Re: [IPsec] Two questions about draft-ietf-ipsecme-chacha20-poly1305-00

[Yaron Sheffer <[e-mail]>]

>> 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