11

What are the difference between MCRYPT_RIJNDAEL_128, MCRYPT_RIJNDAEL_256, MCRYPT_BLOWFISH, etc. Which one is best suitable for data transfer on web?

Duncan Jones
  • 67,400
  • 29
  • 193
  • 254
murvinlai
  • 48,919
  • 52
  • 129
  • 177

5 Answers5

19

Rijandel is another name for AES, the current "one good standard" algorithm. The number 128 or 256 is the key length.

Blowfish is a somewhat older 64 bit block cipher (AES is a 128 bit block cipher).

You can't really say that either of them is any "better" or "worse", because none of them has really been broken, but in general AES should be superior, and most implementations are faster too. Also, the most modern CPUs support AES in hardware, which will make it even faster... so there is little reason not to use AES.

As for key length, 128 bits is actually quite sufficient for a symmetric cipher. Unless of course you are the keeper of your country's nuclear weapon codes, in that case you will want to use 256 bit keys instead.

Note that if you want to use a 256 bit key in a sensible manner, then you will need a password of around 40 characters. Which shows once again that the crypto algorithm is not the weak link in the security chain, but the human is.

Edit: On a second thought, 50-60 characters is probably a more reasonable guess for the required password length on a 256 bit key. English language has considerably less than 2 bits of entropy per character. Let's assume you use a somewhat more random character sequence of letters and digits (one must still be able to remember it, though...), so maybe we'll have 4-5 bits of entropy per character (quite optimistic!). That would require you to type in between 51 and 64 characters, so the password's entropy roughly matches the key's.

Now the question is: How many of us have a 50 character password? :-)

Update:
As of late 2011, there exists a key-recovery attack on Rijndael/AES (Bogdanov, Khovratovich, Rechberger) which is not one of the "mostly theoretical" or "hilarious reduced round" kind of attacks. The attack works on full-round AES and is about 4 times faster than brute force. Formally, one may therefore consider Rijndael being "broken".
Practically, the attack is to date irrelevant. Even with the shortest supported key length, an attack four times faster than brute force requires 2126 operations, which is not practical even with a massive hardware implementation. However, this might change in the future if the attack can be improved.

