Authenticated Encryption

It turns out that doing symmetric encryption (in any mode) without authentication leads to many practically exploitable vulnerabilities, which are serious enough to have the following rule:

Tip: Symmetric encryption must be authenticated encryption (AE).

There are some cases where symmetric encryption alone might be sufficient, but you have to be a cryptography expert to recognize and analyse them, which you are not. Always use AE for symmetric encryption. There is yet another cryptographic zoo of various AE modes. All these modes are single-key—the same secret key that is used for encryption is also used to provide authentication, which is nice. Unfortunately, you should stay away from all these single-key AE modes, for two reasons.

One reason is that while two of the NIST-approved AE modes are implemented by the Microsoft CNG API, none of them are available in the .NET Framework (as of .NET 4.6.1). The other reason is that both of these CNG-implemented AE modes are counter-based, meaning you are responsible for ensuring that the counter never repeats. Microsoft’s own ASP.NET Security Team contemplated which AE approach to take with ASP.NET 4.5, and decided not to use the single-key AE modes (documented on their blog).

The alternative to a single-key AE mode is a dual-key AE mode, which adds the extra complexity of using two separate keys (one for encryption and one for authentication) instead of a single key, and is also not as fast as some single-key AE modes. On the positive side, however, a dual-key AE mode is acceptably fast (fast enough), proven to be secure, and is easy to implement. This dual-key AE mode standard is encrypt-then-MAC (EtM), ISO-19772.

The EtM encryption process is fairly simple:

1. AES-encrypt plaintext P with a secret key K_e and a freshly-generated random IV to obtain ciphertext C₁.
2. Append the ciphertext C₁ to the IV to obtain C₂ = IV + C₁.
3. Calculate MAC = HMAC(K_m , C₂) where K_m is a different secret key independent of K_e.
4. Append MAC to C₂ and return C₃ = C₂ + MAC.

The EtM decryption process is also simple:

1. If input C length is less than (expected MAC length + expected AES IV length), abort.
2. Read MAC_expected = last-MAC-size bytes of C.
3. Calculate MAC_actual = HMAC(K_m , C-without-last-MAC-size bytes).
4. If BAC(MAC_expected , MAC_actual) is false, abort.
5. Set IV = (take-IV-size bytes from start of C). Set C₂ = (bytes of C between IV and MAC).
6. AES-decrypt C₂ with IV and K_e to obtain plaintext P. Return P.

The ISO-19772 specification of EtM only authenticates the ciphertext C₁ and does not authenticate the IV. In the ISO EtM encryption spec, C₂ is equal to C₁ and not to IV + C₁. We believe this to be a specification flaw. ISO‑19772 only states the obvious: “…[IV] shall be distinct for every message to be protected during the lifetime of a key, and must be made available to the recipient of the message.” Just follow the EtM process shown previously.

EtM Key derivation

EtM uses two separate keys—encryption key K_e and MAC key K_m—which need to come from somewhere. However, we still want to avoid the complexity of dual-key management, and instead wish to use a single, secret “master key” from which we can securely derive K_e and K_m. This calls for HKDF or SP800_108_Ctr.

Since you often cannot guarantee the non-reuse of the master key (SKM), the EtM encrypt and decrypt methods should take an optional salt, which will be used by HKDF to generate salted flavors of K_e and K_m. If the master key already has non-reuse safeguards (e.g., randomly generated or salted PBKDF2-derived), then the HKDF salting is not necessary.

Primitive choices

Let’s summarize all primitive choices for a solid EtM implementation:

Table 6: Summary of good EtM choices

Unlike hashes, n-bit HMAC construction is not susceptible to birthday attacks and provides n bits of security. Using more than 128 bits of HMAC-SHA-512 or HMAC-SHA-384 for a MAC digest is overkill because it increases the EtM ciphertext size with little security gain. You could use more than 128 bits for a MAC if you have other requirements, as long as you understand that there is no security-motivated argument to do so. Complete EtM implementation is available in the Inferno crypto library.

Length leaks

Most encryption modes leak some information about the plaintext length, since longer ciphertext typically implies longer plaintext. Padding modes contribute to this problem by adding one extra padding block when the plaintext length is a multiple of the block size. A 16-byte plaintext would get padded to 32 bytes with an extra 16-byte padding block during AES-CBC encryption, while a 15-byte plaintext would get padded to 16 bytes only. If plaintext length confidentiality is required, you could (reversibly) pad all plaintext to the same length prior to encryption. This is often impractical for a variety of reasons (for example, knowing all possible plaintext lengths up front), so it is best to avoid dependency on plaintext length confidentiality.

Common mistakes

Here is a non-exhaustive list of common symmetric encryption mistakes you should learn to recognize:

• Not using an unpredictable IV in CBC mode (IV is calculated somehow, or reused)
• Using symmetric encryption without authenticated encryption (i.e. MAC is not included)
• Using authenticated encryption but forgetting to include IV as part of MAC
• Not using two independent keys for EtM (same key or dependent keys)
• Using a non-cryptographically-strong RNG (for example, using System.Random() instead of CSP-based RNG)
• Improperly deriving master key from SKM (for example, hashing a user-provided password)
• Not using salt (correctly, at all, or using too much—for example, more than 128 bits)
• Using silent fallback with UTF encodings or using UTF-based encodings instead of string serialization
• Not using constant-time byte array equality comparisons
• Using obsolete .NET crypto primitives still available in .NET (MD5, RC2, DES, etc.)