AES Text Encryption

What do PBKDF2 iterations get you?

Passwords that people memorize are too short and predictable to be used as AES keys. So instead of using the password directly, we use PBKDF2 to process it extensively and derive a 256-bit key. The iteration count is the number of times this processing is repeated.

Here’s the key idea: when you increase the iteration count, you only wait once, but an attacker has to wait that long for *every single password guess*. At 250,000 iterations, the number of guesses an attacker can try per second is reduced by a factor of roughly 250,000. You're trading less than a second of your time to force an attacker to spend 250,000 times as much.

What happens without a salt and an IV?

It can be confusing why these are necessary, since both are non-secret random numbers. They serve completely different roles.

Without a salt, the same password always produces the same key. This allows an attacker to pre-compute the keys for millions of common passwords and store them in a lookup table (a 'rainbow table'). When they see a ciphertext, they can just look up the key and find the answer instantly. Even a million iterations won't help you here—that computation was finished long ago. A unique salt for each encryption makes this entire pre-computation effort worthless.

The IV prevents the same plaintext from always producing the same ciphertext. If the IV were fixed, the ciphertext for a short reply like "Yes" would always be the same, allowing an observer to read patterns of who said what without knowing the content. In AES-GCM specifically, reusing an IV with the same key is a catastrophic failure that goes beyond simple pattern exposure and can allow an attacker to recover both plaintexts.

When 'Decryption failed' appears — The role of the authentication tag

AES-GCM doesn't just encrypt; it also creates and attaches a 16-byte authentication tag. During decryption, it recalculates this tag and checks if it matches. If even a single bit is off, it refuses to output a result and fails. This prevents an attacker from tampering with the content by, for example, flipping a few bits in the ciphertext. Successful decryption is a guarantee that the content has not been forged or altered.

The trade-off is that the failure message can't distinguish the cause. A wrong password and a tampered ciphertext both result in the same tag verification failure. This is by design; providing a more specific error would give hints to an attacker.

• The most common cause is a truncated copy. You must paste the entire ciphertext from beginning to end. If you copy from a messaging app where the text is collapsed under a "Show more" link, the end might be cut off.
• If you paste it into the body of an email, the mail client might add line breaks or convert parts of it into links, corrupting the string. Sending it as a file attachment is safer.
• Check for leading/trailing spaces and case sensitivity in the password. A stray space accidentally copied along with the password is a frequent culprit.
• Make sure the mode is set to '🔓 Decrypt' and that you have pasted the ciphertext into the input field, not the plaintext.

Password strength comes first

If your password is `1234`, even a million iterations won't save you. An attacker only needs to try ten guesses. A million iterations × 10 guesses is a matter of seconds. The iteration count is only a meaningful defense when the password itself is reasonably strong.

Conversely, a passphrase made of four random words (like the one the `Load Example` button provides) is easy to remember but has a vastly larger search space. This is why the tool shows a warning after encrypting if your password is less than 8 characters long.

What to use this tool for (and what not to)

This tool runs entirely in your browser; nothing is ever sent to a server. This makes it suitable for handling sensitive information you wouldn't entrust to a third party, like internal memos or temporary account credentials. However, it's not a silver bullet.