Encryption and authentication modes

[David Wagner]

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 majordomo at metzdowd.com