Encrypt Text

Which ciphers are available?

Caesar: each letter is shifted a fixed number of positions. ROT13: equivalent to Caesar with shift 13 (self-inverse). Atbash: replaces each letter with its opposite in the alphabet (A↔Z, B↔Y).

Base64: encodes binary as ASCII text (it is encoding, not encryption). Use it to transport bytes through text-only environments.

These ciphers are broken in seconds by frequency analysis. Do not use them for real data protection — use modern cryptography (AES-GCM).

Cryptography in depth: how modern encryption protects text and data

Encryption is the mathematical process of transforming readable information (plaintext) into an unintelligible form (ciphertext) so that only authorised parties holding the correct key can recover the message. Cryptography went through three large eras: the classical period of substitution and transposition ciphers, the symmetric era kicked off by DES in the 1970s, and the modern public-key era started by Diffie-Hellman in 1976 and the RSA paper in 1978. The tool above lets you play with toy ciphers (Caesar, ROT13, Base64 framing), but real-world security is built on a much more careful stack of primitives, modes and parameters. This page documents that stack.

Symmetric vs asymmetric cryptography

In symmetric systems, the same secret key encrypts and decrypts; it must be shared securely beforehand. Symmetric primitives are very fast, often hardware-accelerated via Intel AES-NI, and handle arbitrary-length data when paired with the right mode. The downside is the key-distribution problem.

Asymmetric cryptography gives each participant a key pair: a public key anyone can know and a private key that stays secret. Anything encrypted with the public key can only be decrypted with the matching private key; digital signatures work in reverse. Asymmetric algorithms are several orders of magnitude slower and have strict size limits, so they are almost never used for bulk data — instead they exchange a fresh symmetric session key (TLS handshake) or sign a document hash.

Modern systems combine both: asymmetric for key establishment and identity, symmetric for the heavy lifting. TLS 1.3, Signal, age, SSH, OpenPGP, FileVault and BitLocker all follow this hybrid pattern.

AES: the Advanced Encryption Standard

AES is the symmetric block cipher that dominates the planet. It was selected by NIST in 2000 after a five-year public competition, standardised as FIPS 197 in 2001, and replaced DES. AES operates on 128-bit blocks and supports three key sizes: 128, 192 and 256 bits, with 10, 12 and 14 rounds respectively. Both AES-128 and AES-256 are safe today; AES-256 gives a meaningful margin against quantum cryptanalysis via Grover's algorithm.

A block cipher alone encrypts only a single 128-bit chunk. To encrypt a longer message you need a mode of operation:

• ECB encrypts each block independently. Identical plaintext blocks produce identical ciphertext blocks (the "ECB penguin"). Never use ECB.
• CBC XORs each block with the previous ciphertext block. Hides patterns but is malleable and vulnerable to padding-oracle attacks without authentication.
• CTR turns the block cipher into a stream cipher via an incrementing counter. Parallelisable, no padding — but no integrity by itself.
• GCM combines CTR with a polynomial MAC and produces an authentication tag. AEAD construction, modern recommendation for nearly all cases.

IV / nonce: why reuse is catastrophic

Every AES mode except ECB needs a fresh, non-secret parameter called an initialization vector (IV) or nonce. For AES-GCM the nonce is 96 bits and must be unique for every encryption with the same key. If you encrypt two different messages with the same key and the same nonce in GCM, the attacker can XOR the ciphertexts to learn the XOR of the plaintexts and recover the authentication subkey — letting them forge arbitrary messages. This has hit production systems repeatedly (notably WinZip AES).

Two safe strategies: generate a random 96-bit nonce with a CSPRNG for every message, or use a deterministic counter. In the browser, crypto.getRandomValues(new Uint8Array(12)) produces a secure random IV.

Key Derivation Functions: turning passwords into keys

Human passwords have very little entropy (30 to 50 bits), while AES expects a uniformly random 128 or 256-bit key. A Key Derivation Function (KDF) bridges the gap: it takes a password plus a random salt and produces a key, while deliberately being slow so brute force is expensive.

