Re: Encryption and authentication modes
Florian Weimer wrote: 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. As David [McGrew] mentioned -- thanks, David -- I've been working towards drafting a proposal for standardizing encrypt-then-authenticate generic composition, and David [McGrew, again] has been quite generous in sharing his work in this area. Working towards this is one aspect of our work (Vincent Rijmen and I) in making cryptography easier to get right at the implementation level, so that its true potential can be realized in practice. Developers shouldn't be making cryptographic decisions, which is one of the driving forces behind our push for standardizing encrypt-then-authenticate generic composition; they needn't be burdened with addressing the subtleties that go along with composite authenticated encryption schemes. The desire to push for this was born out of green cryptography, which Vincent and I introduced in IEEE Security Privacy last year. The premise behind green cryptography was to recycle cryptographic primitives whenever and wherever possible, and do so in a way that not only minimizes implementation complexity, but maximizes cryptographic security. What we ended up with is AES-based encrypt-then-authenticate (e.g., AES-CBC-then-AES-CMAC); this achieves the strongest notions of confidentiality and integrity per Bellare and Namprempre (i.e., IND-CCA2 /\ INT-CTXT) and -- here's the best part -- it's the easiest for developers to get right, since it is secure for all possible secure instantiations of its constituent primitives. If we are to standardize encrypt-then-authenticate generic composition, we would most likely have to include support for SHA-1, SHA-2, and SHA-3; this isn't exactly in line with the recycling paradigm, but a necessary compromise in regards to support across the board. You can get the same security out of AES-CMAC and SHA-*-HMAC, either way. Still, it's important to limit the number of options available, since the more options you have, the more complexity you introduce to the implementation. Perhaps having a standard that supports AES-CBC/AES-CTR-then-AES-CMAC/SHA-*-HMAC would work; this is where community feedback is really useful, since such a standard needs to be as flexible as it is secure. Any thoughts? I've recently spoke with Steve Weis and Ben Laurie at Google, who put together the open-source Keyczar (keyczar.org) cryptographic toolkit, aimed at making cryptography safe and simple for developers to use; they did say, however, that oftentimes, they found themselves backed into a corner with allowing configurations that may be secure, and reasonable, for niche applications, but insecure elsewhere -- in other words, no good for standards. I mention Keyczar because it may be something of interest to you, and I think it serves as a progressive model for the direction we need to be going in -- making cryptography easier to get right. You're absolutely right that you shouldn't have to worry about the details, and that it is easy to misuse. That needs to change. In closing, I'll mention that green cryptography's design paradigm of do a lot with a little; less is more has found its way into a conceptual framework we're working on, dubbed Mackerel, which looks at abstracting away as much of the cryptography as possible and, instead, focus on the higher level concepts of confidentiality and integrity, and why they're mutually necessary. Just as green cryptography is concerned with the assurance of cryptographic implementations, Mackerel is concerned with the tightness of the interface between cryptography and cryptographers, developers, and users. We're drawing a lot from the field of HCIsec, or Human Computer Interaction Security -- of which another Googler, Alma Whitten, is a pioneer*. So, that's a snapshot of what we -- Vincent Rijmen and I -- have been up to over the past couple of years, and I look forward to sharing more as it develops and evolves. I had hoped to have a draft together earlier, but it just wasn't in line with the workload and pace over the past few months; it does appear that I'll have something together by the end of August, which is a plus. We're wide open to thoughts on this. * http://gaudior.net/alma/johnny.pdf - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
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
Florian Weimer writes:
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 wrote such a thing for web developers, and other people have too.
I can't see a reason to do anything other than
ciphertext = aes_cbc(enc-key, random-iv, plaintext)
sealed-blob = hmac(mac-key, ciphertext + timestamp) +
ciphertext + timestamp
You wrap this magic up in a trivial interface:
byte [] seal(byte [] macKey, byte [] encKey, byte [] plaintext)
throws GeneralSecurityException
{ ... }
byte [] unseal(byte [] macKey, byte [] encKey, byte [] ciphertext,
long expirationInterval)
throws UnexplodedCowException
{ ... }
You can find my Java code with a google search, but it's not special. You
can write it yourself in your favorite language with small effort.
This gives you expiration, integrity, and confidentiality. You can make the
keys implicit by getting them from the server config variables or something.
In case of mangled or expired ciphertext, the checking function can fail
fast (no need to decrypt, since you do the hmac check first).
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Encryption and authentication modes
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. Thanks for explaining the use case. In addition to the dedicated AEAD modes (e.g., CCM, EAX, GCM) that you already know about, you might look at encrypt-then-authenticate. It might make a nice and simple solution for this particular use case. In EtA, you encrypt with any secure encryption scheme, then append a MAC that covers the entire ciphertext (including the IV). For instance, AES-CBC + CMAC is a fine combination. It's pretty simple to implement. 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. I'm afraid that, for full security, secure encryption does require either randomness or state. The technical slogan is deterministic encryption schemes are not semantically secure. A more down-to-earth way to say it is that if you use a deterministic, stateless encryption scheme to encrypt the same message twice, you'll get the same ciphertext both times, which leaks some information to an eavesdropper. In some applications that might be OK, but for a general-purpose encryption scheme, one might arguably prefer something that doesn't have such an unnecessary weakness. A weaker goal is graceful degradation: a weak random-number source should not cause a catastrophic loss of security. Some modes of operation are more robust in the face of repeated or non-random IVs; e.g., CBC mode is more robust than CTR mode. Is obtaining proper randomness hard on your platform? On most desktop/server platforms, it is easy: just read from /dev/urandom. If it's hard, there are various hardening schemes you can use to reduce your dependence upon randomness. I don't know whether they're worth the effort/complexity/performance loss; that depends upon your usage scenario. For instance, one cute hardening step you can do is to pick a separate secret key for a PRF (e.g., CMAC), and then hash a random value together with the message itself to obtain the IV for the encryption mode. e.g., to encrypt message M: Encrypt(M): 1. IV = CMAC(K0, random || M) 2. C = AES-CBC-Encrypt(K1, IV, M) 3. T = CMAC(K2, IV || C) 4. return IV || C || T (If you don't like storing 3 separate keys, use standard key separation techniques: K0 = CMAC(K, 0), K1 = CMAC(K, 1), K2 = CMAC(K, 3).) Of course, this hardening scheme does have a performance impact. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Encryption and authentication modes
* 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. 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
Re: Encryption and authentication modes
* james hughes hugh...@mac.com wrote: If there is no room for or an integrity field, you can look at XTS-AES. http://csrc.nist.gov/publications/nistpubs/800-38E/nist-sp-800-38E.pdf A not so well-known statement of said PDF certainly is the following, especially in light of today's storage device capacities: The length of the data unit for any instance of an implementation of XTS-AES shall not exceed 2^20 AES blocks. It seems to have made it smartly into openbsd, at least this commit-info hints it: http://marc.info/?l=openbsd-cvsm=121341266715025 -- left blank, right bald pgpjXNpaGVZ6T.pgp Description: PGP signature
Encryption and authentication modes
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), 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
Re: Encryption and authentication modes
On Jul 14, 2010, at 1:52 AM, Florian Weimer 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), 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? If there is no room for or an integrity field, you can look at XTS-AES. http://csrc.nist.gov/publications/nistpubs/800-38E/nist-sp-800-38E.pdf Are there any traps should be aware of when implementing CCM? CCM is a counter mode cipher, so don't reuse the count (with any reasonable probability). Jim - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Encryption and authentication modes
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), 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. Some technically good candidates for standards adoption, E.G. OCB met resistance due to licensing issues. DJ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
