01 / Checksums and collision resistance
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.
02 / Authentication, derivation and password cost
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.
03 / SM3 and byte-level agreement
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. |
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.