Text Encryptor

Encrypt the same text twice — the output should differ

That is the one check anyone can run on a tool like this, and it is the check that matters. Encrypt a message, encrypt the identical message again, and compare the two outputs. If they match, the tool is reusing its nonce, and that is a serious problem rather than a cosmetic one.

AES-GCM works by generating a keystream from the key and a nonce — a number used once — and combining it with your message. Reuse the nonce with the same key and two things follow. The obvious one is that identical messages produce identical output, so an observer can see you sent the same thing twice without decrypting anything.

The second is much worse. Both messages get the same keystream, so combining the two outputs cancels it out completely and leaves the two original messages combined with each other. Encrypting "attack at dawn" and "attack at dusk" under a repeated nonce and combining the results gives exactly this:

0000000000000000000000140405

That is byte-for-byte the two plaintexts combined — no key was recovered, and none was needed. The 11 leading zeros say the two messages share their first 11 characters, which is already a real leak. And two messages combined this way are separable with ordinary language statistics; if an attacker knows or guesses one of them, they get the other exactly.

This tool generates a fresh 12-byte nonce and a fresh 16-byte salt for every single encryption, so the same input produces different output every time — verified on each build, along with the control that a fixed nonce really does reproduce the leak above. The nonce is not a secret, incidentally, and does not need to be: it is stored in the clear alongside the ciphertext. It only needs to be different every time.

What the extra bytes are for

The output is always longer than the input by a fixed amount, whatever the message length:

Those 16 bytes are an authentication tag, and they buy something specific: tampering is detected rather than silently producing different text. Flip a single bit anywhere in the ciphertext and decryption fails outright instead of returning plausible-looking garbage. Without it, an attacker who cannot read your message can still change it, which is often the more dangerous of the two.

The other cost is deliberate slowness. Your passphrase is not used as a key directly — it is stretched through 150,000 rounds of PBKDF2 first, which makes guessing 150,000 times more expensive per attempt. That is why encrypting takes a noticeable moment, and the moment is the feature.

Being straight about the limits, though: none of this rescues a weak passphrase. Key stretching multiplies the attacker's cost by a constant; a short or common passphrase divides it by very much more. This is a reasonable way to put something in a text file or an email that a casual reader should not see. It is not a reason to trust a three-word password with anything that would genuinely hurt to lose.