Carelessness versus craftsmanship in cryptography

Even high-level libraries like crypto_secretbox still take the nonce separately. They do have a combined mode that prepends the authentication code to the cipher text, and most people who just want to encrypt something should probably look at a higher-level interface like this one instead of directly using raw AES libraries.

That being said, providing an interface where the IV is optional and the default value is a constant instead of random is still insane. That wouldn't be out of place in some Underhanded Crypto Contest where the goal is to create subtle bugs.

It is very rarely necessary to prepend an IV to the cipher text, because normally every application provides something that is useful as an IV, e.g. some unique serial number or some other kind of unique identifier.

For instance, I have an archive of data stored on tape cartridges. I have on my computer a database that allows me to search for information stored on the tapes, which tells me e.g. that the file that I want is in "Tape 174 file 103".

Each tape cartridge (6 TB per cartridge LTO-7) stores about 120 files of 50 GB each, inside which the actual archived data reside.

The archive files are encrypted. Both the 256-bit decryption key and the 128-bit CTR IV are generated simultaneously with a one-way hash function (SHA-384) by hashing some secret data (which is not used for any other purpose) concatenated with the unique name of the file, e.g. "Tape 174 file 103". Thus for any of the encrypted files, both the AES key and the CTR IV are unique and never shared with any other kind of encrypted data.

An AES-CTR encryption/decryption function, e.g. for AES-GCM, should always have separate input parameters for key & IV, without default values, to allow you to use whatever is more suitable in your environment for deriving them.

Hashing a combination of secret data and unique data, like in the example above, is usually a good method for deriving a pair of key and IV for file encryption. For things like encrypting packets of a communication connection, the key is derived only once, to avoid the overhead of switching keys and only the IV changes from packet to packet. Standards like GCM specify how this should be handled. If the value of the IV is known to an adversary, that is normally not harmful, but it is even better when the adversary does not know the value of the IV. (Cryptographic algorithms are designed to resist attacks where the attacker has maximum information, but in practice you also try to minimize the information available to the attacker.)

The case pointed out in the article-- strongMan-- definitely didn't deal with uniform random data, which is why the encryption was broken, not brittle. But if you DO have a bunch of uniform random keys encrypted using CTR mode with the same key and IV, the XOR of any two of them won't tell you much, because the XOR of random values is random.

However, if any of those encrypted keys wind up compromised, it's game over for ALL the keys. Not broken, but definitely brittle.

I understand not loving GCM or GCM-SIV; they definitely aren't perfect. I also agree that CTR+HMAC is just fine in a lot of situations, especially if you're careful enough to derive separate HMAC keys and encryption keys. CTR+HMAC also has the advantage of being key-committing, which gives me the warm fuzzies.

Still, GCM and GCM-SIV have their use cases, especially in performance-sensitive situations. Given the widespread adoption of AEAD modes, I think failing to include GCM in an AES implementation is an indicator that a library is out of date and ought to be treated with caution.

For a security related issue? Not sure that is a wise decision.