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