Re: [Cfrg] I-D Action: draft-nir-cfrg-chacha20-poly1305-00.txt

[Yoav Nir <[e-mail]>]

On Jan 28, 2014, at 4:55 PM, Robert Ransom <[e-mail]> wrote:

> On 1/28/14, Yoav Nir <[e-mail]> wrote:
>> 
>> On Jan 28, 2014, at 2:21 AM, Robert Ransom <[e-mail]>
>> wrote:
> 
>>> Section 4 (‘Security Considerations’) discusses the risk that the
>>> Poly1305 key derived from a ChaCha (key, nonce) pair will collide.
>>> This is not a risk at all.  Poly1305 keys are supposed to be chosen
>>> uniformly at random, and most of the effort of proving Poly1305-AES
>>> secure was in bounding the security loss caused by the fact that AES
>>> could not produce the same value of s for two different nonces.
>> 
>> AES cannot, and if we took the entire 512-bits from ChaCha, they would not
>> repeat either. But with taking only half the bytes, they will repeat much
>> sooner. That is why you shouldn't use the first 64 bits of an AES-encrypted
>> counter as an IV for 3DES. You'll likely get a collision after 2^32
>> messages, and you'll get an unacceptably high chance of collision much
>> sooner.
>> 
>> With taking 128 bits for s out of 512, the odds are much better, so they're
>> acceptable. That is what the section says.
> 
> You missed the point entirely.  The attacker does not benefit from the
> repeated use of a Poly1305 key unless he/she/it knows that the key
> will be repeated.  Poly1305's security relies on the assumption that
> the attacker has no information at all about its keys.

Right. Thanks. I missed that only non-predictability was required (rather than non-repeatability). 

OK. Will fix.

Yoav