CRYPTOGRAPHIC PRIMITIVES
ORIGINS / STANDARDS / OPERATIONS
Diffie 与 Hellman 在 1976 年公开提出公钥密码与密钥协商思想，让没有预共享秘密的双方可以建立共享秘密。RSA 在 1977 年提出，利用大整数上的计算困难性，为公钥加密与数字签名提供另一条路线。数学原语必须配合安全编码：裸 RSA 不等于安全 RSA 加密。
本页 RSA 加密采用 OAEP/SHA-256，签名采用 PSS/SHA-256、32 字节盐。OAEP 仅适合短消息：最大长度为 k - 2·hLen - 2；2048 位 RSA/SHA-256 只有 190 字节。大文件应使用随机 DEK 对称加密，再由接收方公钥保护 DEK。
生产密钥应绑定单一用途与权限。本页为实验可让同一 RSA 材料执行不同操作，不应照搬为生产策略。
椭圆曲线密码在 1980 年代独立提出，用不同的群结构实现公钥运算。ECDH 用曲线建立共享秘密，ECDSA 用于签名；曲线相同并不表示用途相同。Curve25519 在 2006 年提出，RFC 7748 于 2016 年规范 X25519。Ed25519 使用相关数学背景，但按 RFC 8032 执行签名，不是把 X25519 密钥直接当作 SSH 登录签名密钥。
本页 X25519/ECDH 输出经过 HKDF-SHA256 的 32 字节派生密钥，不直接把共享点当 AES 密钥。双方须使用一致的 salt/info；真实协议还需绑定双方身份、公钥、方向和握手记录。匿名协商不能防止中间人攻击，也不能仅凭“结果相同”证明对端身份。
ECDSA 输出采用 WebCrypto 的定长 r || s（IEEE P1363），不是 ASN.1 DER。Ed25519 输出 64 字节签名。不得将同一字节串的编码混用。
SM2 是国密椭圆曲线公钥体系，GB/T 32918 系列分别规定总则、签名、密钥交换、公钥加密及参数。签名中的 ZA 将用户标识、曲线参数与公钥绑定；本页默认标识为 1234567812345678，互通双方必须一致。
本页 SM2 签名为 DER，密文采用未压缩 C1 点（含 04）与可选 C1C3C2 / C1C2C3 排列，不等于 ASN.1 密文封装。SM2 曲线 OID 为 1.2.156.10197.1.301；能导出 PEM 不代表目标系统支持该曲线。本页不把普通 ECDH 冒充完整 SM2 密钥交换协议。
SPKI 描述公钥与算法，PKCS#8 描述私钥与算法；PEM 是 DER 的文本装甲，JWK 是 JSON 表达，OpenSSH 是 SSH 场景格式。格式不改变用途、信任链或授权。PKCS#1 是 RSA 专用兼容格式。
| 标准入口 | 互通约定 |
|---|---|
| RFC 8017 / RFC 7748 / RFC 8032 | RSA、X25519 与 Ed25519；协商与签名严格分开。 |
| RFC 5208 / RFC 8410 / RFC 7517 | PKCS#8、现代曲线编码与 JWK。Hex 仅提供 SM2 原始材料、Ed25519/X25519 的 32 字节种子/公钥，以及 ECDH/ECDSA 的未压缩公钥点。 |
| RFC 4253 / GB/T 32918 系列 | 通用 SSH 登录提供 RSA、Ed25519、ECDSA；SM2 需特定实现，X25519/ECDH 不导出登录密钥。 |
加密 PKCS#8 采用 PBES2 / PBKDF2-HMAC-SHA256（210000 次、16 字节盐）/ AES-256-CBC；OpenSSH 私钥采用 bcrypt KDF（16 轮）/ AES-256-CTR。它们是各自格式的口令保护，并非 AEAD 数据加密；保护强度仍取决于口令熵与离线攻击预算。JWK、Hex、PKCS#1 私钥只提供明确确认后的明文导出。导入支持 PKCS#8/SPKI PEM、RSA PKCS#1 私钥及 OpenSSH 私钥；不声称接受任意 JWK、SSH 公钥或原始 Hex。
KMS 需要把生成、用途授权、版本轮换、吊销、备份恢复、销毁与审计连成可验证的生命周期。数据密钥 DEK 负责加密数据，密钥加密密钥 KEK 负责保护 DEK；信封加密让主密钥留在受控边界，而非随业务数据迁移。密钥标识、版本、算法、用途和授权策略必须绑定，不能只存一段 Hex。
不可导出密钥、HSM 隔离、双人控制、最小权限和审计证据不能由一个浏览器页面替代。本页为互通实验而生成可导出密钥；私钥不自动落盘，保护口令只用于本地导出。清除会丢弃 Worker 和界面中的引用，但 JavaScript 垃圾回收并不承诺物理内存的可证明擦除。生成私钥、密码和生产主密钥应位于符合组织要求的受控环境。
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.
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.
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.
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.