Re: Encryption and authentication modes
Hi Florian, On Jul 23, 2010, at 1:14 AM, Florian Weimer wrote: * David McGrew: can I ask what your interest in AEAD is? Is there a particular application that you have in mind? I just want to create a generic API which takes a key (most of the time, a randomly generated session key) and can encrypt and decrypt small blobs. Application code should not need to worry about details (except getting key management right, which is difficult enough). More popular modes such as CBC lack this property, it's too easy to misuse them. I suppose a superficially similar primitive is contained in Bernstein's NaCl library. I was intrigued by its simplicity, but the cryptographic algorithms it uses are a bit non-standard. RFC 5116 sounds perfect. It might be worthwhile to publish a C API for that interface, along with detailed documentation. That would be fairly straightforward; I think the only complexity is supporting an incremental init/update/final interface. For your application, it sounds like you don't need the incremental API. thanks, David Right now, I would probably use it to forward session state through browser URLs in areas which are not actually security-relevant. Somewhat more sensitive applications are possible in the future. In no case I expect adversaries to actually have access to ciphertext. To some degree, it's about being able to say yes, we use encryption for X, and it's algorithm Y, and I want to do it right without using CMS or modern OpenPGP, with all the complexities that come with that. When I said that CCM wasn't widely implemented, I was referring to the fact that none of the cryptographic libraries on my system supports it directly. This is a pity because once you fix the parameters, it's much simpler to use safely than pure encryption modes. There seems to be one downside with the CCM instance specified towards the end of the NIST standard, though: If you on an architecture where sizeof(size_t) == 8, then your encryption function isn't total because it can't accept the full range of possible input lengths---or you end up with just 64 bit for the tag, which seems to be a bit on the small side. I'm not sure if this is a compelling reason to use EAX or GCM, though---especially since we're strictly limited to 31 bit array length in some places by software and not hardware (so this limitation will be in place for a long time). A mode which does not rely as much on proper randomness for the IV would be somewhat nice to have, but it seems that the only choice there is SIV, which has received less scrutiny than other modes. OCB is very attractive in software, but GCM is more efficient in hardware because it can be implemented without pipeline stalls. GCM can perform well in software, though it can't be as compact as CCM, and it excells with SIMD (http://eprint.iacr.org/2009/129) or modest hardware support like Intel's new PCLMULQDQ instruction (http://www.drdobbs.com/security/218102294;jsessionid=GMTY4RCFLHBMRQE1GHOSKHWATMY32JVN?pgno=3 ). Interesting. But it will take about five years until our crypto code would make use of a new hardware instruction, assuming that we'd implement all the necessary pieces right now (thanks to desynchronized software release cycles at several layers of the software stack). Speed is of no particular concern anyway. Increase in message size is somewhat relevant (think about the URL case I mentioned), but only to up to a degree. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Encryption and authentication modes
Hi Florian, can I ask what your interest in AEAD is? Is there a particular application that you have in mind? DJ provided a good summary of CCM and GCM. To add some follow-on to that, RFC 5116 defines an interface to an AEAD algorithm, and a registry of such algorithms. TLS 1.2 ties into this interface, though currently only GCM is defined in TLS. Both GCM and CCM are defined for use in IPsec, and GCM is in Suite B. The other AEAD algorithm that's been defined is SIV mode; AFAIK it has not been in any standards to date. On Jul 14, 2010, at 10:22 AM, d...@deadhat.com wrote: What's the current state of affairs regarding combined encryption and authentication modes? I've implemented draft-mcgrew-aead-aes-cbc-hmac-sha1-01 (I think, I couldn't find test vectors), The motivations for aead-aes-cbc-hmac-sha1 were 1) to match legacy situations in which only the older algorithms are available, and 2) to define an AEAD algorithm that does not need a unique IV (a randomized algorithm in the terms of RFC5116). The draft could probably be re-spun to better meet goal #1, though I am not sure how important that goal is. In general, it would be valuable to have a randomized algorithm, though it would be preferable to have one that met the higher performance standard of GCM, which anything CBC based won't meet. More recently Justin Troutman has expressed an interest in possibly carrying forward work on generic composition; I've copied him. but I later came across CCM and EAX. CCM has the advantage of being NIST-reviewed. EAX can do streaming (but that's less useful when doing authentication). Neither seems to be widely implemented. But both offer a considerable reduction in per-message overhead when compared to the HMAC-SHA1/AES combination. Are there any other alternatives to consider? Are there any traps I should be aware of when implementing CCM? -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com CCM is widely implemented. It's a matter of where you look. Down at the MAC layer, AES-CCM has proved popular in wireless packet communication because it is well adapted for separating the treatment of the header as plaintext AAD from the packet body as ciphertext. Also it is relatively efficient to implement in hardware since it relies only on a single AES encrypt block cipher and the birthday resistance of the ciphertext MAC reduces on-air per packet overhead. This is the why for example that you see AES-CCM in wireles USB, 802.11, 802.16 and WiMAX management protocols. A couple of years after 802 went for AES-CCM, AES-GCM became the 802.3/ethernet choice since it is more parallelizable and so can be implemented for 10Gbps+ links where CCM becomes trickier. The per packet overhead is higher, but bandwidth on wires is cheap. I don't think you can really implement CCM except in the context of a more detailed specification for a protocol. CCM is a flexible specification and protocols that use it must nail down a number of parameters and field sizes in order to be interoperable. It's not so easy to just plug it in which makes is less convenient for the more pluggable software based protocols higher up the stack. That's true, though there are some particular CCM parameter choices made in http://www.iana.org/assignments/aead-parameters/aead-parameters.xhtml Some technically good candidates for standards adoption, E.G. OCB met resistance due to licensing issues. OCB is very attractive in software, but GCM is more efficient in hardware because it can be implemented without pipeline stalls. GCM can perform well in software, though it can't be as compact as CCM, and it excells with SIMD (http://eprint.iacr.org/2009/129) or modest hardware support like Intel's new PCLMULQDQ instruction (http://www.drdobbs.com/security/218102294;jsessionid=GMTY4RCFLHBMRQE1GHOSKHWATMY32JVN?pgno=3 ). regards, David DJ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
