Encryption/Decryption Tool

About Encryption/Decryption Tool

How AES-256-GCM Encryption Works

When you click Encrypt, the tool runs through four steps to produce the ciphertext.

Step	What Happens	Why
1. Generate salt	16 random bytes are created	Prevents rainbow table attacks on your password
2. Derive key (PBKDF2)	Password + salt run through 310,000 iterations of SHA-256	Stretches a weak password into a strong 256-bit key
3. Generate IV	12 random bytes are created	Ensures the same plaintext + password produces different ciphertext each time
4. Encrypt (AES-256-GCM)	Plaintext is encrypted with the derived key and IV	Produces ciphertext + 16-byte authentication tag

The output is a single Base64 string containing the salt (16 bytes) + IV (12 bytes) + ciphertext + auth tag, concatenated in that order. When decrypting, the tool splits this string apart, re-derives the key from the password and salt, and runs AES-256-GCM decryption. If the password is wrong or the ciphertext has been tampered with, GCM's authentication tag causes decryption to fail rather than producing garbage output.

What Makes GCM Special

AES has several modes of operation. GCM (Galois/Counter Mode) is an authenticated encryption mode, meaning it provides both confidentiality and integrity in a single operation.

AES Mode	Confidentiality	Integrity/Authentication	Parallelizable	Status
ECB	Weak (leaks patterns)	No	Yes	Never use - identical blocks produce identical ciphertext
CBC	Strong	No (needs separate HMAC)	Decrypt only	Legacy - vulnerable to padding oracle attacks if misused
CTR	Strong	No (needs separate HMAC)	Yes	Good but requires manual integrity check
GCM	Strong	Yes (built-in auth tag)	Yes	Recommended - used by TLS 1.3, most modern systems
CCM	Strong	Yes	No	Used in WiFi (WPA2) and Bluetooth

Without authentication, an attacker could flip bits in the ciphertext without detection. GCM's auth tag catches any modification, no matter how small.

PBKDF2 Key Derivation

PBKDF2 turns a short password into a full-length cryptographic key by hashing it repeatedly with a salt. This tool uses 310,000 iterations of SHA-256, the OWASP minimum from 2021-2023. OWASP raised the baseline to 600,000 iterations for PBKDF2-HMAC-SHA256 in its 2023 Password Storage Cheat Sheet update, and that remains the current guidance as of April 2026. The trade-off is UX: at 600,000 iterations a single derivation takes roughly 200ms on mid-range laptops and noticeably longer in mobile browsers, which is why many client-side tools still ship the earlier figure. For interoperability with encrypted output you already have, stick with 310,000; for fresh encryption of highly sensitive data, re-encrypt server-side with 600,000+ and a modern KDF.

KDF	Iterations / Cost	Memory Requirement	Used By
PBKDF2-SHA-256	310,000+ recommended	Minimal	This tool, WPA2 (4,096 iterations), .NET, LastPass
bcrypt	2^cost (10 = 1,024)	4 KB	Password storage in Rails, Django, Spring
scrypt	Configurable	Megabytes	Cryptocurrency wallets, Tarsnap
Argon2id	Configurable	Megabytes	1Password, Signal, modern password storage

PBKDF2 is chosen here because it is the only KDF available in the Web Crypto API. For password storage (one-way hashing), bcrypt or Argon2 are better choices since they are memory-hard, making GPU attacks more expensive.

Encryption vs Hashing vs Encoding

These three operations are often confused. They serve fundamentally different purposes.

Operation	Reversible?	Requires Key?	Purpose	Example
Encryption (AES)	Yes, with the correct key	Yes	Keep data secret	Protecting messages, files, database fields
Hashing (SHA-256)	No (one-way)	No	Verify integrity, store passwords	File checksums, password storage, digital signatures
Encoding (Base64)	Yes, by anyone	No	Represent binary data as text	Email attachments, data URIs, JWT payloads

Base64 encoding is not encryption. Anyone can decode a Base64 string without any secret. The Base64 Encoder is for encoding, not protecting data.

Where AES-256 Is Used

System	Mode	What It Protects
TLS 1.3 (HTTPS)	AES-256-GCM	All web traffic between browser and server
Signal / WhatsApp	AES-256-CBC (in Signal Protocol)	End-to-end encrypted messages
BitLocker (Windows)	AES-256-XTS	Full disk encryption
FileVault (macOS)	AES-256-XTS	Full disk encryption
AWS S3 (SSE)	AES-256-GCM	Objects stored at rest
WireGuard VPN	ChaCha20-Poly1305 (AES-256 as fallback)	VPN tunnel traffic
ZIP archives (AES)	AES-256-CTR	Compressed file contents

Worked Example

