What's the feeling on them preferring 256-bit AES over 128-bit AES?
I was under the impression there is no theoretical nor practical justification for it.
I was under the impression there is no theoretical nor practical justification for it.
> What the attacker hopes to find inside the AES attack is a key collision. This means that a key guessed by the attack matches a key chosen by a user. Any particular guessed key has chance only 1/2^128 of matching any particular user key, but the attack ends up merging costs across a batch of 2^40 user keys, amplifying the effectiveness of each guess by a factor 2^40
If the attacker has collected 2^40 instances of some known plaintext, such as "GET / HTTP/1.1\r\n", encrypted under 2^40 unknown AES-128 keys (and it doesn't matter how those keys were generated), then the attacker can generate a key randomly, encrypt the known plaintext under that key, and see if it matches any of the target ciphertexts. The chance of guessing one of the 2^40 keys successfully this way is 1/2^(128-40) = 1/2^88. This means that attacking one of the keys requires far less than the 2^128 operations that one might expect would be required to attack AES-128. DJB argues that this makes AES-128 ill-matched with elliptic curves that provide a 128-bit security level, thus motivating a cipher with 256 bit keys instead, such as AES-256 or ChaCha20.
In practice, the first 32 bits of the GCM nonce used by TLS are derived during the handshake, so the attacker has to do 2^32 more computations (since there are 2^32 different ways a known plaintext could be encrypted with a given key). So perhaps AES-128 is actually fine with TLS. But the point still stands that there is a justification for preferring AES-256 over AES-128.
"Bottom line: 128-bit AES keys are not comparable in security to 255-bit elliptic-curve keys. Is 2²⁵⁵−19 big enough? Yes. Is 128-bit AES safe? Unclear."
The point there is that batching helps the attacker finding the first AES key by a factor of m, m being the number of keys being attacked, but it doesn't really help finding the first ECC key---although it does help with the cost of finding the second, third, etc a bit. So for example, the effective multi-key security of AES-128, given 2^32 different keys (read: sessions), is 2^96.
See for example [1] for a formalization of multi-key security in the symmetric encryption setting.
With random keys (generated via /dev/urandom), you don't need to worry about that.
I know how sometimes weaknesses are found that seem impossible at first but can somehow be improved, but unless something fundamental has changed in the years since that attack did not appear to have any actual significance beyond academics (which is why no one in the industry worried about it). Beyond any efficiency requirements is the basic least-common denominator actor issue: if an attacker can get a key owner (person or machine) to perform that level of arbitrary action, there are much much easier ways to subvert the entire system.
As a symmetric block cipher I suppose being in the habit of AES-256 usage is at least some gesture towards any future attacks by scalable general purpose quantum computers should they appear, since Grover's means it'd still be decent while 128 would drop to 64, though given the generally usage of asymmetric ciphers for initial exchange I don't know if it actually matters at all in the specific instance of the web. But whatever its benefits or downsides I don't think the related key attack makes it worse then AES-128.
That being said, I don't know if I'd agree with anyone suggesting that A256 provides a meaningful increase in practical security over A128. As you said, the main difference is post-quantum and you can't just drop A256 in and say you are ready for post-quantum as you need a more holistic post-quantum solution anyway.
Quantum does affect this, but obviously the implications of quantum are way bigger than your block cipher choice.
DJB pointed out, correctly, that generic attacks against ciphers with 128-bit keys are distressingly close to being practical. Generic attacks against 256-bit ECDHE are wildly impractical. If you want to make it take comparable effort to break the key exchange as it takes to break the cipher, the cipher key needs to be bigger.
Not he didn't.
And 256-bit ECDHE has 128 bits of security.
> And 256-bit ECDHE has 128 bits of security.
Can you give that a meaningful definition? I suspect you mean that it takes ~2^128 operations to break a single target ECDHE exchange. If so, that is both true and completely irrelevant to anything I said.
The key point here is that it does not take anywhere near 2^128 operations before you can decrypt a single AES-128 block out of a large corpus of captured ciphertexts. For that type of attack, 128 bit ciphers offer vastly less security than ECDHE on a 256-bit field.
Imagine that the NSA has collected 2^40 sessions using AES-128 on the internet. Let's imagine that they only want to steal session IDs being sent (if they want to eavesdrop on more data, it will be worse). From burp, I get that a simple GET request to Gmail is 2319 bytes, that's around 144 blocks of AES. Let's say a 100.
So in total, the NSA would have to store 2^40 * 128 * 100 bits, let's say around 2 petabytes.
Also I forgot, let's imagine that the first block of any of these sessions' first message is always the same thing. A GET request to the same address. We got extra lucky!
Now they have to perform 2^88 AES operations for each key guess, and hopefully they will start finding keys at this point. (It's more than all of the computing power of bitcoin btw.). And for each of these AES operations they also have to check in their 2 petabytes corpus for a match (I hope you way to do that).
Let's imagine that the NSA wants to do less computations of AES. They could have stored 2^50 sessions instead! And now they only have to perform 2^78 AES operations.
For this they would have to store around 2 exabytes. In 2010 the whole traffic of internet was estimated to be around 21 exabytes per month. So if the NSA would be to record sessions for a month, they would need to store 10% of the internet hopping that they would also be GET requests to Gmail.
Now we can theorize about the evolution of storage space, and computing power, and ... quantum computer. In which case ECDHE will fall before AES-128 does.
2 petabytes is no big deal for the NSA. Also, why would they store anywhere near this much per session? They can estimate which part of the stream matters and store that part if they want to.
> And for each of these AES operations they also have to check in their 2 petabytes corpus for a match (I hope you way to do that).
Bloom filter plus a large hash table?
The point is that crypto ought to be configured to be secure, with a large margin of error, against an adversary who controls the entire world's computational capacity and is willing to use highly theoretical attacks because achieving this level of security is not particularly difficult. AES-256 satisfies this criterion, as does ECDHE until a quantum computer shows up. AES-128 does not satisfy this criterion even though the existing attacks are barely practical even for a nation-state adversary.
256-bit keys may not even be quite good enough against a batch attack done with a quantum computer because a full Grover's algorithm run against the entire batch runs in ~sqrt(2^bits / batch size). If you assume a batch size of 2^96 (to give a nice margin of error) and you want a work factor of 2^128 for the adversary, that gives 352 bits.
ECDHE is, of course, completely dead once someone builds a quantum computer.