crypto.subtle, which requires a
secure context (https:// or localhost) in a modern browser.
CNSA 2.0 preference: use SHA-384 or SHA-512 (SHA-256 is fine for Suite B / general use). See the CNSA reference tab.
Output format: iv_hex : ciphertext_hex||tag_hex — paste back into the field to decrypt.
CNSA 2.0 preference: AES-256 (the default key above is 32 bytes) with an authenticated mode (GCM). The IV must be unique per message.
CNSA guidance is ≥ 192-bit keys; PBKDF2-SHA-256/512 with a high iteration count is used for password-based derivation. Prefer ≥ 600,000 iterations (SHA-256) for new work.
NSA CNSA reference (from the NSA advisory)
Sourced from NSA's "Announcing the Commercial National Security Algorithm Suite 2.0" (U/OO/194427-22 · PP-22-1338 · Sep 2022) and the CNSA 1.0 tables (CNSSP 15, Annex B). CNSA 1.0 is the current standard; CNSA 2.0 adds post-quantum algorithms for the transition to be complete by 2035. Reference only — not a compliance claim.
Table IV — CNSA 2.0 algorithms
| Function | Algorithm | Specification | Parameters |
|---|---|---|---|
| Symmetric block cipher (info protection) | AES | FIPS PUB 197 | 256-bit keys for all levels |
| Asymmetric key establishment | CRYSTALS-Kyber (ML-KEM) | TBD | Level V params for all levels |
| Asymmetric digital signatures | CRYSTALS-Dilithium (ML-DSA) | TBD | Level V params for all levels |
| Hash (condensed representation) | SHA | FIPS PUB 180-4 | SHA-384 or SHA-512 for all levels |
| Firmware & software signing | LMS | NIST SP 800-208 | All params; SHA-256/192 recommended |
| Firmware & software signing | XMSS | NIST SP 800-208 | All params approved for all levels |
Table V — CNSA 1.0 algorithms
| Function | Algorithm | Specification | Parameters |
|---|---|---|---|
| Symmetric block cipher (info protection) | AES | FIPS PUB 197 | 256-bit keys for all levels |
| Asymmetric key establishment | ECDH Key Exchange | NIST SP 800-56A | Curve P-384 for all levels |
| Asymmetric digital signatures | ECDSA | FIPS PUB 186-4 | Curve P-384 for all levels |
| Hash (condensed representation) | SHA | FIPS PUB 180-4 | SHA-384 for all levels |
| Asymmetric key establishment | DH Key Exchange | IETF RFC 3526 | Minimum 3072-bit modulus |
| Asymmetric key establishment | RSA | NIST SP 800-56B | Minimum 3072-bit modulus |
| Asymmetric digital signatures | RSA | FIPS PUB 186-4 | Minimum 3072-bit modulus |
Not in the suite: DSA, SHA-1, MD5, Diffie-Hellman/RSA below 3072-bit. CNSA 2.0 deprecates RSA, DH and EC once the PQC standards and FIPS-validated implementations land.
CNSA 2.0 transition timeline (NSA)
| Area | Prefer CNSA 2.0 by | Exclusive use by |
|---|---|---|
| Software & firmware signing | 2025 | 2030 |
| Web browsers/servers & cloud | 2025 | 2033 |
| Traditional networking (VPN, routers) | 2026 | 2030 |
| Operating systems | 2027 | 2033 |
| Niche equipment (constrained, large PKI) | 2030 | 2033 |
| Custom apps & legacy equipment | — | 2033 |
What this tool can and cannot do
Can: SHA-2 hashing, HMAC-SHA-2, AES-GCM encryption/decryption and PBKDF2 derivation — the symmetric primitives from the suite, via your browser's audited Web Crypto implementation. Cannot (here): certificate/key generation, ECDSA/ECDH/EdDSA signing, RSA, LMS/XMSS, or post-quantum (ML-KEM/ML-DSA) — browsers don't expose those as simple primitives (RSA/EC keygen exist but are outside this tool's scope). The algorithms above that aren't implemented here are named for reference.
Security notes
Everything is computed locally with crypto.subtle; nothing is transmitted. This is a utility for
engineers — it is not audited for production key management, and using a browser tab for
secrets has obvious limits. For real key material, use a hardware-backed store (HSM, smart card, TPM).
Sources: NSA, "Announcing the Commercial National Security Algorithm Suite 2.0" (Sep 2022); CNSA 1.0 tables (CNSSP 15, Annex B); NSA Suite B (RFC 8423 reclassified it historic). Related IETF profiles: RFC 8603, 8755, 8756, 9151, 9206, 9212.