Introduction
Need to encrypt a payload with AES-GCM, generate an RSA key pair, or verify an ECDSA signature in your browser? Modern cryptography tools handle the symmetric and asymmetric algorithms that protect real systems today. Unlike classical ciphers, these algorithms have key spaces measured in powers of two and resist brute-force attacks from any conventional computer. Every tool here uses the Web Crypto API or vetted JavaScript libraries. Keys are generated locally and never transmitted.
What this category includes
- Symmetric encryption tools (AES-128/192/256 in CBC, CTR, and GCM modes; ChaCha20-Poly1305)
- Asymmetric encryption and signing tools (RSA-OAEP, RSA-PSS, ECDSA, EdDSA)
- Key exchange simulators (Diffie-Hellman, ECDH)
- Key format converters (JWK, PEM, DER, PKCS#1, PKCS#8)
- Certificate parsing (X.509) and signature verification
- Post-quantum algorithm demos (ML-KEM, ML-DSA) based on NIST FIPS 203 and 204
How these tools work
These tools use the Web Crypto API, which exposes the SubtleCrypto interface for cryptographic operations. The browser's native implementation handles key generation, encryption, decryption, signing, and verification. This means the actual cryptographic math runs in compiled native code, not in JavaScript, which is faster and less error-prone.
For AES, the tool calls crypto.subtle.encrypt() with an AesGcmParams, AesCbcParams, or AesCtrParams object specifying the mode, IV, and (for GCM) additional authenticated data. For RSA, it uses RSA-OAEP for encryption and RSA-PSS for signatures. For ECDSA, it supports the P-256, P-384, and secp256k1 curves.
Key format conversion uses the "jose" library for JWK and the "node-forge" library for PEM, DER, and PKCS formats. X.509 certificate parsing uses "asn1js" to decode the ASN.1 structure and display the subject, issuer, validity period, and public key.
Post-quantum demos implement ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) and ML-DSA (Module-Lattice-Based Digital Signature) based on the finalized NIST standards. As of Node.js v24.7.0, ML-KEM and ML-DSA are supported natively in the Web Crypto implementation.
All operations run client-side. Generated keys never leave the browser.
How the underlying systems work
AES (Advanced Encryption Standard) was finalized as FIPS 197 in 2001. It operates on 128-bit blocks with key sizes of 128, 192, or 256 bits. AES-256 has a key space of 2^256, which is approximately 1.15 x 10^77. For comparison, the observable universe contains roughly 10^80 atoms. Exhaustive search of the AES-256 key space is considered computationally infeasible even with hypothetical quantum computers.
The mode of operation matters as much as the cipher. ECB (Electronic Codebook) is insecure because it preserves patterns in the plaintext. CBC (Cipher Block Chaining) is better but vulnerable to padding oracle attacks without careful implementation. GCM (Galois/Counter Mode) provides authenticated encryption, meaning it detects tampering. The MDN documentation recommends GCM over CBC and CTR for this reason. ChaCha20-Poly1305, defined in RFC 8439, is an alternative AEAD cipher that is faster than AES on platforms without hardware AES support.
RSA, published by Rivest, Shamir, and Adleman in 1977, relies on the difficulty of factoring large integers. A 2048-bit RSA key is the current minimum for security. ECDSA achieves equivalent security with much smaller keys (a 256-bit elliptic curve key provides roughly the same security as a 3072-bit RSA key).
Post-quantum cryptography became real in August 2024 when NIST approved FIPS 203 (ML-KEM, derived from CRYSTALS-Kyber) and FIPS 204 (ML-DSA, derived from CRYSTALS-Dilithium). These lattice-based algorithms resist attacks from quantum computers that would break RSA and ECDSA via Shor's algorithm. NIST mathematician Dustin Moody encouraged system administrators to begin transitioning immediately, noting that full integration takes time.
How to use these tools
- Select the algorithm you need (AES, RSA, ECDSA, ChaCha20, Diffie-Hellman, etc.)
- For symmetric tools, enter your plaintext or ciphertext and provide a key and IV
- For asymmetric tools, generate a key pair first, then use the public key to encrypt or the private key to sign
- Choose the mode (GCM recommended for AES; PSS for RSA signatures)
- View the output in hex or base64, and copy it for use in your application
Real-world examples
Encrypting an API Payload with AES-GCM
A developer building a Node.js microservice needs to encrypt a JSON payload before storing it. They paste the JSON into the AES tool, select GCM mode, generate a 256-bit key, and provide a 12-byte IV. The tool returns the ciphertext and authentication tag in base64. They copy both into their code, which uses crypto.subtle.decrypt() with the same key and IV to recover the plaintext.
Verifying a JWT Signature with ECDSA
A backend engineer debugging an authentication issue has a JWT signed with ES256 (ECDSA over P-256). They paste the JWT into the ECDSA signature verifier, paste the public key in PEM format, and the tool reports whether the signature is valid. The step-by-step breakdown shows the header, payload, and signature components, helping them spot a key mismatch.
Converting a JWK to PEM for OpenSSL
A DevOps engineer has an RSA public key in JWK format from a cloud provider's API response. They paste the JWK into the JWK Converter tool, select PEM output, and get a PEM-formatted key they can pass to OpenSSL for further verification. The tool confirms the key size (2048-bit) and exponent (65537) during conversion.
Comparison of methods
| Method | Complexity | Typical use |
|---|---|---|
| AES-256-GCM | O(n) with hardware acceleration | Symmetric encryption, TLS, file encryption |
| ChaCha20-Poly1305 | O(n) in software | Mobile and IoT encryption, TLS alternatives |
| RSA-2048 | O(n^2) for keygen | Asymmetric encryption, key transport |
| ECDSA P-256 | O(n^2) for keygen | Digital signatures, JWTs, TLS |
| ML-KEM-768 | Lattice-based | Post-quantum key encapsulation |
| ML-DSA-65 | Lattice-based | Post-quantum signatures |
Limitations
These tools are for education, testing, and development. They are not a substitute for a properly audited cryptographic library in production. Never paste real production keys into a web tool, even one that runs client-side. Browser extensions, compromised dependencies, or a modified page could intercept keys. For production systems, use a hardware security module (HSM) or a secrets manager. Also note that ECB mode is intentionally excluded from these tools because it is insecure. If you need CBC, be aware of padding oracle attacks and use a library that handles padding verification safely.
Frequently asked questions
What is the difference between AES-GCM and AES-CBC?
GCM (Galois/Counter Mode) provides authenticated encryption, meaning it generates an authentication tag that detects tampering. CBC (Cipher Block Chaining) does not provide authentication by default and is vulnerable to padding oracle attacks if not combined with a separate MAC. MDN recommends GCM over CBC and CTR for this reason. Use GCM unless you have a specific reason to use CBC.
Is RSA still secure in 2026?
RSA-2048 is still considered secure against classical computers. NIST SP 800-57 recommends a minimum of 2048 bits for RSA through 2030. However, RSA is vulnerable to Shor's algorithm, which a sufficiently powerful quantum computer could use to break it. This is why NIST finalized FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA) in August 2024. Organizations should begin planning a transition to post-quantum algorithms.
What are ML-KEM and ML-DSA?
ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) is specified in FIPS 203, derived from the CRYSTALS-Kyber submission. ML-DSA (Module-Lattice-Based Digital Signature) is specified in FIPS 204, derived from CRYSTALS-Dilithium. Both were finalized by NIST in August 2024 and are designed to resist attacks from quantum computers. They are the first post-quantum standards approved for federal use.
Why does the tool recommend GCM over ECB?
ECB (Electronic Codebook) encrypts each block independently, which means identical plaintext blocks produce identical ciphertext blocks. This preserves patterns and leaks information. The classic demonstration is encrypting a bitmap image with AES-ECB: the outline of the image remains visible in the ciphertext. GCM uses a counter mode that avoids this and adds authentication.
Can I use these tools with production keys?
No. Even though these tools run client-side, you should never paste real production keys into a web page. Browser extensions, compromised dependencies, or a modified page could intercept keys. Use these tools for learning, testing with throwaway keys, and debugging. For production, use a hardware security module or a secrets manager.
Related categories
Conclusion
Modern cryptography tools handle the algorithms that protect real systems: AES, RSA, ECDSA, ChaCha20, and the new post-quantum standards from NIST. Use them to learn how authenticated encryption works, debug a JWT signature, or explore ML-KEM before migrating your infrastructure. For hashing and password storage, see Security & Hashing. For Bitcoin and Ethereum address tools, see Blockchain & Crypto.