Text Encryption Tool

About the Text Encryption Tool

Encryption is handled by the browser's native AES-256-GCM implementation, with your passphrase run through PBKDF2 at 100,000 iterations (SHA-256) and a fresh random salt and IV generated each time you encrypt, all without the text leaving the page. It's a solid convenience tool for everyday use, but for genuinely sensitive data you'd still want dedicated, audited security software instead.

Cryptographic Ciphers & Security Specifications

Why your passphrase isn't used directly as the encryption key

AES-256 needs a 256-bit key with genuinely uniform randomness across all 256 bits, but a human-chosen passphrase, even a decent one, has far less real entropy than that and often follows predictable patterns. PBKDF2 (Password-Based Key Derivation Function 2) bridges that gap, it takes your passphrase and deliberately, repeatedly hashes it to stretch it into a properly-sized key, while also intentionally slowing the whole process down. That deliberate slowness is the entire point: it makes brute-force guessing dramatically more expensive for an attacker without meaningfully inconveniencing you, since you're only running it once per encryption or decryption.

Why specifically 100,000 iterations

Each PBKDF2 iteration means running SHA-256 once more on the accumulated result, and 100,000 of them takes a legitimate user only milliseconds on a normal device, an imperceptible one-time cost per operation. But an attacker trying to guess your passphrase has to pay that identical 100,000-iteration cost for every single guess they make, turning what might otherwise be millions of cheap guesses per second into a dramatically slower process. This "work factor" concept, deliberately expensive-but-tolerable computation, is the whole security value PBKDF2 adds on top of a weak or guessable passphrase.

Why a fresh salt is generated every single time you encrypt

The salt, 16 random bytes generated fresh for each encryption, gets mixed into the key derivation so that even the exact same passphrase produces a completely different derived key every time. Without this, an attacker could precompute a table of derived keys for common passphrases once and reuse it against any ciphertext they intercept, or notice that two messages encrypted with the same passphrase share telltale similarities. With a fresh salt every time, that precomputation attack becomes worthless, and encrypting identical text twice with the identical passphrase produces two completely unrelated-looking outputs.

Why the IV also has to be unique, even more strictly than the salt

AES-GCM has a hard security requirement: the same key and IV (initialization vector) combination must never be used to encrypt two different messages, doing so can catastrophically undermine the cipher's confidentiality guarantees. Since a fresh key is derived from a fresh salt on every encryption here anyway, generating a fresh random 12-byte IV alongside it (the standard size for GCM) ensures this critical constraint holds even in the unlikely event of a salt collision, defense in depth on a rule that genuinely cannot be violated safely.

Why salt, IV, and ciphertext are all bundled into one output string

Neither the salt nor the IV is secret, both need to be available again at decryption time to re-derive the identical key and re-run the cipher with the same parameters. Rather than requiring you to separately track and store three different values, this tool concatenates salt, then IV, then ciphertext into one byte sequence and base64-encodes the whole thing as a single portable string. That's why the encrypted result is just one block of text you can copy, paste, and store anywhere, decryption only needs that one string plus your passphrase, nothing else.

Why a wrong passphrase produces a clean error instead of garbled output

GCM is an authenticated encryption mode, meaning it bakes in an integrity check alongside the encryption itself. If you attempt to decrypt with the wrong passphrase, or if the ciphertext has been altered or corrupted in any way, that built-in authentication check fails and the browser's crypto engine throws an error rather than returning silently-corrupted plaintext. Since a wrong passphrase and genuinely corrupted data both trigger that exact same authentication failure with no way to distinguish between them, this tool's error message honestly reflects that ambiguity, "Wrong passphrase or corrupted data" rather than falsely claiming to know which one actually happened.

Authenticated Encryption with Associated Data (AEAD) Mechanics

Galois/Counter Mode (GCM) is an Authenticated Encryption with Associated Data (AEAD) operational mode for symmetric block ciphers. Unlike unauthenticated modes like CBC (Cipher Block Chaining) or CTR (Counter Mode), GCM couples confidentiality with cryptographic message integrity. During encryption, the cipher utilizes an underlying counter to generate a pseudo-random keystream that is XORed with the plaintext. Concurrently, a GHASH polynomial multiplication module processes both the ciphertext and any optional Associated Data across a Galois Field (GF(2^128)), computing a 128-bit authentication tag.

When decrypting, the engine recomputes the GHASH tag and performs a constant-time comparison against the tag embedded in the ciphertext payload. If a single bit in the ciphertext, salt, or initialization vector has been altered by a network glitch or a malicious man-in-the-middle attacker, the authentication verification aborts immediately. Plaintext bytes are wiped from memory without being exposed to higher-level application layers.

Side-Channel Defense: Constant-Time Execution in WebCrypto

Historically, web applications implementing client-side cryptography relied on third-party JavaScript libraries (such as CryptoJS or Forge). While functional, pure JavaScript cryptographic routines suffer from severe side-channel vulnerabilities. JavaScript runtime JIT compilers (like V8) optimize code execution paths dynamically, introducing variable execution times based on CPU branch prediction, memory cache misses, and S-box lookup table indexing.

Adversaries capable of executing unprivileged code or observing microsecond-level network response timings can exploit these timing variations to reconstruct private keys. The W3C Web Cryptography API (window.crypto.subtle) resolves this vulnerability by delegating all cryptographic operations directly to compiled C++ routines and dedicated CPU hardware extensions (such as Intel AES-NI, AMD Cryptographic Extensions, and ARMv8 Cryptography). Hardware instructions execute in strictly constant time, completely eliminating cache-timing and branch-timing side-channel leaks.

Quantum Computing Resilience: AES-256 and Grover's Algorithm

As quantum computing architectures advance, cybersecurity standards are evolving to counter theoretical quantum adversaries. While asymmetric cryptosystems (such as RSA and elliptic curve Diffie-Hellman) are fundamentally vulnerable to polynomial-time factorization via Shor's algorithm, symmetric ciphers exhibit far greater quantum resilience.

The primary quantum attack against symmetric algorithms is Grover's algorithm, an unstructured quantum search procedure that accelerates brute-force key retrieval by a quadratic factor: searching a key space of size 2^N requires 2^(N/2) operations. Consequently, AES-128 is reduced to an effective quantum security strength of 64 bits, placing it within theoretical reach of future fault-tolerant quantum hardware. In contrast, AES-256 is reduced from 256 bits to 128 bits of quantum security. Because 2^128 operations remains mathematically and energetically impossible to execute (exceeding the total thermodynamic capacity of planet Earth), AES-256 is officially rated by NIST and the NSA as post-quantum secure for classical confidentiality.

Zero-Trust Architecture: 100 Percent Client-Side Privacy

Text encryption is meaningless if the encryption engine transmits your plaintext or secret passphrase across the internet to a third-party server. Many online utilities send user text across HTTP APIs where server logs, database backups, and reverse proxies can harvest sensitive messages.

Utility369 enforces a strict zero-knowledge security boundary. All PBKDF2 key derivations, AES cipher transformations, and Base64 packaging execute entirely inside your local browser memory sandbox. No passphrases, keys, plaintexts, or ciphertexts are ever sent over external networks. You can disconnect your device from the internet, switch to airplane mode, and encrypt or decrypt data with complete mathematical privacy.