Encrypt & Decrypt Text

What actually happens

Your password is not the encryption key. Passwords are short and guessable; AES needs 256 bits of proper key material. So the password goes through a key derivation function first:

1. A random 16-byte salt is generated for this message.
2. The password and salt run through PBKDF2-SHA256, 310,000 iterations, producing a 256-bit key.
3. A random 12-byte nonce is generated.
4. The message is encrypted with AES-256-GCM using that key and nonce.
5. Salt, nonce and ciphertext are packed together and Base64-encoded so the result survives being pasted into an email.

The salt means the same password produces a different key for every message. The nonce means the same message encrypted twice looks entirely different. The iteration count means an attacker guessing passwords does 310,000 hashes per attempt instead of one.

Why GCM rather than plain AES

GCM is authenticated encryption. As well as hiding the content, it detects tampering: change a single byte of the ciphertext and decryption fails outright rather than producing plausible-looking garbage.

That matters more than it sounds. Without authentication, an attacker who can't read your message may still be able to alter it in predictable ways. With GCM, a wrong password and a tampered message produce the same result, refusal.

The part that is actually your problem

The cipher is not the weak point. Two things are:

Your password. AES-256 is unbreakable in practice; "summer2024" is not. An attacker doesn't attack the algorithm, they guess the password. Use a long passphrase. Four or five random words beats a short complicated string, and is far easier to read down a phone line. The password generator makes them.

How you share it. Sending the encrypted message and the password in the same email achieves nothing whatsoever. Anyone with access to that inbox has both halves. Use genuinely separate channels: message by email, password by phone. Or agree a password in person beforehand.

When this is the right tool

• Putting something sensitive into a channel you don't control, a shared document, a ticketing system, a note-taking app.
• Emailing a credential or a reference number where you can phone the password through separately.
• Storing a note in a place you don't fully trust, a synced notes app, a cloud file.
• Sending something where the recipient can't install anything and needs to open it in a browser.

When it isn't

• Ongoing private conversation. Use a dedicated end-to-end encrypted messenger. It handles key exchange, forward secrecy and identity verification, none of which a password does.
• Files. This encrypts text. For files, use archive encryption or full-disk encryption.
• Anything where losing access is unacceptable unless the password is backed up somewhere safe. There is no recovery path.
• Regulated data: health records, payment details. Where compliance requires documented, audited systems.

There is no recovery

Worth stating plainly, because people are used to password resets. If you lose the password, the message is unrecoverable. Not "difficult to recover". Mathematically gone. That property is the entire point, and it applies to you exactly as much as to anyone else.

Before encrypting anything you need back, write the password down somewhere you'll still have it in a year.