Printable View
I currently use the AES Fusion object, and I find it works very well. However there are those who question the use of the 128-bit algorithm since the industry standard is now AES 256 Rijndael, which as far as I know has yet to be defeated.
Are there any plans for an object using this algorithm?
I second this as it's stronger.
Actually, there have been various cryptographic breaks against AES 192/256, and against reduced-round versions of all of them, but no breaks that I know of against full AES 128.
Surely those breaks were timing attacks or other exploits requiring code execution privileges on the machine performing the encryption, and not attacks on the ciphertext itself. Unless there's some error in the implementation, the 256-bit key will yield a stronger ciphertext.
I think that there's also a common tactic in use where the hash from a passphrase is used as the encryption key, which would weaken the cipher because the hash is made up of fewer character types (SHA1 is only letters and numbers). I'm not a cryptography expert by any means, but I think a longer key would be good in these cases.
+1 vote
This would be a good update for the AES Fusion object. :)
Nope, 'twas an attack on the cypher itself. See: http://www.springerlink.com/content/e300837u42750670/Quote:
Originally Posted by Richard_Pikk
Note that it's still far too slow of an attack to be practical, but it's still an attack, and on AES 256, not on AES 128.
You misunderstand, the hash isn't only letters and numbers, the hash is raw binary, the numbers are just a human-readable hexadecimal representation of it. It's entirely possible people are stupid enough to use the hex version as the key, but it's not right.Quote:
Originally Posted by Richard_Pikk
Ah, okay. Not having read the paper, does it imply that their attack cannot work for some reason against AES 128?
Honestly, I don't know. It specifically concentrates on AES 256, making no mention of AES 128. I know that there are differences in the algorithms other than the key size.
On the topic of hashes for keys, do you see any method of doing this in MMF2 using the RAW output?
I'm not sure you really gain anything by hashing the key before using it, the entropy should be about the same...
The only case I know of where people do that is in making WEP keys for old wifi networks, as WEP required an exactly 40-bit key, which would be only 5 characters.
It could be used in cases where a password is required to read some encrypted data, like in programs that people use to store their PIN numbers, banking information and other passwords. The user inputs a master password which is used to decrypt a stored encryption key that in turn unlocks the data. Because the master password isn't necessarily exactly 16 characters long, the input could be hashed and the first 128 bits of the hash used as the key.
A few points.
Rijndael was the codename for the cipher before it was selected for AES.
AES 128 has not been broken. Reduced-round versions, sure, but that's only something the cryptography guys care about. Attacks on modern ciphers (such as the recent PS3 hack) are caused by implementation errors or side-channel attacks. And social engineering is far more effective than any other technique.
The key size determines the number of rounds/round schedule. The algorithm doesn't really change, only a few constants (constants can be a big deal in cryptography e.g. S-boxes, but this is not that kind of constant).
Hashing the key won't increase the entropy, this is not the point of a hash. You are getting the right idea, however, since a hashed passphrase is better than inserting the passphrase directly into the key and padding/truncating it. A salted and hashed passphrase is even better, preventing the use of rainbow tables.
Your goal is to render brute-force attacks infeasible, by making key generation computationally expensive. Using SHA-1 alone, once is a poor choice; you should use PBKDF2. (Someone needs to develop an extension for that!)
"SHA1 is only letters and numbers" is a misunderstanding, it outputs a 160-bit digest which is often expressed as 40 hexadecimal characters. If you're using it for AES 128 you need to truncate it; for the others, you need to pad it (and if the attacker knows you are only using 128 bits of a 256-bit key, her job is billions of times easier). Not that you should use its output directly, see above.
So if you were to hash (SHA-1) a salted passphrase, then proceed to rehash the output (again with a salt) a large number of times, you could produce a key with the same entropy as the passphrase but with a higher computational overhead required to brute-force?
No, hashing repeatedly lowers entropy due to hash collisions, in theory hashing enough times can get you down to the same single value.
Actually the "key schedule" (for making round keys from the main key) has extra steps in AES 256. Don't know how it affects the strength of the algorithm, it's well known that adding extra steps to an encryption doesn't necessarily increase security (e.g. 2x ROT13 is not clever!).Quote:
Originally Posted by ChrisB
I mistyped, I meant key schedule. It increases in accordance with the size of the key, so it can be used effectively with the fixed 128-bit block size.
The security does increase with the key size, I forget the reasoning now, been a while since I looked at it. Although the effective security has decreased a few times in a short space of time, 256 will continue to be significantly more secure than 128, even if an attack could make the strength linear to the key size rather than exponential. But the security is still *very* high, again this is something for the cryptographers to care about while they design whatever supersedes AES, and certainly not for law-abiding non-paranoid civilians to care about.
Adding extra steps to a cipher can be used effectively however, Triple DES is just DES applied three times, and is very widely used in banking. (Though DES is pitiful by today's standards) If there's a problem you will certainly hear about it.
AES 256 has an extra step in the key schedule involving the S-BOX that isn't in the other versions of AES. See: http://en.wikipedia.org/wiki/Rijndael_key_schedule#Key_schedule_descriptionQuote:
Originally Posted by ChrisB