Hi Yoav, On Fri, Jun 12, 2015 at 3:33 PM, Yoav Nir <[email protected]> wrote:
> > 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]> wrote: > >> Hi, Kathleen. >> >> Please see below >> >> On Jun 6, 2015, at 1:19 AM, Kathleen Moriarty < >> [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). > OK, so the difference here is that the method you are using is in section 2.6 and I was looking at the requirements for POLY1305 from section 2.5, which uses a different method. > > 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. > Thank you! I'll look for the update to kick-start last call. Kathleen > > Yoav > > -- Best regards, Kathleen
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
