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
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
