AES-256-CTR + HMAC-SHA256 Encryption
Stream cipher encryption with separate message authentication. Encrypt-then-MAC design for maximum security.
đź”’ Your Data is Fully Protected
Your data is never stored. All encryption and decryption is processed securely and immediately discarded—no data is saved to any database or file system. Works reliably across all browsers.
About This Algorithm
Encryption: AES-256-CTR
- Counter (CTR) mode stream cipher
- 256-bit encryption key
- 16-byte random IV per encryption
Authentication: HMAC-SHA256
- Separate key for authentication
- HMAC covers salt + IV + ciphertext
- Encrypt-then-MAC for security
Remember this password - you'll need it to decrypt the data
About AES-256-CTR + HMAC-SHA256 Encryption
AES-256-CTR + HMAC-SHA256 is an Encrypt-then-MAC construction that combines a stream cipher (AES in Counter Mode) with a separate message authentication code (HMAC). This approach uses two independent keys—one for encryption and one for authentication—providing defense in depth and cryptographic key separation as recommended by security researchers.
Technical Specifications
Encryption Algorithm
AES-256-CTR (Counter Mode) turns AES into a stream cipher. The counter is encrypted and XORed with plaintext, allowing parallel processing, no padding requirements, and random access decryption.
Authentication (HMAC)
HMAC-SHA256 computes a 256-bit authentication tag over the ciphertext, IV, and salt. This Encrypt-then-MAC approach is cryptographically proven secure and detects any tampering.
Key Derivation
PBKDF2-HMAC-SHA256 with 100,000 iterations. Two separate 256-bit keys are derived: one for AES encryption and one for HMAC. This key separation prevents related-key attacks.
Counter/Nonce
A 128-bit counter (16 bytes) is randomly generated for each encryption. Unlike GCM's 96-bit IV, CTR mode can use the full 128-bit block as the initial counter value.
Encrypt-then-MAC Construction
Step 1 - Derive Keys: From your password and a random salt, two independent 256-bit keys are derived using PBKDF2: Kenc for encryption and Kmac for authentication.
Step 2 - Encrypt: The plaintext is encrypted using AES-256-CTR with the encryption key and a random 128-bit counter/IV, producing the ciphertext.
Step 3 - Authenticate: HMAC-SHA256 is computed over (salt || IV || ciphertext) using the MAC key. The resulting 256-bit tag is appended.
Step 4 - Verify First: During decryption, the HMAC is verified before any decryption attempt. This prevents padding oracle and other attacks.
Why Use CTR+HMAC?
âś“ Advantages
- • Key separation: Independent encryption and MAC keys
- • Proven security: Encrypt-then-MAC is formally proven secure
- • Conservative design: Combines well-studied primitives
- • No nonce reuse catastrophe: More forgiving than GCM
- • Parallel processing: CTR mode supports parallel encryption
âš Considerations
- • Two-pass processing (encrypt, then MAC)
- • Larger output (256-bit HMAC vs 128-bit GCM tag)
- • Requires two separate key derivations
- • Slightly more complex implementation
- • Must verify MAC before decrypting (critical!)
Comparison with Other Modes
| Feature | AES-GCM | CTR+HMAC | CBC+HMAC |
|---|---|---|---|
| Cipher Type | Stream (CTR-based) | Stream cipher | Block cipher |
| Key Separation | No (single key) | Yes (dual keys) | Yes (dual keys) |
| Nonce Misuse | Catastrophic | Recoverable | Recoverable |
| Auth Tag Size | 128 bits | 256 bits | 256 bits |
| Best For | Speed, TLS, IPsec | Key separation, security margin | Legacy systems |
Implementation Details
This tool uses industry-standard Node.js crypto module for all cryptographic operations, ensuring consistent and reliable encryption across all browsers. The Encrypt-then-MAC construction ensures the HMAC is always verified before any decryption attempt, preventing timing attacks and padding oracles. Your data is never stored—all operations are processed in memory and immediately discarded. No data is saved to any database, file system, or logs.