Damon
  • 67,688
  • 20
  • 135
  • 185
  • 1
    Who says that the encryption key (and IV) has to be human-readable? [`openssl_random_pseudo_bytes(32)`](http://us3.php.net/manual/en/function.openssl-random-pseudo-bytes.php) will get you 256 bits of cryptographically adequate randomness, which happens to be the maximum key size in AES-256. It can be stored safely base64-encoded. – Charles Mar 10 '11 at 00:39
  • 2 bits of entropy per character? Sounds way to low for passwords, I would guess more like 5 or 6 bits per character. I would guess the entropy per character of English text (like a newspaper article) will be much less than that for passwords. – President James K. Polk Mar 10 '11 at 00:40
  • @Charles: It's true that you can trivially create 256 bits of random for a key, but what is it good for? That only shifts the problem one stage further: how do you protect this random key? No matter how many random bits a randomly generated key has, it bears no more security than the weakest link in the security chain. The symmetric encryption is never the weak link. 99% of the time it's the human (because humans utterly fail at choosing good passwords and at keeping them safe), and for the remaining 1% it will almost always be a key exchange protocol. – Damon Mar 10 '11 at 00:54
  • @GregS: I remember NIST claiming that their Electronic Authentication Guidelines ensure that 8-character passwords have at least 30 bits, that would be 2,13 bits per character. Wikipedia claims 50 characters for case-insensitive alphanumeric, and 43 for case-sensitive alphanumeric for 256 bits of entropy, which is not very far off my figures. – Damon Mar 10 '11 at 01:01
  • @dm.skt: I stand corrected, at least NIST would base their figures on some actual data. – President James K. Polk Mar 10 '11 at 01:14
  • Regardless, AES-256 *can't take keys larger than 256 bits*, so a 40-50 character key would have to be truncated at character 32 to be legal in this specific instance. You'd need to move beyond the normal alphanumeric range to pack that much entropy into such a minimal space. – Charles Mar 10 '11 at 01:37
  • @Charles: Correct. That is why many people use a cryptographic hash (e.g. SHA-256) to generate the actual key from a passphrase. That would turn the 40-50 characters into 32 characters. The problem is that you're already lucky if someone uses 10 characters. A 256 bit hash that was generated from a data that has only 30-35 bits of entropy still only has 30-35 bits of entropy. You can make an attacker's life a tiny bit harder e.g. by securing a cryptographically secure random number with this key. That makes an attack slighly harder insofar as encrypted random data is "random garbage" and ... – Damon Mar 10 '11 at 08:37
  • ... and decrypted random data is "random garbage" too, which makes it harder to tell that you've found the key than if the data was some actual known plaintext or plaintext of some known structure. So, an attacker would need 2 decryption steps instead of 1, effectively adding 1 bit of key lenght. But the problem is that a lot of users will just give you their password if you tell them that there has been an incident of "newtonian bit collapse" in the system, so you must verify that their password still works correctly and their data is still valid. Even a 16384 bit key won't prevent that. – Damon Mar 10 '11 at 08:45
  • I didn't know AES was supported in hardware on some modern CPUs. Good to know! – Nick Johnson Mar 10 '11 at 17:50
  • So far it's somewhere in between "rare" and "theoretic", but yeah, it's nice. The more expensive Westmere processors (i5 and i7) support it, and allegedly AMD's Bulldozer will support it when it comes out later this year. So, before it's "real reality", I guess another few years will pass, but it will come. With the new instructions, encoding/decoding one block with AES boils down to somewhat more than a dozen instructions with a latency of about 5 clock cycles each. So, at around 60-70 cycles per block, I guess memory bandwidth will be the limiting factor. – Damon Mar 11 '11 at 00:16
  • 2
    "The number 128 or 256 is the key length." No. It defines the block size! http://php.net/manual/en/function.mcrypt-encrypt.php – binarious Sep 04 '13 at 08:49
  • @binarious: Thank you for the downvote, but please get your facts straight before making yourself seem silly. Rijndael is a 128-bit block cipher. The block length is part of the algorithm's design, and it is simply not possible to use it with a different block size. The algorithm's only tuneable parameters are key length and (in principle) the number of rounds. The numbers 128 and 256 in the cipher constant do **certainly not** refer to the cipher's block size. – Damon Sep 04 '13 at 09:58
  • 3
    @Damon "Rijndael, supports block and key sizes of 128, 192, and 256 bits, but in AES the block size is always 128 bits." https://en.wikipedia.org/wiki/Block_size_%28cryptography%29 And in the official PHP documentation is written, that you set the block size with the constant in question. – binarious Sep 04 '13 at 10:13
  • "*The attack works on full-round AES and is about 4 times faster than brute force. Formally, one may therefore consider Rijndael being "broken".*" Ummmm, are you sure about this? Firstly, four times faster than brute force is still incredible difficult. I don't see how this makes Rijndael broken. – Duncan Jones Jan 07 '14 at 15:37
  • @Duncan: Any algorithm that has an attack which is better than brute force is formally "broken". That's just how the definition goes -- a non-broken algorithm offers no means of getting past it that is any faster than trying every possible permutation (i.e. brute force). That's however only looking at it from a formal PoV. Hence the following paragraph which says that _practically_ this does not matter to date, since the complexity is still 2^126, which is (assuming no quantum computers and assuming the attack is not refined by another 4-5 orders of magnitude) good enough for the time being. – Damon Jan 08 '14 at 13:52
  • 1
    @Damon Interesting. Can you cite a source for that definition of "broken"? I hadn't appreciated it had such a strict meaning. For instance, [this page](http://searchsecurity.techtarget.com/definition/cryptanalysis) defines broken as being able to extract plaintext from ciphertext and would describe your scenario as weakening. – Duncan Jones Jan 08 '14 at 13:56
  • [This question](http://crypto.stackexchange.com/questions/933/when-is-an-asymmetric-scheme-considered-broken) also seems to suggest that "broken" means something more dramatic. Although [this one](http://crypto.stackexchange.com/questions/3690/no-sha-1-collision-yet-sha1-is-broken) agrees with you. I suspect you are right, but that there are many people using the term incorrectly. – Duncan Jones Jan 08 '14 at 13:58
4

Both Rijndael and Blowfish are considered to be secure.

MCRYPT_RIJNDAEL_128 vs MCRYPT_RIJNDAEL_256:
The only difference is the block size. You can use either with 128 bit, 192 bit, or 256 bit keys.
Bigger keys take longer to brute-force.
The 256-bit version is therefor more secure.
Note: The 128-bit version still takes lots of time time to brute-force.

Currently Rijndael is the Advanced Encryption Standard:
http://en.wikipedia.org/wiki/Advanced_Encryption_Standard

AES is generally faster then Blowfish because:
- The algorithm itself is more efficient for processors (bit vs byte blocks).
- Manny processors support hardware acceleration for AES.

Conclusions:
- All three options are secure enough for data transfer.
- The choice depends on how 'secret' the data is.
- Rijndael is wider used and therefore easier to implement is some situations.

Scott Arciszewski
  • 33,610
  • 16
  • 89
  • 206
Anne
  • 26,765
  • 9
  • 65
  • 71
  • 2
    Brute force on a 128 key is not realistic. It just won't happen. If you have an i7, you can do around 40 million AES operations per second. Assume that my numbers are by a factor of 1000 wrong, and assume that an attacker has a gigantic zombie network with 500 million such machines. Now divide 2^128 by those numbers and divide by (86400*365) again. That's still 10^11 years. Heck, our planet doesn't even exist for 10^11 years yet. It is *much* more likely that your passphrase will be broken. – Damon Mar 10 '11 at 00:41
  • That's exactly why I mentioned it takes 'lots of time'. Currently brute-force is the only way to decrypt AES encrypted data without the key, in other words, there is no faster method then trying every possible option. Essentially 128-bit AES encryption is still immensely secure, there are just too much possibilities :) – Anne Mar 10 '11 at 01:09
  • 3
    `RIJNDAEL_256` is not AES. Only `RIJNDAEL_128` – CodesInChaos Jan 18 '13 at 22:24
2

The answer(s) to this question stating that, regarding MCRYPT_RIJNDAEL_128 and MCRYPT_RIJNDAEL_256, "The number 128 or 256 is the key length" - this is incorrect. These numbers refer to the blocksize, not the keylength. However, both implementations (using a block size of 128 or 256 bits) can accept keys of 128 or 256 bits.

hunter
  • 872
  • 10
  • 26
1

It depends on the kind of answer you want: Differences in implementation are a mere programming concern whilst differences in design are usually quite detailed mathematical proofs. Explaining the intricate design differences between several encryption algorithms is possibly beyond the scope of this site. In addition, every algorithm has weaknesses, some known, some not. Specific weaknesses in extant algorithms usually result in their retirement, but there can be ways to work around them (Classic example: DES had a subset of keys that resulted in easily crackable code. The workaround was to not use those keys.).

staticsan
  • 29,935
  • 4
  • 60
  • 73
-1

RSA is an Asymmetric encryption algorithm and maximum Key length 2048 for proposed year 2030 AES is a Symmetric algorithm with maximum key size 256 bit for proposed year 2015 a Serpent encryption algorithm is also symmetric algorithm with key size 256 and proposed year 2015.

TechAUN
  • 1