Re: [IPsec] AD review of draft-ietf-ipsecme-chacha20-poly1305-08

[Yoav Nir <[e-mail]>]

> On Jun 12, 2015, at 10:08 PM, Kathleen Moriarty <[e-mail]> wrote:
> 
> Hi Yoav,
> 
> Once again, sorry for the delay!  My schedule should start to get better in a couple of weeks.
> 
> On Sat, Jun 6, 2015 at 6:03 PM, Yoav Nir <[e-mail] <mailto:[e-mail]>> wrote:
> Hi, Kathleen.
> 
> Please see below
> 
>> On Jun 6, 2015, at 1:19 AM, Kathleen Moriarty <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Hi,
>> 
>> Sorry this took me a bit of time to get to, I wanted to read through some of the background materials first and have been a bit swamped lately (should clear up soon).  Anyway, I have a few comments from my review and also some from a developer.  Please don't feel the need to respond over the weekend as I am sending this late on a Friday.
>> 
>> First, thank you very much for your work on this draft.  Having a standby cipher n hand is a good thing for algorithm agility.  Hopefully we don't need it for some time.
>> 
>> 
>> Section 2 talks about AEAD_CHACHA20_POLY1305 and makes the statement that the initialization vector (part of the nonce) does not have to be unpredictable.  That might be okay for chacha20 as long as you have uniqueness, but I thought POLY1305 required an unpredictable nonce (section 2.5 of rfc7539).  It is not entirely clear to me where that value comes from in this description.  Please let me know if I am missing something in section 2. 
> 
> The Poly1305 function does require a unique key. The way that we generate this unique and unpredictable key is by running the ChaCha20 block function with the same key and nonce, but with the block counter set to zero and using the top 256 bits of the result as the one time key. If ChaCha20 is a valid encryption function that has output indistinguishable from random data, this makes the one-time Poly1305 key unpredictable, even though the nonce is not unpredictable.  The text for that is at the bottom of page 3:
> 
>    The same key and nonce, along with a block counter of zero are passed
>    to the ChaCha20 block function, and the top 256 bits of the result
>    are used as the Poly1305 key.
> 
> Right, but the RFC7539 for POLY1305, the nonce must be unpredictable.  If you are feeding in the same nonce used for chacha, then it should also be unpredictable. 

Ah, I see the source of the confusion. Poly1305 does not get a nonce at all. It gets a one-time key. You could generate this one-time (unpredictable) key in many ways, but the way we do it here is by encrypting the (predictable) nonce using ChaCha20. This is similar to the practice of generating a random 128-bit value, and using that as an AES key, and encrypting a counter to generate unpredictable values (such as initialization vectors).

So it’s fine for the nonce to be predictable as long as the encrypted nonce is not.

I’ll make the rest of the changes soon.

Yoav