01 / The public-key idea
Diffie and Hellman publicly described public-key cryptography and key agreement in 1976, allowing parties without a pre-shared secret to establish one. RSA followed in 1977, using hard problems over large integers for encryption and signatures. The mathematics still needs safe encoding: textbook RSA is not secure RSA encryption.
This page uses RSA-OAEP/SHA-256 for encryption and RSA-PSS/SHA-256 with a 32-byte salt for signatures. OAEP handles short messages only: the limit is k - 2*hLen - 2, just 190 bytes with RSA-2048/SHA-256. Encrypt large files with a random DEK, then protect that key with the recipient's public key.
Production keys need defined purposes and permissions. Reusing RSA material for several operations here is an experiment, not a production policy.
02 / Curves, agreement and signatures
Elliptic-curve cryptography was independently proposed in the 1980s. ECDH establishes a shared secret; ECDSA signs messages. Using the same curve does not make their purposes interchangeable. Curve25519 appeared in 2006 and X25519 was specified by RFC 7748 in 2016. Ed25519 uses related mathematics but signs under RFC 8032; an X25519 key is not an SSH login signing key.
X25519/ECDH returns a 32-byte HKDF-SHA256 derived key here, not a raw shared point used as an AES key. Both parties must agree on salt and info. Real protocols must also bind identities, public keys, directions and the handshake transcript. Anonymous agreement does not prevent a man-in-the-middle attack; matching results do not establish the peer's identity.
ECDSA signatures use WebCrypto's fixed-width r || s form (IEEE P1363), not ASN.1 DER. Ed25519 signatures are 64 bytes. Agree on the encoding rather than treating the forms as interchangeable.
03 / SM2 and key formats
The GB/T 32918 series covers SM2's general rules, signatures, key exchange, public-key encryption and parameters. ZA binds a user identifier, curve parameters and public key into signing. This page defaults to identifier 1234567812345678; both parties must match it.
SM2 signatures are DER. Ciphertext uses an uncompressed C1 point, including 04, and either C1C3C2 or C1C2C3 order; it is not an ASN.1 ciphertext envelope. The curve OID is 1.2.156.10197.1.301. Exporting PEM does not mean a recipient supports the curve. Ordinary ECDH is not presented as the full SM2 key-exchange protocol.
SPKI describes public keys and algorithms; PKCS#8 describes private keys and algorithms. PEM is text armor around DER, JWK is JSON, and OpenSSH is an SSH-specific format. None changes a key's purpose, trust chain or authorization. PKCS#1 is an RSA-specific compatibility format.
| Standards | Interoperability rules |
|---|
| RFC 8017 / RFC 7748 / RFC 8032 | RSA, X25519 and Ed25519. Keep agreement and signing separate. |
| RFC 5208 / RFC 8410 / RFC 7517 | PKCS#8, modern curve encodings and JWK. Raw Hex is limited to SM2 material, 32-byte Ed25519/X25519 seeds or public keys, and uncompressed ECDH/ECDSA public points. |
| RFC 4253 / GB/T 32918 series | Generic SSH login supports RSA, Ed25519 and ECDSA here. SM2 needs a specific implementation; X25519/ECDH are not exported as login keys. |
Encrypted PKCS#8 uses PBES2 with PBKDF2-HMAC-SHA256 (210000 iterations, a 16-byte salt) and AES-256-CBC. OpenSSH private keys use bcrypt KDF (16 rounds) and AES-256-CTR. These protect each format with a passphrase; they are not AEAD data encryption. Strength still depends on passphrase entropy and an attacker's offline budget. JWK, Hex and PKCS#1 private keys can only be exported unencrypted after explicit consent. Import accepts PKCS#8/SPKI PEM, RSA PKCS#1 private keys and OpenSSH private keys, not arbitrary JWK, SSH public keys or raw Hex.
Key management is more than choosing an algorithm
A KMS needs a verifiable lifecycle: generation, permitted uses, version rotation, revocation, backup and recovery, destruction, and audit. A data-encryption key (DEK) encrypts data; a key-encryption key (KEK) protects the DEK. Envelope encryption lets a master key stay within a controlled boundary rather than travel with business data. Bind key identifiers and versions to algorithms, purposes and authorization policies. A Hex string alone cannot describe those rules.
A browser page cannot replace non-exportable keys, HSM isolation, dual control, least privilege or audit evidence. Keys here are exportable for interoperability experiments. Private keys are not saved automatically, and a protection passphrase is used only for local export. Clearing discards the Worker and UI references; JavaScript garbage collection does not guarantee provable erasure of physical memory. Generate production private keys, passwords and master keys in an environment that meets your organization's controls.