3 ms·

I guess once SHA-3 is done, NIST better start research on the next symmetric cipher. The attack only knocks off two bits now, but attacks only get better with t

I guess once SHA-3 is done, NIST better start research on the next symmetric cipher. The attack only knocks off two bits now, but attacks only get better with time. Note that you should be using accepted standards for key management anyways. NIST believes that AES-128 has 128 bits of strength, and AES-256 has 256 bits of strength [1, page 63], which they find "Acceptable" until 2031 [1, page 65]; the catch is that any individual key should be expired after a few years. This is called a "cryptoperiod," and the longest they recommend using a key is five years [1, page 55]. By this standard, keep using AES-256, but change your keys every year, and be prepared to migrate to a new cipher at some point within the next decade or two. [1]: http://csrc.nist.gov/publications/drafts/800-57/Draft_SP800-57-Part1-Rev3_May2011.pdf http://csrc.nist.gov/publications/drafts/800-57/Draft_SP800-...

dchest 15y ago
Speaking of SHA-3, "biclique cryptanalysis was ﬁrst introduced for hash cryptanalysis". Here's an interesting quote from the paper regarding the relationship between attacks on block ciphers and hash functions: "... the block cipher standard AES is almost as secure as it was 10 years ago in the strongest and most practical model with a single unknown key. The former standard DES has not seen a major improvement since Matsui’s seminal paper in 1993. In contrast, the area of hash function cryptanalysis is growing quickly, encouraged by the cryptanalysis MD5, of SHA-0 and SHA-1, followed by a practical attack on protocols using MD5, preimage attacks on Tiger and MD5, etc. As differential cryptanalysis, a technique originally developed for ciphers, was carried over to hash function analysis, cryptanalysts are now looking for the opposite: a hash analysis method that would give new results on block ciphers."
tptacek 15y ago
The total cost to the industry of adopting AES was enormous. That implies that deprecating it would at present impose costs that far outweigh the benefits, because replacing AES will be expensive, and there are at present minimal practical benefits to doing so. Remember, plenty of critical systems have been fielded that rely on RC4 and DES-EDE, both of which are also (for all intents and purposes) unbroken in their most common usage. For Hacker News, the far more important thing to point out is that no matter what block cipher you use, you are never going to get burnt by research like this, but you are almost certain to be completely boned by implementation errors.
- xilun0 15y ago
  one should also note that even if we take a fantasist hypothesis of a major breakthrough demonstrating a loose of strength of 2 bits for AES-128 once a year during ten years, we would probably still have tens of years to replace the cipher. Of course this theory is full baseless hypotheses, but even more is the theory that would says that there is a risk of a major breakthrough tomorrow reducing the strength of AES-128 to 64-bits. There is no need to hurry.
- gchpaco 15y ago
  For Hacker News, the far more important thing to point out is that no matter what block cipher you use, you are never going to get burnt by research like this, but you are almost certain to be completely boned by implementation errors. Wish I could up vote you twice for this.
- quanticle 15y ago
  I would consider key management to be a greater problem than implementation, at this point. There are many verified, open-source, freely-licensed cryptography libraries out there. You shouldn't be rolling your own implementation. Unfortunately, key management is still a difficult problem. Without secure keys, even the most secure encryption becomes nothing more than an inconvenience.
  - tptacek 15y ago
    Everyone says this, because Applied Cryptography (not a good book) says it. But no, the problem of coming up with a good 128 bit or 256 bit key is not the hardest part of getting a cryptosystem working. Plenty of static-keyed systems, in which keys are more or less guaranteed to come from /dev/random, end up totally busted. You seem to be thinking that when I say "implement", I mean, "building an AES core library from scratch". No. I mean properly using a well tested, totally sound AES library in a way that doesn't leave your application totally boned.
    - cperciva 15y ago
      I've seen a lot of broken key management. People using MD5(passphrase) (cough OpenSSH cough) as a key, people downloading public keys over insecure networks and not verifying them at all, people distributing secret keys along with software destined to be run on hostile systems... I'm happy to say that systems which try to generate random passwords do tend to generate securely random passwords, though. /dev/random has been a huge help there.

dchest 15y ago

Speaking of SHA-3, "biclique cryptanalysis was ﬁrst introduced for hash cryptanalysis". Here's an interesting quote from the paper regarding the relationship between attacks on block ciphers and hash functions: "... the block cipher standard AES is almost as secure as it was 10 years ago in the strongest and most practical model with a single unknown key. The former standard DES has not seen a major improvement since Matsui’s seminal paper in 1993. In contrast, the area of hash function cryptanalysis is growing quickly, encouraged by the cryptanalysis MD5, of SHA-0 and SHA-1, followed by a practical attack on protocols using MD5, preimage attacks on Tiger and MD5, etc. As differential cryptanalysis, a technique originally developed for ciphers, was carried over to hash function analysis, cryptanalysts are now looking for the opposite: a hash analysis method that would give new results on block ciphers."

tptacek 15y ago

The total cost to the industry of adopting AES was enormous. That implies that deprecating it would at present impose costs that far outweigh the benefits, because replacing AES will be expensive, and there are at present minimal practical benefits to doing so. Remember, plenty of critical systems have been fielded that rely on RC4 and DES-EDE, both of which are also (for all intents and purposes) unbroken in their most common usage. For Hacker News, the far more important thing to point out is that no matter what block cipher you use, you are never going to get burnt by research like this, but you are almost certain to be completely boned by implementation errors.

xilun0 15y ago
one should also note that even if we take a fantasist hypothesis of a major breakthrough demonstrating a loose of strength of 2 bits for AES-128 once a year during ten years, we would probably still have tens of years to replace the cipher. Of course this theory is full baseless hypotheses, but even more is the theory that would says that there is a risk of a major breakthrough tomorrow reducing the strength of AES-128 to 64-bits. There is no need to hurry.
gchpaco 15y ago
For Hacker News, the far more important thing to point out is that no matter what block cipher you use, you are never going to get burnt by research like this, but you are almost certain to be completely boned by implementation errors. Wish I could up vote you twice for this.
quanticle 15y ago
I would consider key management to be a greater problem than implementation, at this point. There are many verified, open-source, freely-licensed cryptography libraries out there. You shouldn't be rolling your own implementation. Unfortunately, key management is still a difficult problem. Without secure keys, even the most secure encryption becomes nothing more than an inconvenience.
- tptacek 15y ago
  Everyone says this, because Applied Cryptography (not a good book) says it. But no, the problem of coming up with a good 128 bit or 256 bit key is not the hardest part of getting a cryptosystem working. Plenty of static-keyed systems, in which keys are more or less guaranteed to come from /dev/random, end up totally busted. You seem to be thinking that when I say "implement", I mean, "building an AES core library from scratch". No. I mean properly using a well tested, totally sound AES library in a way that doesn't leave your application totally boned.
  - cperciva 15y ago
    I've seen a lot of broken key management. People using MD5(passphrase) (cough OpenSSH cough) as a key, people downloading public keys over insecure networks and not verifying them at all, people distributing secret keys along with software destined to be run on hostile systems... I'm happy to say that systems which try to generate random passwords do tend to generate securely random passwords, though. /dev/random has been a huge help there.