Re: [IPsec] ChaCha20 + Poly1305 for IKE and IPsec

[Paul Wouters <[e-mail]>]

On Fri, 27 Feb 2015, Yoav Nir wrote:

>>> [2] https://tools.ietf.org/html/draft-nir-ipsecme-chacha20-poly1305-05
>>
>> Can we rename ESP_ChaCha20-Poly1305 to ESP_ChaCha20_Poly1305 ? That
>> allows implementors to match the literal IANA string into C-code, which
>> does not allow a "-" symbol.
>
> Hmm, it’s like version -10 all over again:
> http://www.ietf.org/rfcdiff?url1=draft-irtf-cfrg-chacha20-poly1305-09&url2=draft-irtf-cfrg-chacha20-poly1305-10

Good :)

>> 	The problem is that if future advances in cryptanalysis reveal a
>> 	weakness in AES, VPN users will be in an unenviable position.  With
>> 	the only other widely supported cipher being the much slower 3DES,
>>
>> I'm not sure if that is completely true. We do have Camellia, although
>> I'm not a cryptographer and it might be too similar to AES. So I still
>> agree with the sentiment of the text.
>
> There are several algorithms that exist, and even quite a few that are defined for IPsec. But none are as universally implemented as 3DES and AES. So as a developer I can implement Camellia (and I have no idea about its speed relative to AES), but as a user with an existing version of some software that has to interoperate with some other user of some other version of some other software, only with AES and 3DES it’s safe to assume that we can achieve interoperability.

The point is, you cannot predict that chacha20/poly1305 will become
widely supported either. Regardless, I don't care that much about this
bit of text, so if you want to leave it as-is that's fine.

>> 	The length of the ciphertext as a 32-bit network order quantity.
>>
>> Can we clarify the number of octets used here without needing to go into
>> another reference document?
>
> Mmm, 4?   Network order is the controversial part, because everything else in ChaCha20 is little-endian.

It would be good for implementors to see that number in this document.

>> Although perhaps we can go back to CRFG and ask if they can give us
>> something that is not based on the SHA2 family?
>
> Why don’t you like SHA2?  Is it about the performance or just a general dislike of NIST algorithms?

I see this as a category ciphers that are non-NIST, grass-roots. So it
would make logical sense not to depend no an SHA2/SHA3 family.

> Anyway, perhaps you’d like blake2 better:
> http://tools.ietf.org/html/draft-saarinen-blake2-01

Seeing that blake2 is based on chacha, I do think that is a better fit
to use compared to sha2.

> Still seems like a shame to brink that in just for the PRF.

The C code is in the RFC, it's not that hard to bring in :P

>> I have no strong opinions about Diffie-Hellman groups.
>
> Perhaps Curve25519 after CFRG finish recommending it.

That would make sense.

Paul