Great questions—AES-256-GCM is a rock-solid choice for secure authenticated encryption, but getting these details right is critical to avoiding security gaps. Let’s break down each of your questions clearly:

1. Is the salt from salt = crypto.randomBytes(64) just pseudo-random data, and does it only exist to make cracking harder? #

First off, that salt isn’t just pseudo-random—it’s cryptographically secure pseudo-random (CSPRNG) data, since Node.js’s crypto.randomBytes() uses your system’s trusted random number generator (like /dev/urandom on Unix or CryptGenRandom on Windows).

Its main job is tied to key derivation (if you’re using something like pbkdf2 or scrypt to turn a password into a 256-bit AES key, which you absolutely should be). Without a unique salt, every time you use the same password, you’d end up with the exact same AES key. That’s a huge risk because attackers could use precomputed rainbow tables to crack your keys quickly.

By using a unique salt for each encryption operation, even the same password will generate a unique AES key every time. This eliminates rainbow table attacks entirely and forces attackers to brute-force each encrypted blob individually, which is exponentially harder. So yes, it does boost cracking resistance—but its core role is to ensure key uniqueness per encryption.

2. What’s the actual purpose of the IV in crypto.createCipheriv('aes-256-gcm', key, iv), besides changing the ciphertext’s appearance? And do I need a new IV every time? #

The IV (Initialization Vector) is way more than a "cosmetic" change. AES-GCM is a block cipher mode, and the IV ensures that identical plaintext blocks encrypted with the same key produce different ciphertext blocks. Without an IV, if you encrypt the same plaintext twice with the same key, you’d get identical ciphertexts—this leaks information about your data (e.g., an attacker could tell you’re sending the same message repeatedly).

In GCM specifically, the IV also plays a role in generating the authentication tag (more on that in the next question).

Yes, you absolutely need a new IV every single time you encrypt something with the same key. The IV doesn’t need to be secret (you can store/transmit it alongside the ciphertext and tag), but it must be unique for each encryption with the same key. Reusing an IV with GCM breaks the security of the entire algorithm—attackers can recover plaintext bits or even forge valid ciphertexts.

3. What is the tag from tag = cipher.getAuthTag();, and why do we need it? #

That tag is GCM’s authentication tag, which makes AES-GCM an AEAD (Authenticated Encryption with Associated Data) algorithm. Here’s why it matters:

When you encrypt with GCM, the cipher generates this tag by combining the IV, ciphertext, and any associated authenticated data (AAD, if you use it) with the AES key. During decryption, you pass this tag to decipher.setAuthTag(tag) before calling decipher.final().

The tag serves two critical purposes:

• Integrity verification: It ensures the ciphertext hasn’t been tampered with (e.g., an attacker changed a byte of the ciphertext). If the ciphertext is modified, the tag verification will fail, and Node.js will throw an error instead of returning corrupted plaintext.
• Authentication: It proves that the ciphertext was actually created by someone who holds the correct AES key. This prevents attackers from sending fake ciphertexts that your application might mistakenly decrypt as valid data.

Without verifying the tag, you’re missing half of GCM’s security benefits—you’d get encryption but no way to confirm the data hasn’t been altered or forged.

内容的提问来源于stack exchange，提问作者KomentaS