I am doing an experiment for an essay in computer science and my topic is encryption. I want to compare the file sizes of files encrypted using AES Crypt and Blowfish. I need to calculate the BigO for both of these as a requirement for my essay. I am unsure on how to do this, I would much appreciate it if someone could help me.
I also would like some opinions on justification for this topic, i am looking at which algorithm produces the smallest file sizes and to see if the results are linear. I have some justification such as businesses may want to reduce the use of memory and resources, talk about transmission is faster with smaller files and downloading is faster. Thank you.
Encryption algorithms such as AES and Blowfish by themselves produces one output byte for each input byte so AES and Blowfish produce the same output sizes.
Except: Both are block based algorithms and depending on the encryption mode the input size may need to be padded to a multiple of the block size so the output is that much larger. For AES the block size is 16-bytes and for Blowfish the block size is 8-bytes so the output may be up to one block size larger than the input.
Try some encryption, there are online tools such as Online encrypt tool that support several encryption algorithms. Note: AES is essentially Rijndael-128.
Opinion: There is no justification for this topic, it is well understood and documented, there is essentially no encrypted size reason to choose one over the other. But, Blowfish is not considered as secure as AES so AES should be chosen, even the author of Blowfish states he used AES.
Note: Many CPUs have optimization instructions for AES so AES is in general the best choice.
Related
Cryptographic Mavens,
Would you be so kind as to offer a bit of background for a cryptographically-related scene in a novel?
Assume the good guy has to decrypt a dozen image files...yet does not know either the system used to encrypt the files, or their key(s).
Unlike the TV/Movie hackers who crack such files after ~5 seconds of furious keyboarding...what (in your opinion) would be plausible (not necessarily through or completely accurate) approaches to (1) determining how the files were encrypted (i.e., what encryption system was used?), and (2) how to attempt decrypting them for viewing?
Your suggestions...thoughts...ideas--maybe even a reference or two (Amazon?)--will be gratefully appreciated.
Thank you,
Plane Wryter
You can't. A reasonably good encryption algorithm will yield data that is statistically almost pure normally-distributed "random" data. (i.e. undecipherable, unrecognizable, high entropy)
The only way you could do this was to brute-force passwords through a brute-force list of password-derivation functions, into a brute-force list of crypto algorithms (i.e. really freaking hard).
Could someone explain a couple of scenarios where the system design can justify the use of an encryption solution, respectively, as 3DES and Blowfish?
I'll add a few, one related to the backwards compatability: if you have a hardware implementation that only does 3DES (many older smartcards) then 3DES could be preferred over AES. Hardware accelerators can be used for both speedups and security (side channel attacks, see below).
3DES implementations may be less vulnerable to side channel attacks (although it certainly is not immune from it). AES is harder to get right - as I've come to understand - because of it's internal design (table accesses). AES better algo, bigger blocksize or key size does not mean much when confronted with a good side channel attack.
3DES has a 8 byte blocksize compared with 16 bytes for AES which can lead to a bit more overhead when using it in block mode encryption. Of course, this one can be mitigated by using a stream mode cipher, and we're only talking about a few bytes for the last block. This is an extremely thin argument for this reason.
I'll be a bit shorter on Blowfish: variable key size and sometimes faster than AES, less likely to be implemented in hardware, but backwards compatibility may be reasons, and the 8 byte blocksize again.
None of the three reasons above is generally enough to choose 3DES or Blowfish over AES of course.
Just one: backward compatibility with existing data or services/API that requires them.
Otherwise keep it simple and just use AES :-)
Note that people often suggest that using older algorithms gets better performance (not a very good tradeoff IMHO) but that's generally not the case (you'll need to test it against the library you use) and AES ends up way faster (at least from 3DES).
what about replacing the key addition subroutine with 3DES so that each block of the four blocks of eight characters get encrypted and including Blowfish F() inside the DES function F() i.e before the 32 bits is returned by the DES F(), I am actually using this idea to create a number generator to try and crack the lottery and to date have won £106.40, would love to upload the code but there is no way to do it here anyway.
I am reading about cryptography I was thinking about these properties of AES (that I use):
same message = same ouput
no message length secrecy
possible insecurity if you know the messages (does this actually apply to AES?)
I hear that AES is secure, but what if I want to theoritcaly improve these properties?
I was thinking I could do this:
apply encryption algorithm A
XOR with random data D (making sure the output looks random in case of any cipher)
generate random data that are longer than the original message
use hashing function F to allocate slots in random data (this scrambles the order bytes)
Inputs: Encryption algorith A, Data to XOR with D and a hashing function F
My questions are
does the proposed solution theoreticaly help with my concerns?
is this approach used somewhere?
Possible enhancements to this approach
I could also say that the next position chosen by hashing function will be altered using a checksum of the last decoded byte after the XOR step (that way the message has to be decoded from beginning to end)
If I was to use this to have conversation with someone, the data to XOR with could be the last message from the other person, but thats probably a vulnerability.
I am looking forward to your thoughts!
(This is only theoretical, I am not in need of more secure encryption, just trying to learn from you guys.)
Yeah.
Look. If you want to learn about cryptography, I suggest you read Applied Cryptography. Really, just do it. You will get some nice definitive learnings, and get an understanding of what is appropriate and what is not. It specifically talks about implementation, which is what you are after.
Some rules of thumb:
Don't make up your own scheme. This is almost universally true. There may be exceptions, but it's fair to say that you should only invent your own scheme if you've thoroughly reviewed all existing schemes and have specific quantifiable reasons for them not being good enough.
Model your attacker. Find out what scenarios you are intending to protect against, and structure your system so that it works to mitigate the potential attacks.
Complexity is your enemy. Don't make your system more complex then it needs to be.
Stay up to date. You can find a few mailing lists related to cryptography and (and hashing) join them. From there you will learn interesting implementation details, and be aware of the latest attacks.
As for specifically addressing your question, well, it's confusing. I don't understand your goal, nor do I understand steps 3 and 4. You might like to take a quick look here to gain an understanding of the different ways you can use a given encryption algorithm.
Hope this helps.
You assumptions are incorrect.
same message != same output
The output will not be the same if you encrypt the same message twice.
This is because you are suppsed to use different IVs'.
Message length can be hidden by adding random data to the plaintext.
Attacks have been demonstrated against AES with lesser number of rounds.
Full-round AES has not been compromised in any way.
Other than that I suggest you follow Noon Silks recommendation and read Applied Cryptography.
What's the point of the random data XOR? If it's truly random, how will you ever decrypt it? If you're saying the random data is part of the key, you might as well drop AES and use only the truly random key - as long as it's the same length (or longer than) the data and is never used more than once to encrypt. It's called a one-time pad, the only theoretically unbreakable encryption algorithm I know about.
If the random bits are pseudo-randomly generated, it's highly unlikely that your efforts will yield added security. Consider how many talented mathematicians were involved in designing AES...
EDIT: And I too highly recommend Applied Cryptography, it's an actually very readable and interesting book, not as dry as it may sound.
AES and other modern encryption algorithm are considered strong and sometimes one can see quotes like "it's not recommended to use classic zip encryption since it is no longer considered strong". But is there a really non-linear difference between them? For example, if both produce sequences with high entropy, does it mean that with a very long password (512 bit and more) they both become indistinguishably strong since lets say theoretically we can break AES for example with billion year computer time and zip with 1/10 of that time?
Yes. When people talk about "strong" encryption, they refer to an encryption scheme where there are no known techniques to recover plaintext that are significantly better than a brute-force key search. "Significant" is an important word here: there is an attack on 256-bit AES with a complexity of 2^119. That's an enormous reduction in the search space, but 256-bit AES is still considered strong because it's simply computationally unfeasible to pull off.
In comparison, the attacks on classic pkzip encryption are as low as 2^27. That's so much simpler than the attack on AES that it's actually quite difficult to visualise; calling it non-linear simply doesn't do it justice. One is trivial, the other impossible.
Imagine I have this:
$cdata = AES_256($data, $pass);
AES_256 implements the AES algorithm.
If I know the content of $cdata and the content of $data and also have
the AES_256() code, can I reverse engineer and find $pass?
Simple answer: NO.
This has been tested, and mentioned in the Wiki link.
A related-key attack can break up to 9
rounds of 256-bit AES. A
chosen-plaintext attack can break 8
rounds of 192- and 256-bit AES, and 7
rounds of 128-bit AES, although the
workload is impractical at 2128 -
2119.
Or put it another way: you have a better chance of being struck by lighting... on the same day you win the Lottery, than breaking it!
This is called a known-plaintext attack. A good cipher like AES should be immune to it, as the others explained.
If $pass is actually a password and not a 256-bit key, you may be in luck.
While it is far from trivial to perform, a brute-force attack against a normal password is much faster than brute-forcing a 256-bit key.
So modify one of the many password-brute-forcing tools, and you have a attack that (depending on the strength of the password) might take weeks to several years - but that is fast compared to 3x10^51 years...
Another quote, from Wikipedia:
AES permits the use of 256-bit keys.
Breaking a symmetric 256-bit key by
brute force requires 2^128 times more
computational power than a 128-bit
key. A device that could check a
billion billion (10^18) AES keys per
second would require about 3 x
10^51 years to exhaust the 256-bit
key space.
Brute forcing when you know the original text might be faster but still, 3 x 10^51 years is a long time. Plus there's the problem of probably not having a device that can check a billion billion (10^18) keys/second.
In short: everything is possible, but this is not feasible in the world we are now living in.
You could brute force it, but it would take a long time. As in decades or even longer. That's the point of encryption algorithms like AES.
AES, like all good crypto algorithms, doesn't rely on security through obscurity.
In other words, there are no "secrets" in the code, so you having the code won't help you particularly.
Known plaintext is a separate issue, which I don't know much about so I'll leave that up to the other answerers.
Of course not - the only approach is brute force.
Do you really think NIST is so stupid as to choose a cipher that is so easily cracked for a new standard?
with the power of super computers the time to crash AES encryption with be dramatically shortened.... I heard...
2x2^256 possible combinations is a lot to bruteforce. But bruteforcing is the only way. It would actually take about 3 decades. AES is the best Encryption possible right now I'd say. But that would only take that much time using a CPU. Because GPU's (Graphic Processing Units) are strictly math based, people have been making programs that only use the GPU to crack math based algorithms much more quickly than a CPU could. In other words AES might not last 3 decades. If only eternity codes were possible. Well looks like dynamic encryption may be the only way people can really hide their information in the near future.