[AES-GCM] Add Key Commitment

[commial]

As described in ¹ and ², AES-GCM does not ensure "key commitment", ie.

ciphertext should only decrypt to a valid plaintext under the key used to generate the
ciphertext

In other words, an attacker could force the recipient to decrypt the ciphertext with a wrong key. Even if the obtained cleartext won't be the original one, it could mislead the user -- which might think it is -- or help reach potentially vulnerable code.

MLA is a target similar to the "Envelope Encryption" section in ¹: for a given ciphertext, several recipients must obtain the same plaintext.
Given the format of MLA, this attack is unlikely to be exploitable: one would have to forge a correct footer, which is several bytes long, while keeping "interesting" values in it.

But following the "better be safe than sorry" philosophy, especially regarding the cryptographic part, the following changes are proposed:

1. based on the "padding fix" idea in ¹, add a 512-bits (2x256 bits for 256bits security) long fixed chain at the beginning of the cryptographic layer (encrypted)
2. on key decapsulation, the chain is decrypted and compared to the original one. Operations continues only if the chain is correct

The chain is at the beginning to ensure repair will still work. Adding an expected clear-text of 512-bits ensure the key used is the expected one (otherwise, it would means that 2 keys decrypt the same ciphertext to the same cleartext under AES-256).

Drawbacks:

• This addition increase the size of the resulting archive. But a 512-bits addition seems to be negligible in the current uses of MLA
• It requires an update of the format, at least of the layer, which is a breaking change
• It gives a decryption oracle (one can test if one key is the correct one), but the key space is expected to be large enough and others decryption oracles (for instance, files contents and their hashes) already exists in MLA

Footnotes

1. "How to Abuse and Fix Authenticated Encryption Without Key Commitment", Usenix'22 ↩ ↩² ↩³

2. "Fast Message Franking: From Invisible Salamanders to Encryptment" ↩

[commial]

Fixed by #209