Here is an history of the Synthetic IV mode of operation which has been two things:
- a key-wrapper algorithm: that was the main motivation. The point of a key wrapping algorithm is that you do not need to "randomize" the encryption with a nonce (since the key is already random), but you do want to keep the authentication of AEADs.
- an authenticated cipher that is nonce-misuse resistant: if you use AES-GCM with the same (key, nonce) pair twice, an attacker can then steal the authentication key (and probably forge messages). Using the same (key,nonce) pair twice with SIV only renders the encryption deterministic (so an attacker will notice if a plaintext is encrypted twice).
There has been many versions of SIV, the most promising is the one being standardized by Google and named AES-GCM-SIV.
- 2006 - Rogaway - Deterministic Authenticated-Encryption: A Provable-Security Treatment of the Key-Wrap Problem
- 2007 - Rogaway - The SIV Mode of Operation for Deterministic Authenticated-Encryption (Key Wrap) and Misuse-Resistant Nonce-Based Authenticated-Encryption
- 2008 - D. Harkins - Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES)
- 2015 - Shay Gueron and Yehuda Lindell - GCM-SIV: Full Nonce Misuse-Resistant Authenticated Encryption at Under One Cycle per Byte'
- 2017 - Shay Gueron and Adam Langley and Yehuda Lindell - AES-GCM-SIV: Specification and Analysis
- 2018 - N. Madden - Synthetic IV (SIV) for non-AES ciphers and MACs
- 2019 - Shay Gueron and Adam Langley and Yehuda Lindell - RFC-draft - AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption
A reason for doing key wrap (DAE) instead of conventional (probabilistic) AE is the intuition that, if the plaintext carries a key, there shouldn’t be any need to inject additional randomness into the encryption process.
We emphasize that our formalization of DAEs includes a header (also called a tweak or associated-data). For cryptographic practice, allowing a header seems to be almost essential. Network security protocols require sending packets only portions of which are encrypted, but all of which must be authenticated and bound together. Good security practice requires keys to be bound to control information such as expiration date and permitted usage, and the binding of keys to such control information has strongly informed security architecture (eg, IBM’s cryptographic control vectors [25]). Regarding headers as vectors facilitates both efficiency advantages and a cleaner abstraction boundary.
We are specifically concerned with IV-misuse, meaning that the IV is used in a way other than the way mandated by the scheme; for example, using a counter when the scheme requires a random value, or repeating an IV when the scheme requires it to be a nonce. Experience has shown that IVs are frequently mishandled. An encryption scheme robust against misuse should at least be an AE scheme (as programmers, protocol designers, and even books often assume that encryption provides for authenticity) and so we will treat IV-misuse within the context of authenticated encryption and not privacy-only encryption. The notion is applicable to the latter context, too.
Designing an IV-based AE scheme that is secure when its IV is an arbitrary nonce—not just when it is a random value—is a first move in the direction of making schemes robust against IV-misuse
We want the encryption oracle to return bits that look random except when this is impossible—on a repeated triple of (header, IV, message)—and the decryption oracle should return ⊥ except when the triple is already known to have a valid decryption. For simplicity, assume as before that our IV-based encryption scheme is length-preserving
How these schemes work:
Rogaway also wrote this rap song:
Yo! We’z gonna’ take them keys an’ whatever you pleaze
We gonna’ wrap ’em all up looks like some ran’om gup
Make somethin’ gnarly and funky won’t fool no half-wit junkie
So the game’s like AE but there’s one major hitch
No coins can be pitched there’s no state to enrich
the IV’s in a ditch dead drunk on cheap wine
Now NIST and X9 and their friends at the fort
suggest that you stick it in a six-layer torte
S/MIME has a scheme there’s even one more
So many ways that it’s hard to keep score
And maybe they work and maybe they’re fine
but I want some proofs for spendin’ my time
After wrappin’ them keys gonna’ help out some losers
chronic IV abusers don’t read no directions
risk a deadly infection If a rusty IV’s drippin’ into yo’ veins
and ya never do manage to get it exchanged
Then we got ya somethin’ and it comes at low cost
When you screw up again not all ’ill be lost