The draft currently has all three: standalone ChaCha, standalone Poly1305, and AEAD.
Standalone Poly1305 has the issue that it requires a one-time key or a nonce to generate it, but ESP only allows an IV for the cipher, not for the MAC. The draft deals with it by using the replay counter as a nonce, but then changes APIs. That is one reason why some people are opposed to standalone Poly1305. Yoav On Mon, Mar 10, 2014 at 10:43 AM, Daniel Migault <[email protected]>wrote: > Hi, > > My understanding is that Poly1305 and chacha20 are provided as > "alternatives" to SHA* or AES*. Specific devices with AES > accelerations may be willing, for performance optimization, to use > Poly1305 instead of SHA with AES. For this reason it might be better > to have: > - chacha20 as a stand-alone cipher > - Poly1305 as a stand-alone MAC > > On the other hand, providing the AEAD chacha20-poly1305 may be helpful > for end users or admins. Especially if security consideration > recommends AEAD. Would it bring too much complexity to also define > AEAD chacha20-poly1305? > > BR > Daniel > > > > On Mon, Mar 10, 2014 at 9:15 AM, Yoav Nir <[email protected]> wrote: > > > > > > > > On Mon, Mar 10, 2014 at 8:00 AM, Yaron Sheffer <[email protected]> > > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > -- > Daniel Migault > Orange Labs -- Security > +33 6 70 72 69 58 >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
