Here's the reason that we do use the 32-bit salt value for GCM - to prevent
batching attacks.
Consider the case that an attacker is able to collect packets from a billion
(2^30) sessions; each such session contains a packet with the same IV (say,
IV=0), and contains a packet with the same known plaintext (or, at least,
plaintext that satisfies the same known linear equations). Then, what an
attacker can do is check a key to see if any of the IV=0 packets used that key,
in constant time. The reduces the effort for an attacker to find the n bit key
for some session from 2^n to 2^{n-30}. What the salt does is multiply the
effort involved in this specific attack by a factor of 2^32 (because the
attacker needs to guess the key and the salt); that way, the attacker needs to
collect 4 billion sessions before this attack starts to have any advantage over
a simpler attack that just attacks a single packet (which the salt doesn’t
protect against).
Now, of course, chacha20 has 256 bit keys; hence even if we decided not to
apply the same protection, someone with a collection of a billion sessions
might be able to use this to reduce the effort to 2^226.
I'll let you decide whether this is a compelling argument or not…
I think that for 256-bit keys it’s not that compelling. So the question is
which is simpler: to do as AES-GCM does, or to set the salt to zero?
It seems to me like a "truth in advertising" kind of thing: if we use a
256-bit cipher then people using it expect 256-bit strength, rather than
2^226. So I would be happy if we can get the salt without having to pay
in packet length.
Thanks,
Yaron
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