• PBKDF2 (RFC 2898) iterates HMAC-SHA-256 hundreds of thousands of times. FIPS-approved but memory-cheap, so GPUs and ASICs accelerate attacks.
• scrypt (RFC 7914) is memory-hard, forcing attackers to provision RAM.
• Argon2 (RFC 9106) won the 2015 Password Hashing Competition. Use Argon2id with at least 19 MiB, two iterations and one degree of parallelism.

Common modern algorithms

• AES-GCM (128 / 256) — symmetric AEAD, hardware-accelerated, TLS 1.3 default.
• ChaCha20-Poly1305 — stream-cipher AEAD by Daniel J. Bernstein, faster than AES on CPUs without AES-NI. Used by TLS 1.3, WireGuard, OpenSSH.
• RSA-OAEP / RSA-PSS — asymmetric, 2048-bit minimum (3072+ recommended).
• EdDSA (Ed25519) — elliptic-curve signatures; deterministic and immune to nonce-reuse failures.
• X25519 / ECDH — elliptic-curve key agreement, modern replacement for finite-field DH.

Web Crypto API: encrypting in the browser

Browsers expose a native, audited stack through window.crypto.subtle, available only over HTTPS or localhost. The API is asynchronous and returns Promises. A minimal AES-GCM encryption looks like this:

const key = await crypto.subtle.generateKey(
  { name: "AES-GCM", length: 256 },
  false,
  ["encrypt", "decrypt"]
);
const iv = crypto.getRandomValues(new Uint8Array(12));
const ct = await crypto.subtle.encrypt(
  { name: "AES-GCM", iv },
  key,
  new TextEncoder().encode("hello world")
);
// store iv alongside ct (iv is public, not secret)

To derive a key from a password, use crypto.subtle.deriveKey with PBKDF2 (Web Crypto does not ship Argon2; use a libsodium WASM build if needed).

What encryption does not hide

Encryption protects content, not metadata. An attacker on the wire still observes message length, timing, frequency, source and destination addresses, and conversation size pattern. Traffic-analysis against encrypted VoIP can recover spoken phrases, and the length of a TLS request reveals which page on a known site was loaded. If metadata matters, add padding, traffic shaping or mix networks (Tor) — not just stronger AES.

Practical use cases

• User passwords: never encrypt — hash with Argon2id (or bcrypt / scrypt). Encryption is reversible; hashing is not.
• Files at rest: AES-256-GCM with a per-file random nonce and a key derived from the user password via Argon2id.
• Messages between people: use a vetted protocol such as the Signal Protocol (double-ratchet, X3DH, Ed25519) rather than rolling your own.
• Bearer tokens / JWT: sign with EdDSA or HMAC-SHA-256; only encrypt the payload (JWE) if it carries secrets.
• Backups: envelope encryption — one data key per file, wrapped by a KMS-managed master key.

FAQ

Is AES-256 better than AES-128? Both are secure today. AES-256 has a larger safety margin against future and quantum cryptanalysis, but is roughly 40% slower. For most apps AES-128 is enough.

Can I reuse the same IV if the message is the same? No. GCM security depends on never reusing a nonce with the same key. Generate a fresh random IV every time.

Should I store passwords encrypted? No. Hash them with Argon2id or bcrypt. Hashes cannot be recovered if your database leaks; encrypted passwords can if the master key leaks.

Will quantum computers break AES? Grover's algorithm cuts brute-force time from 2^n to 2^(n/2): AES-128 becomes 64-bit (weak), AES-256 becomes 128-bit (still strong). RSA and ECC are fully broken by Shor's algorithm, hence post-quantum schemes like ML-KEM and ML-DSA standardised by NIST in 2024.

Is the Caesar cipher in this tool useful for real security? No — it is purely educational. Caesar, ROT13 and Base64 framing have zero cryptographic strength.