Asked  8 Months ago    Answers:  5   Viewed   30 times

So guys, there's plenty of different ciphers available - but which one is the safest to use nowadays?




If unsure use AES (also known as "Rijndael") with a 128-bit key. If you have developed some kind of fetish about key size then you could fulfill your irrational qualms by selecting a larger key, e.g. 192 or 256 bits; the extra cost is not high (+40% workload for AES-256, compared to AES-128, and it takes a very very fast network to actually observe that difference).

Beware that, regardless of the key size chosen, the correct mcrypt cipher for AES is always MCRYPT_RIJNDAEL_128. This is because the AES standard refers to the flavor of the Rijndael cipher with a 128-bit block size. If you want AES-256, you need to use MCRYPT_RIJNDAEL_128 with a 256-bit (32 byte) key, not MCRYPT_RIJNDAEL_256.

AES was published in 1998 and adopted by the US government as a federal standard in 2001, and it shows no sign of weakness nowadays. Some mathematical properties were found later on, but they do not impact actual security; mostly, they highlight that we have some relatively precise knowledge on why AES is secure. No other symmetric encryption algorithm has received as much attention (by thousands of talented cryptographers) than AES.

Most security issues come from how the cryptographic algorithm is used, not the algorithm itself. Use a proper chaining mode, add a MAC, manage padding, and most of all handle the keys securely. If you got all of this right (which is much more tricky than what it seems) then it becomes time to worry about choosing Rijndael, Twofish or whatever.

Wednesday, March 31, 2021
answered 8 Months ago

Have you tried the three different second arguments for mcrypt_create_iv(): MCRYPT_RAND (system random number generator), MCRYPT_DEV_RANDOM (read data from /dev/random) and MCRYPT_DEV_URANDOM (read data from /dev/urandom)? Do they offer different consistent speeds? I wonder if it's because /dev/random (the default random source) is running out of collected entropy; the function will block when it does.

Wednesday, March 31, 2021
answered 8 Months ago

PHP 5.6 has stronger encryption requirements than 5.4. In 5.6 you'll get this warning, which is really an error because it actually causes encryptions and decryptions to fail:

Warning: mcrypt_encrypt(): Key of size xx not supported by this algorithm. Only keys of sizes 16, 24 or 32 supported.

...where "xx" is the length of your salt value. So the salt value has to be exactly 16, 24, or 32 characters in length.

Saturday, May 29, 2021
answered 5 Months ago

Version 5.2 is used by 84.9% of all the websites who use PHP version 5.

Version 5.3.3 is used by 39.7% of all the websites who use PHP version 5.3

You can see more statistical data from the following link:

Saturday, May 29, 2021
answered 5 Months ago

No, in fact an IV is vital in most implementations. The IV is also considered to be safe for public use, for instance the IV is transmitted in plain text for WEP and WPA1/WPA2. The problem arises when this same key+iv is used to encrypt the same plain text. The cipher texts will be identical, unless you use an IV. If an attacker can encrypt arbitrary plain text with this key, and then view the cipher text. This is a much faster way of brute forcing other cipher text that the attacker has obtained.

Not only that, the IV must be random or you would be in violation of CWE-329. The reason why this is a problem is a bit more subtle and I didn't get it at first. You didn't mention this, but i hope you are using either the CBC or CMAC modes

The use of a hash function on a password is nearly identical to using a String2Key function. This is a solid design so long as an attacker can't use SQL Injection to obtain the key.

Tuesday, September 14, 2021
answered 2 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :