Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
The line that changes the output is the one that supplies a fresh initialization vector (IV, also called a nonce) to each encryption call. With AES-GCM, the same password can produce a different ciphertext every time only when the IV is new for every encryption, and when the key is derived with a per-password salt. Neither value is secret, but both must be stored so the data can be decrypted later.
Where the uniqueness actually comes from
People often expect a single function call to do the trick. In practice, two separate inputs do two separate jobs, and mixing them up is the most common source of confusion.
| Input | When it is used | Must be unique? | Secret? | Stored with the ciphertext? |
|---|---|---|---|---|
| Salt | While deriving the encryption key from the password | Yes, per password (or per derivation) | No | Yes, or retrievable metadata |
| IV / nonce | Each time the encryption operation runs | Yes, for every encryption under the same key | No | Yes |
| Password | Only during key derivation | Not applicable | Yes | No, it must not be stored in plain form |
The MDN reference for AesGcmParams puts the IV requirement plainly: the IV “does not have to be secret, just unique,” and it “must be unique for every encryption operation carried out with a given key.” That means the same password, run through a salt-based derivation, yields the same key, and only the IV changes the output on each run.
Recommended Free Tools
The encryption step, line by line
In the browser’s Web Crypto API, the encryption call looks like this:
#1 Best Overall
- ✅ PROTECT ONLINE ACCOUNTS – A password manager, two-factor security key, and secure communication token in one, OnlyKey can keep your accounts safe even if your computer or a website is compromised. OnlyKey is open source, verified, and trustworthy.
- ✅ UNIVERSALLY SUPPORTED – Works with all websites including Twitter, Facebook, GitHub, and Google. Onlykey supports multiple methods of two-factor authentication including FIDO2 / U2F, Yubico OTP, TOTP, Challenge-response.
- ✅ PORTABLE PROTECTION – Extremely durable, waterproof, and tamper resistant design allows you to take your OnlyKey with you everywhere.
- ✅ PIN PROTECTED – The PIN used to unlock OnlyKey is entered directly on it. This means that if this device is stolen, data remains secure, after 10 failed attempts to unlock all data is securely erased.
- ✅ EASY LOG IN –No need to remember multiple passwords because by plugging OnlyKey to your computer, it automatically inputs your username and password. It works with Windows, Mac OS, Linux, or Chromebook, just press a button to login securely!
const iv = crypto.getRandomValues(new Uint8Array(12));
const ciphertext = await crypto.subtle.encrypt({ name: "AES-GCM", iv }, key, plaintext);The 12-byte array is 96 bits, the length MDN recommends for AES-GCM. The syntax itself does not create uniqueness. The uniqueness comes from generating a new array for each encryption. If the same iv is reused with the same key, the guarantee breaks. Decryption then needs the identical bytes:
const plaintext = await crypto.subtle.decrypt({ name: "AES-GCM", iv }, key, ciphertext);MDN’s deriveKey() example shows this pattern end to end: a PBKDF2-derived AES-GCM key, a salt, and the same IV passed to decryption.
Rank #2
- POWERFUL SECURITY KEY: The YubiKey 5 NFC is the most versatile physical passkey, protecting your digital life from phishing attacks. It ensures only you can access your accounts
- WORKS WITH 1000+ ACCOUNTS: Compatible with popular accounts like Google, Microsoft, and Apple. A single YubiKey 5 NFC secures 100+ of your favorite accounts, including email, password managers, and more
- FAST & CONVENIENT LOGIN: Plug in your YubiKey 5 NFC via USB and tap it, or tap it against your phone (NFC), to authenticate. No batteries, no internet connection, and no extra fees required
- MOST SECURE PASSKEY: Supports FIDO2/WebAuthn, FIDO U2F, Yubico OTP, OATH-TOTP/HOTP, Smart card (PIV), and OpenPGP. That means it’s versatile, working almost anywhere you need it
- PRIMARY & SPARE KEYS: Just like having a spare house key, we recommend buying two YubiKeys - one for daily use and one as a spare. That way you’ll never get locked out of your accounts
How the password becomes a key
Password-based encryption runs in two stages, and each one has its own inputs.
- Derivation. The password, a password-based key derivation function (KDF), a salt, and the KDF parameters produce the encryption key. The same password with a different salt produces a different key.
- Encryption. The key, the plaintext, and a fresh IV produce authenticated ciphertext.
- Decryption. The password is run through the same KDF with the same salt and parameters to rebuild the key, and the stored IV is passed to the decrypt call.
If your design derives a new key for every message, each derivation should use a new salt. You still need a fresh IV for each encryption, because the rule applies per key and per operation. A unique salt and a unique IV are not interchangeable, and one does not replace the other.
Rank #3
- FIDO2 & Passkey Ready: Business-ready and FIDO2 L1 certified. This key is supported by major management suites and is ideal for both individual and enterprise deployment. Works seamlessly with Gmail, Facebook, GitHub, Dropbox, Coinbase, and more.
- Dedicated Manager App: Use the Thetis Manager App for the initial hardware PIN setup. Setting the PIN on the device first ensures a smooth registration process. Once the PIN is configured, you can begin registering the key across your favorite FIDO2-compatible online services.
- Universal Connectivity (USB-C, USB-A, & NFC): Designed for PCs, Macs, iPhones, and Android. For mobile use, simply unfold the key, align it with your phone’s NFC antenna, and hold for a few seconds to authenticate.
- Enhanced MFA (FIDO2 & TOTP/HOTP): Strengthen your security with flexible options. Use the Manager App to access TOTP/HOTP features for accounts that do not yet support FIDO2.
- Check FIDO2 compatibility before purchase - Known limitations: ID Austria is not supported (requires FIDO2 Level 2). Windows Hello login only works with Windows Enterprise editions that support Entra ID. NFC is supported only through mobile authentication, Not MacOS/windows.
The Python cryptography documentation makes the same point for its password-based Fernet example: the salt must be kept, because without it the key cannot be reproduced. Its current guidance recommends Argon2id for deriving keys from passwords.
What to store alongside the ciphertext
Nothing in this design requires secrecy for the salt, the IV, or the KDF settings. What is required is that they survive until decryption. A practical record usually holds:
Rank #4
- USB-C or tap via NFC for easy authentication on any compatible device. No drivers needed; optional Kensington software available for advanced management features.
- Works across Windows, macOS, iOS, Android, ChromeOS, and supports Passkeys and Apple ID.
- Slim, keychain-ready form for easy carry and on-the-go authentication
- IP68-rated for dependable performance
- FIDO CTAP 2.1 for enhanced security features (e.g. resident credentials, Passkey support) and backwards compatibility with CTAP 2. FIDO2 L2 certified security for phishing resistant protection against identity theft and unauthorized access.
- The ciphertext (including or alongside the authentication tag, depending on the library’s output format).
- The IV used for that specific encryption.
- The salt used for key derivation.
- The KDF identifier and its parameters, such as the algorithm name and iteration or memory settings.
- A format or version field, so future code can tell which scheme produced the data.
The exact layout is an implementation choice. Many libraries bundle these values into one blob, and that is a reasonable approach as long as the decryption side parses it the same way.
Why authenticated encryption matters here
OWASP’s Cryptographic Storage Cheat Sheet recommends authenticated modes such as GCM or CCM where they are available, and advises against building custom algorithms. GCM does more than hide the plaintext: it also detects whether the ciphertext has been modified. A tampered ciphertext fails to decrypt rather than returning altered data. That is why GCM is the mode behind this article’s example, and why the IV rule matters so much. Reusing an IV under GCM is not a cosmetic problem; it weakens the guarantees the mode is supposed to give.
Best Value
- Ultra-Compact FIDO2 Security Key - Plug-and-stay or carry on a keychain. This USB-A hardware security key offers portable, always-on protection for desktop and mobile use. (Item Size: 0.75 X 0.74 IN x 0.25 IN)
- USB-A Hardware Key for All Devices - Works with USB-A ports on PC, Mac, Android, and other laptop/notebook device. Enables secure, cross-platform login with FIDO2.0 passkey support.
- FIDO Certified Security Key - Meets FIDO and FIDO2 standards. Works with Google, Microsoft, GitHub, Dropbox, and more. Please check service compatibility before purchase.
- Passwordless Login with Passkey - Supports passkey login via WebAuthn and CTAP2. Enjoy password-free sign-ins where supported. Not all websites or services currently support passkeys.
- Advanced Multi-Factor Authentication - Offers 200 FIDO2 passkey slots and 50 OATH-TOTP slots. Strong, flexible 2FA/MFA support across various apps and authentication platforms.
Common mistakes
- Hard-coding one IV. A constant IV makes identical messages encrypt identically under the same key.
- Assuming the password changes each output. The password is an input to key derivation. Output varies because of the salt (for new keys) and the IV (for each encryption), not because of the password.
- Discarding the salt or IV after encryption. The data becomes unrecoverable, even with the correct password.
- Treating the IV as a secret. Hiding it adds nothing and can cause loss of data when it is misplaced.
- Relying on a weak password. A KDF makes offline guessing more expensive, but it does not turn a weak password into a strong one. An attacker who has the ciphertext and the salt can still try candidate passwords.
Password storage is a different job
Encrypting data that must later be recovered is not the same as storing a login password. Login verification should use a one-way slow password-hashing algorithm with a unique salt, as described in OWASP’s Password Storage Cheat Sheet. Nobody should need to decrypt a stored login password, so reversible encryption is the wrong tool for that task. Keep the two designs separate in code and in documentation.
Limits of what is established
- MDN and OWASP establish the uniqueness requirement and the 96-bit recommendation for AES-GCM IVs. Neither gives a collision probability for random 96-bit IVs or a safe maximum number of encryptions per key. Use your library’s current guidance and the relevant standard for operational limits.
- No single KDF configuration is universal across platforms. Choose parameters from current guidance for your target environment, and treat the stored parameters as part of the record.
- A unique IV guarantees different ciphertext for repeated encryption under the same key. It does not, by itself, protect a weak password or a leaked key.
In short, an encryption that looks different each time reflects correct handling of both the salt and the IV, and the design still needs authenticated encryption and well-tested library code.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
