AES-256-GCM Client File & Text Encryptor
Encrypt and decrypt sensitive files and confidential text locally using 256-bit AES-GCM with PBKDF2 key derivation. Authenticated encryption running 100% in browser memory.
100% Secure & Client-Side: AES-GCM encryption executes entirely in browser memory. No files or keys are transmitted.
Derived using PBKDF2 (100,000 rounds of HMAC-SHA256 with 16-byte random salt).
Click or drag file to encrypt
The Cryptographic Superiority of AES-GCM Authenticated Encryption
The Advanced Encryption Standard (AES), originally known as Rijndael and specified by NIST in November 2001 (FIPS PUB 197), is an iterative symmetric block cipher operating on 128-bit blocks of data using key sizes of 128, 192, or 256 bits.
However, a raw block cipher only describes how to encrypt a single 16-byte block. When encrypting arbitrary files spanning kilobytes or megabytes, a cipher mode of operation is required. Historically, developers utilized Cipher Block Chaining (CBC) mode. CBC provides confidentiality but zero integrity verification: an adversary who flips bits in the ciphertext can alter the decrypted plaintext in predictable ways without triggering a decryption error.
Authenticated Encryption
Combines counter-mode stream encryption with universal Galois field hashing (GHASH) to generate a 128-bit authentication tag.
Padding Oracle Immunity
Operates as a stream cipher without PKCS#7 block padding, completely eliminating padding oracle side-channel attacks.
Hardware Pipelining
Counter mode allows parallel block processing on modern CPUs equipped with Intel AES-NI and ARMv8 Cryptography instructions.
Key Derivation Architecture: PBKDF2 with HMAC-SHA256
A symmetric key for AES-256 requires exactly 256 bits of uniformly distributed cryptographic entropy (32 raw bytes). Human-authored passphrases rarely exceed 40 to 60 bits of entropy. Feeding a password directly into an AES cipher creates an immediate vulnerability.
To bridge this gap, this implementation adheres to RFC 8018 (PKCS #5 v2.1) by routing the password through PBKDF2:
- 16-Byte Cryptographic Salt: Generated fresh for every encryption run via
crypto.getRandomValues(new Uint8Array(16)). The salt ensures that identical passwords produce completely distinct ciphertext streams, completely disabling precomputed rainbow table attacks. - 100,000 Iteration Work Factor: Forces crackers to compute 100,000 sequential HMAC-SHA256 operations for every single candidate password guess, drastically increasing the financial and hardware cost of offline brute-force attacks.
- 12-Byte Initialization Vector (IV): In AES-GCM, the IV must never be reused with the same key. Generating a 96-bit random IV alongside a fresh salt guarantees nonce uniqueness across trillions of encryptions.
Binary Container Layout for .enc Files
The exported .enc archive formats the cryptographic artifacts into a compact binary package:
[ 0 .. 15 ] : 16 Bytes — PBKDF2 Salt (RFC 8018)[ 16 .. 27 ] : 12 Bytes — AES-GCM Initialization Vector (NIST SP 800-38D)[ 28 .. N-16 ]: Variable — Encrypted Ciphertext Payload[ N-15 .. N ] : 16 Bytes — Galois Authentication Tag (GHASH)