CRYPTOGRAPHIC PRIMITIVES
ORIGINS / STANDARDS / OPERATIONS
1992 年的 MD5 面向软件中的快速消息摘要；但抗碰撞性后来被攻破。SHA-1 于 1995 年标准化，也已不适合依赖抗碰撞性的签名和证书。摘要将任意长度消息映射为固定长度输出，安全目标包含原像、第二原像与碰撞抗性，三者不能混为一谈。摘要不是数字签名，也不能单独证明发送者身份。
SHA-2 沿用迭代压缩的设计脉络。NIST 在 SHA-1 风险背景下组织 SHA-3 竞赛，Keccak 在 2012 年胜出，2015 年发布 FIPS 202；它采用海绵结构，为设计多样性提供另一条路线。SHA3-256 与 Keccak-256 的域分隔不同，不能仅凭输出长度认为两者相同。
1997 年 RFC 2104 规范 HMAC，以秘密密钥对消息认证，解决简单拼接密钥与摘要带来的设计陷阱。它不具有公钥签名的公开验证能力；共享 HMAC 密钥的双方都能生成有效认证码。
2010 年 RFC 5869 将 HKDF 分成 Extract 和 Expand：提取输入密钥材料的伪随机性，再用 info 做用途分隔。HKDF 很快，不是密码哈希。盐通常公开，而密码派生的盐须随机、独立。PBKDF2 通过迭代提高猜测成本；2015 年密码哈希竞赛胜者 Argon2 进一步引入内存成本，Argon2id 结合数据独立与数据相关访问，兼顾侧信道与时间-内存权衡。
SM3 提供 256 位摘要，在 GB/T 32905-2016 中标准化。国密体系中的签名通常是 SM2 配合 SM3，而非把 SM3 摘要本身叫作 SM2 签名。
文本编码、行尾、Unicode 规范化与输入是 UTF-8、Hex 还是 Base64 都会改变摘要。本页不隐式清理正文。HMAC 密钥是原始字节；HKDF 的 IKM、salt、info 有各自角色。Argon2id 输出在本页是派生字节，不是完整 PHC 密码记录；生产密码数据库还需保存版本、盐与参数，并用受审计的验证库。
参数需要按目标硬件与并发预算校准，不能把本页默认值当作所有系统的容量规划。
| 标准入口 | 范围与边界 |
|---|---|
| RFC 1321 / FIPS 180-4 / FIPS 202 | MD5、SHA-1/SHA-2、SHA-3；MD5/SHA-1 仅作遗留互通，不建议用于新安全设计。 |
| RFC 2104 / RFC 5869 | 消息认证与密钥派生不是同一个过程；HKDF info 应绑定协议、用途、方向与上下文。 |
| RFC 9106 / RFC 8018 / GB/T 32905-2016 | Argon2、PBKDF2 与 SM3；时间、内存、盐和并行度必须随记录或协议保存。 |
KMS 需要把生成、用途授权、版本轮换、吊销、备份恢复、销毁与审计连成可验证的生命周期。数据密钥 DEK 负责加密数据，密钥加密密钥 KEK 负责保护 DEK；信封加密让主密钥留在受控边界，而非随业务数据迁移。密钥标识、版本、算法、用途和授权策略必须绑定，不能只存一段 Hex。
不可导出密钥、HSM 隔离、双人控制、最小权限和审计证据不能由一个浏览器页面替代。本页为互通实验而生成可导出密钥；私钥不自动落盘，保护口令只用于本地导出。清除会丢弃 Worker 和界面中的引用，但 JavaScript 垃圾回收并不承诺物理内存的可证明擦除。生成私钥、密码和生产主密钥应位于符合组织要求的受控环境。
MD5 was published in 1992 as a fast software message digest, but its collision resistance was later broken. SHA-1, standardized in 1995, is also unsuitable for signatures and certificates that depend on collision resistance. Hashes map arbitrary-length messages to fixed-length outputs. Preimage, second-preimage and collision resistance are distinct goals. A digest is not a digital signature and cannot, by itself, identify a sender.
SHA-2 follows an iterative compression design. With SHA-1 under scrutiny, NIST ran the SHA-3 competition: Keccak won in 2012 and became FIPS 202 in 2015. Its sponge construction offers a different design. SHA3-256 and Keccak-256 use different domain separation; equal output lengths do not make them equivalent.
RFC 2104 standardized HMAC in 1997: authenticate a message with a secret key rather than inventing a hash-and-key concatenation. HMAC does not offer public verification like a signature. Both holders of the shared key can produce valid authentication codes.
RFC 5869 split HKDF into Extract and Expand in 2010. It extracts pseudorandom key material, then uses info to separate purposes. HKDF is fast; it is not a password hash. Salts are usually public. Password-derivation salts need to be random and independent. PBKDF2 increases guessing cost through iteration. Argon2, winner of the 2015 Password Hashing Competition, adds memory cost; Argon2id combines data-independent and data-dependent access to balance side-channel concerns and time-memory trade-offs.
SM3 is a 256-bit hash standardized in GB/T 32905-2016. Chinese cryptographic systems commonly pair SM2 signatures with SM3; an SM3 digest alone is not an SM2 signature.
Text encoding, line endings, Unicode normalization and UTF-8/Hex/Base64 interpretation affect the hash. This page does not clean up text implicitly. HMAC keys are raw bytes; HKDF's IKM, salt and info serve different roles. Argon2id produces derived bytes here, not a complete PHC password record. Production password databases must retain versions, salts and parameters and use an audited verification library.
Calibrate parameters for the target hardware and concurrency budget. These defaults are not capacity planning for every system.
| Standards | Scope and limits |
|---|---|
| RFC 1321 / FIPS 180-4 / FIPS 202 | MD5, SHA-1/SHA-2 and SHA-3. MD5/SHA-1 are for legacy interoperability, not new security designs. |
| RFC 2104 / RFC 5869 | Message authentication and key derivation are different operations. Bind HKDF info to the protocol, purpose, direction and context. |
| RFC 9106 / RFC 8018 / GB/T 32905-2016 | Argon2, PBKDF2 and SM3. Retain cost, memory, salt and parallelism parameters with the record or protocol. |
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.