# Is it possible to recover AES-GCM plaintext when having everything but the additional data?

I'm using the window.crypto library in browsers.

I use iv from window.crypto.getRandomValues, key from window.crypto.subtle.generateKey, and additionalData from a user-input password.

After the encryption, I store iv, key, and encrypted_content in the local storage.

If someone gets these three things, is it possible for them to crack it without additionalData?

AES-GCM internally directly uses the given key for AES-CTR mode, without performing any derivation. The initial counter for that mode relies only on the IV/nonce; given the recommended default of a 12 byte IV, the IV/nonce is used directly as well. So there is absolutely nothing preventing an attacker to decrypt the message when the attacker gets hold of the key. The additional data is required for calculating the right authentication tag, but it doesn't influence the decryption at all. Putting a password in the additional data does, for that reason, not ensure confidentiality of the message.

The authentication tag also relies on the same key for security. Although the attacker may not be able to verify correctness of the authentication tag, it would be possible to append data to the message undetected (decrypting the last GHASH result, then continuing the GHASH calculation and finally encrypting the result again - basically performing a length extension attack). The resulting plaintext may not match the expected result, but it depends on the protocol if it would generate an error and if that error indicates tampering. So putting a password in the additional data does, for these reasons, not provide integrity or authenticity of the message.

As for any symmetric cipher, losing the key is fatal. Using a password based key derivation function (a.k.a. password hash) such as Argon2 - as cipherfox correctly identifies - is best. Use the resulting value as key and another part of the result as IV. Even then, the strength of the password is fundamental to the security provided by the password hash.

• Notably argon2i and not argon2d. Maybe argon2id for hybrid defence and performance. – cypherfox Mar 12 '18 at 14:29
• I didn't specify it any further because I think that it is detrimental to security if the password function is just copied without any justification. The user should learn about password hashes themselves and not rely on a single recommendation here. Oh, and I voted up your answer, but I think that the explanation on why decryption would succeed and that the ciphertext / plaintext could be altered required another answer. – Maarten Bodewes Mar 12 '18 at 15:22
• Fair. You could have edited mine to extend the verbosity ;-) – cypherfox Mar 12 '18 at 15:43
• Comments are not for extended discussion; this conversation has been moved to chat. – SEJPM Mar 13 '18 at 17:04

GCM is an authenticated wrapper around CTR mode. The authenticated data is only considered when verifing the authentication tag - after decrypting the data.

If your adversary has the $(\text{iv}, \text{key}, \text{ciphertext})$ they can recover the $\text{message}$ but they cannot detect tampering.

I recommend that you use Argon2i with a user's passphrase, running inside a WebWorker instead of the main thread such that you do not freeze the browser while computing the key. Do not store the key in localstorage. Similarly, do not store the key in any globally accessible variables I.e. not in window.mysecretkey!

Libsodium has an argon2i implementation and has been compiled to JavaScript/asm.js and WebAssembly.