AES Encryption & Decryption

Advanced Encryption Standard (AES) – symmetric block cipher. Encrypt and decrypt messages using AES-128, AES-192, or AES-256. Supports CBC (Cipher Block Chaining) and GCM (Galois/Counter Mode) with authentication.

Hex-encoded raw key. Length determines strength: 32 chars = AES-128, 48 = AES-192, 64 = AES-256.
CBC requires exactly 16-byte IV (32 hex). GCM recommends 12-byte nonce (24 hex). Unique IV is critical for security.
CBC (PKCS#7) GCM (Authenticated)
? "Hello World" ? JSON Sample ? Long Text
Zero-knowledge design: All cryptographic operations run locally in your browser using Web Crypto API. No plaintext, keys, or ciphertext are ever sent to any server.

Understanding AES – The Global Encryption Standard

The Advanced Encryption Standard (AES) is a symmetric block cipher adopted by the U.S. government and used worldwide. It superseded DES and remains unbroken for practical applications. AES operates on 128-bit blocks with key sizes 128, 192, or 256 bits. This tool implements the NIST-standardized AES in two widely used modes: CBC (Cipher Block Chaining) and GCM (Galois/Counter Mode).

? AES core: SubBytes, ShiftRows, MixColumns, AddRoundKey (Rijndael S-box). The number of rounds: 10 (AES‑128), 12 (AES‑192), 14 (AES‑256).

Why CBC and GCM?

  • CBC (Cipher Block Chaining): Each plaintext block is XORed with the previous ciphertext block before encryption. Requires a random, unpredictable IV. Provides confidentiality but not integrity. PKCS#7 padding handles variable-length messages.
  • GCM (Galois/Counter Mode): Authenticated encryption (AEAD) – provides both confidentiality and integrity/authenticity. Generates an authentication tag that ensures the ciphertext hasn't been tampered with. Essential for secure channels (TLS, IPsec).

How the Tool Works (Client‑Side Web Crypto API)

When you click Encrypt, the browser's native window.crypto.subtle imports your hex key, generates a CryptoKey object, and encrypts the plaintext using AES‑CBC or AES‑GCM. For GCM, the tool also computes an authentication tag. The result is encoded as Base64 or Hex. Decryption reverses the process — the same key, IV/nonce, and (for GCM) tag are required. No data leaves your device, guaranteeing privacy.

Step‑by‑step workflow

  1. Provide a hex-encoded AES key (or generate a cryptographically random one).
  2. Set a unique IV/nonce (randomness is crucial; never reuse IV with same key in CBC/GCM).
  3. Select mode: CBC (confidentiality only) or GCM (authenticated encryption).
  4. Enter plaintext, press Encrypt → ciphertext (and tag for GCM) appears.
  5. To decrypt, paste ciphertext (and tag) and use the same key+IV → original plaintext.
Real‑World Use Case: Secure API Payloads

Financial institutions and healthcare APIs use AES‑GCM to encrypt sensitive JSON payloads. The authentication tag prevents malicious alteration of transaction amounts or patient IDs. With our tool, developers can test encryption parameters before integrating into production systems – ensuring compliance with PCI‑DSS or HIPAA requirements.

Security Best Practices & Common Pitfalls

  • IV uniqueness: Reusing an IV with the same AES key in CBC or GCM destroys security. Always use a random IV for each encryption operation.
  • Key management: Never hardcode keys in client‑side code for production; use HSM or key management services. This tool is for education and testing.
  • Key length: Prefer AES‑256 for high security (quantum‑resistant margin). AES‑128 remains sufficient for most applications but avoid AES‑192 unless required by legacy systems.
  • GCM nonce size: 12 bytes (96 bits) is recommended. Larger nonces increase collision probability.

Authority & Standards

This tool complies with NIST Special Publication 800-38A (CBC) and 800-38D (GCM). The Web Crypto API implementation is FIPS 140-2 compliant on supported browsers. References: FIPS 197, NIST SP 800-38D.

Frequently Asked Questions

CBC ensures confidentiality but not integrity; GCM provides both encryption and authentication (AEAD). GCM is recommended for modern applications because it detects tampering.

No. All operations are performed locally in your browser. Keys and plaintext never leave your device.

The IV ensures that encrypting the same plaintext twice produces different ciphertexts, preventing pattern leakage. It must be random and unique per encryption.

Without the correct tag, decryption will fail. The tag is essential for verifying integrity; store it alongside the ciphertext.

For production, derive keys using PBKDF2 or Argon2 from passwords. This tool focuses on raw keys for simplicity and educational clarity. We recommend using a password manager and generating random keys.
References: NIST FIPS 197, SP 800-38A, SP 800-38D; Daemen, J., Rijmen, V. "The Design of Rijndael"; Web Crypto API W3C Recommendation.