> On Jun 12, 2015, at 10:08 PM, Kathleen Moriarty > <[email protected]> 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 <[email protected] > <mailto:[email protected]>> wrote: > Hi, Kathleen. > > Please see below > >> On Jun 6, 2015, at 1:19 AM, Kathleen Moriarty >> <[email protected] <mailto:[email protected]>> >> 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
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