Suppose you encrypt the text "meeting at 3pm" with the password "correcthorsebatterystaple". The tool generates a random salt (say, 16 bytes) and IV (12 bytes), derives a 256-bit key via PBKDF2, encrypts the plaintext, and appends the GCM auth tag. The output is a single Base64 string roughly 80 characters long. If you change even one character of the plaintext or password, the entire output changes completely - there is no partial similarity.

To decrypt, you paste the Base64 string and enter the same password. The tool extracts the salt from the first 16 bytes, re-derives the key, extracts the IV from the next 12 bytes, and decrypts the remainder. If the password is wrong, GCM authentication fails and the tool reports an error rather than producing garbled text.

A small concrete trace helps. The plaintext "meeting at 3pm" is 14 bytes of UTF-8. After encryption the byte layout is 16 salt + 12 IV + 14 ciphertext + 16 GCM tag = 58 bytes of binary. Base64 encoding adds roughly 33% overhead, producing an 80-character output string. Encrypt the same plaintext a second time with the same password and you get a completely different 80-character string, because both the salt and the IV are freshly randomised. This non-determinism is deliberate: it stops an observer from spotting that you sent the same message twice.

Security Best Practices

Practice	Why
Use a strong password (16+ characters)	PBKDF2 slows brute force but cannot fix a weak password
Never reuse an IV with the same key	GCM breaks catastrophically if IV is reused - this tool generates random IVs automatically
Store ciphertext, not plaintext	If your storage is compromised, the attacker still needs the password
Use HTTPS when transmitting ciphertext	Prevents man-in-the-middle from modifying the Base64 string
Do not embed passwords in code	Use environment variables or key management services
Rotate keys periodically	Limits the damage if a key is compromised

Limitations of Browser-Based Encryption

The Web Crypto API provides genuine cryptographic operations, but running in a browser has trade-offs. The page could be modified by a malicious extension. Memory cannot be securely cleared (JavaScript has no memset equivalent). And the password is typed into a web page that could be observed by other tabs or extensions. For high-security applications, use a dedicated tool like GPG or age on the command line, or handle encryption server-side with a proper key management service.

How Strong Is a 256-bit Key in Practice?

A 256-bit key has 2^256 possible values, which is roughly 1.16 x 10^77. Even if every computer on Earth tested a billion keys per second, brute-forcing AES-256 directly would still take longer than the age of the universe. The real weakness is never the cipher - it is the password feeding PBKDF2. A 6-character lowercase password has about 28 bits of entropy; a 12-character password mixing case, digits, and symbols has around 72 bits. The NIST SP 800-63B guideline recommends at least 15 characters or a passphrase of four or more random dictionary words (40-50 bits of entropy before the KDF adds its stretching work). As of the April 2026 guidance, cloud GPU rigs can test roughly 10 billion SHA-256 hashes per second against unhashed passwords, so weak passwords remain the dominant attack surface regardless of how strong the cipher is.

Password	Entropy (bits)	Time to crack at 10B guesses/sec
password123	~22	Under 1 second
Tr0ub4dor&3	~28	~27 seconds
correcthorsebatterystaple	~44	~50 years
16-char random mixed	~96	Heat death of the universe

These figures assume the attacker has the ciphertext and can guess passwords offline. PBKDF2's 310,000 iterations multiply every guess by that factor, so the "50 years" row in practice becomes a number with more zeros than fit on screen - but only if the password has real entropy to begin with.

Common Mistakes People Make

Mistake	What Happens	Fix
Reusing the same password across different data	One compromised password opens every file at once	Derive distinct keys per context, or use a password manager with unique secrets
Pasting ciphertext into plain email	Observers see which key slot is in use and can correlate metadata	Wrap with TLS or use PGP over the whole message
Losing the salt and IV	Decryption is impossible - the tool prepends them for exactly this reason	Store the full Base64 output, never trim it
Editing the Base64 string by hand	GCM auth tag fails, decryption aborts	Treat the string as opaque; copy exactly as produced
Trusting AES-256 to fix a weak password	The cipher is fine, the password is the weakest link	Use a generated passphrase from the Password Generator

For generating strong passwords to use with this tool, try the Password Generator. For keyed message authentication without encryption, the HMAC Generator signs messages with a shared secret. All processing runs in your browser via the Web Crypto API.

Sources

• OWASP - Password Storage Cheat Sheet (PBKDF2 iteration counts)
• NIST SP 800-38D - Recommendation for Block Cipher Modes of Operation: GCM
• NIST SP 800-63B - Digital Identity Guidelines (password entropy)
• RFC 8446 - The Transport Layer Security (TLS) Protocol Version 1.3
• MDN - Web Crypto API Reference
• RFC 2898 - PKCS #5: Password-Based Cryptography Specification (PBKDF2)