Re: [IPsec] ChaCha20 Poly1305, AEAD and other modes
On Mon, Mar 10, 2014 at 8:00 AM, Yaron Sheffer yaronf.i...@gmail.comwrote: 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
Re: [IPsec] ChaCha20 Poly1305, AEAD and other modes
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 ynir.i...@gmail.com wrote: 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 -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] ChaCha20 Poly1305, AEAD and other modes
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 mglt.i...@gmail.comwrote: 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 ynir.i...@gmail.com wrote: 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 -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] ChaCha20 Poly1305, AEAD and other modes
On Sun, 9 Mar 2014, Yoav Nir wrote: Some people in the room said that we should only do the AEAD and skip the stand-alone algorithms. This would prevent SAs with combinations such as ChaCha20 + HMAC-SHA1 or AES-128-CBC + Poly1305. I'm not saying whether we need or don't need these combinations. I don't see much use for them personally. My question to the list now is whether everyone agrees that it's fine to drop them and leave only the combined mode algorithm in the draft. Yes. We have too many algorithms in IKE already. If we believe that combined mode algorithms are better than classic ENCR+INTEG algorithms, and I think we do, than we should not be adding more old style ENCR+INTEG algorithms. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] ChaCha20 Poly1305, AEAD and other modes
Yoav Nir writes: Hi draft-nir-ipsecme-chacha20-poly1305 currently specifies three transforms: 1. chacha20 as a stand-alone cipher 2. Poly1305 as a stand-alone MAC 3. ChaCha20-Poly1305 as an AEAD. Some people in the room said that we should only do the AEAD and skip the stand-alone algorithms. This would prevent SAs with combinations such as ChaCha20 + HMAC-SHA1 or AES-128-CBC + Poly1305. I would suggest only keeping the AEED. For example AES-128-CBC + Poly1305 does not make any sense, especially if the Poly1305 is still defined to use ChaCha20 to generate keying material for the Poly1305, i.e. AES-128-CBC + Poly1305 will need to implement ChaCha20 too... We also already have multiple quite ok MACs and I assume we will have more when SHA3 stuff goes through, so there is no need for standalone Poly1305. There might be some uses for standalone ChaCha20, but I think it would be more important to keep things simple, and just define one thing and that would be AEAD mode. I'm not saying whether we need or don't need these combinations. I don't see much use for them personally. My question to the list now is whether everyone agrees that it's fine to drop them and leave only the combined mode algorithm in the draft. BTW, One the questions I had there that as the Poly1305 requires separate key for each invocation and the draft uses ChaCha20 to generate key, but if I have understood correct the way it generates the key only gives out random unpredictable keys, but it does not generate unique keys. If I understood correctly the original Poly1305 document used AES in a way which did generate unique keys for each poly1305 invocation. The draft-nir-cfrg-chacha20-poly1305 says the The pair (r,s) should be unique, and MUST be unpredictable Should we add some text there explaining why the way in draft-nir-ipsecme-chacha20-poly1305 is ok, i.e. that even when we truncate the 512 bit output and only take 256 bits of it, the propability of using same key twice is negligible. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] AES key lengths: draft-ietf-ipsecme-esp-ah-reqts
Paul On Mar 8, 2014, at 8:08 AM, Black, David david.bl...@emc.com wrote: The next draft changes AES-128-CBC to AES-CBC, and says: In the following sections, all AES modes are for 128-bit AES. 192-bit AES MAY be supported for those modes, but the requirements here are for 128-bit AES. What about 256-bit AES keys? They should also be a MAY. Why not “SHOULD” for 192 and 256 bit keys? paul It's good to remember the reason that 256-bits keys for AES were specified, i.e., as a hedge against someone building a quantum computer. So, unless the data being encrypted is expected to have a lifetime far enough into the future as to merit protection against that concern, the extra time needed to perform AES-256 vs. AES-128 does not seem justified. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] AES key lengths: draft-ietf-ipsecme-esp-ah-reqts
On Mar 10, 2014, at 12:05 PM, Stephen Kent k...@bbn.com wrote: Paul On Mar 8, 2014, at 8:08 AM, Black, David david.bl...@emc.com wrote: The next draft changes AES-128-CBC to AES-CBC, and says: In the following sections, all AES modes are for 128-bit AES. 192-bit AES MAY be supported for those modes, but the requirements here are for 128-bit AES. What about 256-bit AES keys? They should also be a MAY. Why not “SHOULD” for 192 and 256 bit keys? paul It's good to remember the reason that 256-bits keys for AES were specified, i.e., as a hedge against someone building a quantum computer. So, unless the data being encrypted is expected to have a lifetime far enough into the future as to merit protection against that concern, the extra time needed to perform AES-256 vs. AES-128 does not seem justified. Steve That’s a good argument for a user choosing to use AES-128 rather than AES-256. But it doesn’t really address why “SHOULD implement” isn’t justified — the implementation cost is trivial and if it isn’t used it has no performance impact. paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] AES key lengths: draft-ietf-ipsecme-esp-ah-reqts
On Mon, 10 Mar 2014, paul_kon...@dell.com wrote: That’s a good argument for a user choosing to use AES-128 rather than AES-256. But it doesn’t really address why “SHOULD implement” isn’t justified — the implementation cost is trivial and if it isn’t used it has no performance impact. It's not the implementation cost that matters. It is the GUI confusion. For example one vendor uses aes as aes128, and another vendor uses aes for aes256 (or aes_ctr or aes_cbc or aes_gcm). Each option we expose needlessly to the enduser is one more potential interop issue. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] AES key lengths: draft-ietf-ipsecme-esp-ah-reqts
On Mar 10, 2014, at 12:45 PM, Paul Wouters p...@cypherpunks.ca wrote: On Mon, 10 Mar 2014, paul_kon...@dell.com wrote: That’s a good argument for a user choosing to use AES-128 rather than AES-256. But it doesn’t really address why “SHOULD implement” isn’t justified — the implementation cost is trivial and if it isn’t used it has no performance impact. It's not the implementation cost that matters. It is the GUI confusion. For example one vendor uses aes as aes128, and another vendor uses aes for aes256 (or aes_ctr or aes_cbc or aes_gcm). Each option we expose needlessly to the enduser is one more potential interop issue. True. But if you assume sufficiently foolish GUI designs, just about anything can be hard to use. And I don’t think that good crypto design should be put at the mercy of people who can’t design a decent UI. We know that it’s possible to get this right. paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] AES key lengths: draft-ietf-ipsecme-esp-ah-reqts
Paul, ... It's good to remember the reason that 256-bits keys for AES were specified, i.e., as a hedge against someone building a quantum computer. So, unless the data being encrypted is expected to have a lifetime far enough into the future as to merit protection against that concern, the extra time needed to perform AES-256 vs. AES-128 does not seem justified. Steve That’s a good argument for a user choosing to use AES-128 rather than AES-256. But it doesn’t really address why “SHOULD implement” isn’t justified — the implementation cost is trivial and if it isn’t used it has no performance impact. paul I have been told by some commercial security consultants that their customers believe that bigger is more secure, and thus they should mandate use of longer key lengths if they are available. If that report is accurate, then making AES-256 a SHOULD (vs. a MAY) creates a situation where the performance penalty will be incurred, for no good reason. But, I'm not going to fall on my sword for this. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
