-----Original Message-----
From: IPsec [mailto:[email protected]] On Behalf Of Yoav Nir
Sent: Monday, March 30, 2015 10:40 AM
To: [email protected]
Cc: [email protected]; [email protected]
Subject: [IPsec] Two questions about draft-ietf-ipsecme-chacha20-poly1305-00
> Hi,
>
> There is two questions I would like guidance from the group about.
>
> First is the nonce/IV question: In the current draft, there is a 64-bit IV
> with guidance not to repeat them (so use a counter or LFSR). The function
> itself accepts a 96-bit input nonce, so the nonce is constructed from the
> 64-bit IV and 32 zero bits. The reason for doing this is so the algorithm
> could be used in a multi-sender case such as GDOI, where the 32-bit zero can
> be replaced by a sender ID.
This idea about the multi-sender case works only if the there's a sender id
somewhere in the encrypted packet.
> Alternatively, we could generate a 32-bit salt value from the key material,
> but I don’t see a reason why we’d want that.
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...
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
