> On Mar 30, 2015, at 8:42 PM, Scott Fluhrer (sfluhrer) <[email protected]>
> wrote:
>
>
> -----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.
You’re right. For some reason I thought that the SID in GDOI was implied rather
than transmitted on the wire. Oh, well…
>> 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…
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?
Yoav
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
