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

[Kathleen Moriarty <[e-mail]>]

Hi Yoav,

On Fri, Jun 12, 2015 at 3:33 PM, Yoav Nir <[e-mail]> wrote:

>
> 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]> wrote:
>
>> Hi, Kathleen.
>>
>> Please see below
>>
>> On Jun 6, 2015, at 1:19 AM, Kathleen Moriarty <
>> [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).
>
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