* 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 Weimer <[email protected]> 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 [email protected]
