Encryption Key Generator
Generate cryptographic keys (AES-GCM/CBC/CTR 128-256, RSA-OAEP/PSS/PKCS1 2048-4096, ECDSA/ECDH P-256/384/521, HMAC SHA-256/384/512). Export as JWK and PEM. Non-extractable mode for production. 100% client-side.
What is the Encryption Key Generator?
Encryption Key Generator wraps the browser's Web Crypto API (`crypto.subtle.generateKey`) to produce production-grade cryptographic keys without ever shipping the bytes to a server. Symmetric algorithms: AES-GCM (the default for new authenticated encryption work), AES-CBC and AES-CTR at 128 / 192 / 256-bit lengths, plus HMAC with SHA-256 / SHA-384 / SHA-512 (used for JWT and API request signing). Asymmetric: RSA-OAEP (encrypt), RSA-PSS (sign — modern preferred), RSASSA-PKCS1-v1_5 (sign — used by older RS256 JWTs), ECDSA (sign), ECDH (key exchange) at 2048 / 3072 / 4096-bit RSA or P-256 / P-384 / P-521 curves. Keys export as JWK (always) and PEM (asymmetric — PKCS#8 for private, SPKI for public). A non-extractable mode generates the CryptoKey without ever exposing the bytes — the right setting for production code that should only use the key through `crypto.subtle.*` methods. Private keys are hidden behind a reveal toggle.
How to use it
- Pick an algorithm — AES-GCM is the safe default for new symmetric work.
- Pick the key length (AES, RSA, HMAC) or curve (ECDSA, ECDH).
- Toggle extractable off for production use, on for export to JWK / PEM.
- Copy or download the key material — private keys are hidden behind a reveal toggle.
Benefits
- Five algorithm families: AES (GCM/CBC/CTR), RSA (OAEP/PSS/PKCS1), ECDSA, ECDH, HMAC.
- All AES key lengths (128/192/256), all common RSA sizes (2048/3072/4096), all NIST P-curves (256/384/521), HMAC over SHA-256/384/512.
- Symmetric keys export as Hex, Base64URL and JWK; asymmetric as PEM (PKCS#8 private, SPKI public) + JWK.
- Non-extractable mode — the CryptoKey is generated but bytes cannot be exported. The right setting for production.
- Private keys are hidden behind a 'Reveal' toggle so they don't leak from a screen-share or session capture.
- Generated via Web Crypto API — the platform-native cryptographically-strong primitive.
- Auto-regenerates on every algorithm / parameter change for fast iteration.
- 100% client-side — keys never touch a server.
Frequently asked questions
Are these keys safe for production use?
Yes — they come from the same Web Crypto implementation your backend uses (BoringSSL on Chrome, NSS on Firefox, Apple's CoreCrypto on Safari). The randomness is OS-seeded.
What's the difference between AES-GCM and AES-CBC?
AES-GCM authenticates as it encrypts — you get integrity for free. AES-CBC just encrypts; you need a separate MAC (HMAC-SHA-256 typically) to detect tampering. Use AES-GCM for new code.
Why RSA-PSS instead of RSA PKCS#1 v1.5?
PSS is probabilistic (different ciphertext each time) and has stronger security proofs. PKCS#1 v1.5 is still widely deployed (every RS256 JWT) but new code should prefer PSS.
Why is my private key hidden by default?
Private keys are the most sensitive output. Hiding them behind a reveal toggle prevents accidental leakage via screen recording, screen-share, or browser session captures.
What does 'non-extractable' mean?
The Web Crypto API returns a CryptoKey object that points to key material the browser tracks internally. With extractable=true you can export the bytes (raw, JWK, PEM); with extractable=false you can't, and the key can only be used via crypto.subtle.encrypt/decrypt/sign/verify — much safer for production.
Can I use these for SSL / TLS?
RSA / ECDSA keys generated here are structurally identical to what openssl produces. To use for TLS, export the PEM and feed it to your server config along with a certificate signed for your domain (via a CA or Let's Encrypt).
Why P-256 vs P-384?
P-256 (also called secp256r1) gives ~128-bit security and is the fastest of the NIST curves. P-384 gives 192-bit security. P-521 gives 256-bit. Most TLS today uses P-256.
Are AES-128 keys still safe?
Yes for current threat models. AES-256 buys you margin against future quantum attacks but is slower. AES-128 is the spec default and what most browsers/protocols negotiate.
Why no Ed25519?
The Web Crypto API doesn't support Ed25519 in all browsers yet (Safari is the laggard). When support is universal we'll add it. For now, ECDSA on P-256 is the safe portable choice.
Is anything uploaded?
No. All key generation runs in your browser via crypto.subtle — Toollyz has no server that ever sees the key material.
Will the same configuration generate the same key?
No — every call to crypto.subtle.generateKey produces a fresh random key. The strength meter shows the configuration; the bytes change every time.