On Mon, Mar 10, 2014 at 8:00 AM, Yaron Sheffer <yaronf.i...@gmail.com>wrote:
> Hi Yoav, > > Can you explain why we need Poly1305 at all? We have SHA-2 and will > probably adopt Keccak (SHA-3), so it's not like we don't have a backup. > Sure. Poly1305 is fast.Faster than SHA-1, SHA-2, and Keccak. I haven't compared it to GMAC on Intel, but that is fast only becuase it has special Intel instructions like PCLMULQD. Both ChaCha and Poly1305 can be fast in a plain C implementation, so they're fast on any platform. Poly1305 needs another algorithm to generate the per-message keys. That could be AES as in DJB's original paper, or it can be ChaCha as in this draft (with or without the AEAD). > Let me suggest that we adopt *only* ChaCha20, which can be combined with > any integrity protection algorithm in the normal ESP way. Is there any > extra value (maybe code sharing?) in predefining an AEAD? > The AEAD version is already in at least one crypto library (NSS as used in Chrome) and there's a patch that AGL donated to OpenSSL (not in there yet). So in addition to AEADs being fashionable, this combination makes sense for performance, especially on non-Intel platforms. Yoav
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
