This is my understanding of Synthentic IVs

You have 2 keys $K_1$ & $K_2$.

$F$ is a PRF

Instead of choosing a separate IV, you instead generate the IV from the PlainText.

$IV = F(K_1, m)$
$c = E(K_2, m, IV)$

You don't need a separate Tag/Hash for authentication. Because the IV is generated using the PT itself, after decrypting the CT, you can generate the IV at the decryption end & check it it's same as IV send along with the CT.

I was looking at AES-GCM-SIV - https://tools.ietf.org/html/rfc8452

Here the IV seems to be passed as Input to the Encryption Algorithm & is not generated from the PT.

AES-GCM-SIV encryption takes a 16- or 32-byte key-generating key, a 96-bit nonce, and plaintext and additional data byte strings of variable length.

It also seems to produce a tag

Calculate S_s = POLYVAL(message-authentication-key, X_1, X_2, ...). XOR the first twelve bytes of S_s with the nonce and clear the most significant bit of the last byte. Encrypt the result with AES using the message-encryption key to produce the tag.

So why is this Encryption named as an SIV scheme?


The SIV that you describe is the way that it is often specified specifically for key wrap. However, you always want to have an IV since encryption of the same message twice should yield different ciphertexts. If you only derive the IV from the message and key, then it will always be the same for the same message. By deriving the effective IV from the input IV, message and key, you guarantee that different messages and different IVs always give different ciphertexts, and the only "flaw" is when the same message is encrypted twice with the same IV (and in this case, only that fact is revealed). This is optimal nonce-reuse resistance.

Note that an IV is input to AES-GCM-SIV, but it is used to derive an "effective" IV from the tag, that is actually used to encrypt the message. The continuation in the RFC that you quoted is "The encrypted plaintext is produced by using AES, with the message- encryption key, in counter mode (see [SP800-38A], Section 6.5) on the unpadded plaintext. The initial counter block is the tag with the most significant bit of the last byte set to one." (Note that the initial counter block is the tag...)

AES-GCM-SIV also does continual key derivation from the input IV in order to get better security bounds. However, that is an orthogonal issue.

  • $\begingroup$ So, the tag is encrypted using AES & that is used as the IV? From this block diagram on this page - cyber.biu.ac.il/aes-gcm-siv - is appears as the tag is generated on the PT rather than the CT. Isn't that bad - i.e. you need to decrypt before authenticating? $\endgroup$ – user93353 Feb 16 at 8:11
  • 1
    $\begingroup$ The tag is generated on the plaintext and not the ciphertext. Indeed, it is better in principle to generate it on the ciphertext. However, that would force you to do 3 passes over the plaintext (for full nonce-misuse resistance you already need to make 2 passes). Note that although in general MAC-then-encrypt is not a good strategy and can even be completely broken, it doesn't mean that dedicated authenticated encryption algorithms cannot work this way (e.g., CCM works this way). $\endgroup$ – Yehuda Lindell Feb 16 at 8:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.