# Using HMAC as a nonce with AES-CTR encrypt-and-MAC

Suppose I use the following encrypt-and-MAC construction:

$$E(k_1, k_2, n, m) = E_\text{AES256-CTR}(k_1, n, m) \| \text{HMAC-SHA256}(k_2, m)$$, where:

$$k_1$$ and $$k_2$$ are 256-bit keys

$$n$$ is a nonce

$$m$$ is an arbitrary-length message.

What security losses occur if I use the MAC as the nonce? (i.e. $$n = \text{HMAC-SHA256}(k_2, m)$$, but truncated to the appropriate length) Are there any other disadvantages to this scheme compared with typical authenticated encryption, e.g. AES-GCM?

Clearly, this scheme is distinguishable under chosen plaintext attack, since the same plaintexts always encrypt to the same ciphertexts. This is acceptable in my application, but I'm interested to know if there are other problems.

What you're describing is pretty similar to the SIV block cipher mode. It also uses a deterministic function of the message to derive the nonce for CTR encryption. Under some pretty widely accepted assumptions about HMAC-SHA256 this is a perfectly fine way of achieving deterministic authenticated encryption. It doesn't meet IND-CPA (as you pointed out) but if this is acceptable for your application, you should be fine.

Disadvantages are mostly in terms of efficiency. The mode you propose requires two passes of the plaintext to generate a ciphertext, but GCM only requires one. A mode like OCB also only requires one pass for authenticated encryption, but is parallelizable as well. The impact of this is, again, dependent on your application.

• Please note that you can in fact parallelize GCM although it's not as easy as with OCB. And note further that GCM takes overall (encryption + authentication) ~1.5 passes (one full encryption + one field multiplication per block) while OCB only requires one.
– SEJPM
Nov 29 '15 at 13:23
• @SEJPM, "1.5 passes" doesn't really make sense IMO. The main difference compared to SIV is that they only need to make a single pass over the data (e.g. allowing a streaming interface), during which they do more than just one cipher invocation per block. The fact that OCB's additional work is lighter is a minor difference, even if sometimes important.
– otus
Nov 29 '15 at 13:39
• Is this also okay using ChaCha20-Poly1305?
– Demi
Dec 17 '15 at 8:12
• Ummmm.... Probably, as long as Poly1305 doesn't have some weird property that I'm not aware of. You just need to make sure your MAC is also a PRF in your adversarial setting. Dec 18 '15 at 1:43