AES-GCM-SIV: Specification and Analysis [pdf]

1. A distinct message-based format (ie not streaming)

2. Protection against modified plaintext/malleable ciphertext without a separate MAC/signature construct (this protection can extend to some "attached" plaintext called "associated data")

3. Multiple entities making encrypted messages that cannot necessarily communicate with each other to negotiate safe nonces (for example, a server farm, or in distributed computing)

As such, it would not be the best choice for file encryption.

-----

In more detail: AES-GCM-SIV has three parts: AES, GCM, and SIV.

AES is a (some might say the) choice for symmetric encryption. In general, symmetric encryption is ultimately used for any and all content that you encrypt; asymmetric encryption is used almost exclusively with other cryptographic primitives, because it is very slow in comparison (among other issues). Cryptosystems like PGP make it seem like you're using asymmetric encryption on content by going like this:

    asymmetric_encrypt(symmetric_key) + symmetric_encrypt(content, symmetric_key)

GCM is one (again, some might say the) choice for "authenticated encryption with associated data", or AEAD. It is a more sophisticated construct than "simple" encryption, in that it also asserts that the ciphertext (and, optionally, some attached in-the-clear plaintext, for example, metadata) was encrypted by someone who had the symmetric key to the data. This is important, because otherwise, the ciphertext is "malleable" -- that is to say, an active attacker could modify the ciphertext without discovery by the client. This can be a big problem; an easy example why is this scenario:

1. Imagine an encrypted "on/off" boolean value for a lightbulb. Alice (client) sends True for "on" to Bob (lightbulb), and Mallory (the active attacker) intercepts the message 2. Mallory knows the format of the plaintext because she has the same kind of lightbulb. She flips the bit in the ciphertext that corresponds to the on/off value, and then transmits the modified message to Bob 3. Bob successfully decrypts the message, sees Mallory's "off" command, despite Mallory never knowing the encryption key for the message, and turns himself off

GCM solves this problem in a way that is analogous to combining a MAC construct with the AES encryption, in one integrated primitive. You could do these separately, and for a long time that's what the industry standard was, but it's easy (and catastrophic) to screw up, so there's been a substantial movement towards AEAD primitives instead.

Finally, SIV ("synthetic initialization vector"). GCM (and a number of other block modes) require an initialization vector, or IV. No key + IV combination can ever be used twice; if it is, the plaintext of both messages is fairly trivially recoverable. AKA, total system failure, equivalent to no encryption, etc. It is difficult to understate the severity of this; it's a really, really big deal to reuse the same key and IV combination. The problem that SIV seeks to solve is one where you have a bunch of different sources for the IV, and you can't necessarily guarantee their uniqueness. Traditionally, you would choose a random IV from a very large set of values to avoid the birthday paradox (you're basically relying on random chance to avoid reusing the IV+key, but because the selection space is so large, you're extremely confident it won't be a problem). But this doesn't always work; the linked paper gives an example of a server cluster running Google's new QUIC protocol, which would be subject to IV birthday collisions during a DDoS attack.

SIV is part of a relatively new area termed "nonce reuse resistance" or "nonce misuse resistance". These constructs seek to protect against accidental IV reuse, as in the birthday collision above, by constructing the IV from the plaintext of the message. The idea is that, if you accidentally reuse the same key + IV, by definition, you must also have the same plaintext -- resulting in an identical ciphertext, which protects the contents of the message. As such, you can safely use AES in an AEAD block mode, in a stateless distributed system, without worrying about two different protocol instances accidentally reusing the same key + IV combination (which would, again, break everything).

Disclaimer: this is significantly simplified for the purposes of explanation.

Does this mode entirely derive the IV from the plaintext or do you provide a nonce that's also mixed in? (So the chances of nonce reuse + same message = reused IV are even lower?) Could you not do the same kinda thing just with GCM by using an IV plus hash of the plaintext?