Hash & Encryption Algorithms Cheat Sheet

Hash and encryption cheat sheet: output length, security status and best-use cases for MD5, SHA-1, SHA-256, SHA-3, HMAC, password hashing (bcrypt/scrypt/Argon2) and AES/RSA/ECC.

How It Works

A hash maps arbitrary input to a fixed-length digest and is one-way: easy to compute from the input, practically impossible to invert. A good hash has the avalanche effect (one changed bit flips the output) and strong collision resistance.

Families: MD5 and SHA-1 are broken for security by collision attacks; SHA-256 (SHA-2) is still safe; SHA-3 is a different design. Uses include integrity checks, digital signatures and password storage (salted to defeat rainbow tables). Never use MD5/SHA-1 where security matters.

When to Use This Table

This table is for choosing a hash algorithm. It lists MD5, SHA-1, the SHA-2 family, SHA-3, CRC and xxHash with their type, output length, security status and best use. Decide first whether you need tamper resistance or merely sharding and deduplication.

When not to consult it: you are designing password storage or need collision-resistant signatures. Collision probability and tamper resistance are different dimensions; password storage needs a dedicated KDF such as Argon2, bcrypt or scrypt, never a plain digest.

Rule of thumb: ask about purpose. Integrity checks that only detect accidental corruption or download tampering are fine with CRC32 or xxHash, which are fast; defences against an attacker who actively constructs collisions need SHA-256 or better; MD5 and SHA-1 should remain only for compatibility with legacy systems.

Mind length-extension attacks: SHA-256 itself is not resistant to them (SHA-3 and BLAKE2 are). If your protocol constructs H(secret || message), an attacker can extend it to H(secret || message || padding || extra) without knowing the secret. If you need a MAC, use HMAC rather than assembling it yourself.

Boundaries and Common Pitfalls

  • MD5 and SHA-1 are no longer safe — collisions are constructible

    Practical collision construction exists for both MD5 and SHA-1 — MD5 collisions take seconds to generate, and the SHAttered SHA-1 attack was published in 2017 at roughly 45k dollars with the cost still falling. The consequences: file signatures, certificate integrity and dedup keys can all be bypassed. A collision does not directly yield a second-preimage attack, but that is irrelevant for signature use cases. New code should use SHA-256 or SHA-3/BLAKE2 exclusively.

  • Hand-rolling H(secret || data) is not a MAC

    This is among the most common security mistakes. Hashing secret + message has a length-extension weakness: an attacker who does not know the secret can still produce a valid hash of secret + msg + padding + extra, allowing them to tamper with the appended portion. SHA-256 is collision resistant but not length-extension resistant (SHA-3 and BLAKE2 are). Use HMAC, which addresses this by design, such as crypto.createHmac in Node.

  • A cryptographic hash is not a password storage mechanism

    General-purpose hashes, SHA-256 included, are designed to be fast, which is exactly what password storage must not be — a GPU computes tens of billions per second. Passwords need a deliberately slow KDF with a salt and a tunable cost parameter: Argon2id (preferred), bcrypt, scrypt or PBKDF2. These salt internally and expose an iteration cost that makes brute force impractical. Migrating legacy hashes should use a progressive scheme that recomputes and upgrades on successful login.

How This Relates to Neighbours

To compute or verify a hash, use the in-site hashing tools; this page is a selection reference, not a calculator.

For generating identifiers, use the in-site UUID and random tools; a hash is not a substitute for a unique identifier.

Full digital signature and certificate chain design belongs to applied cryptography, out of scope here.

If the goal is understanding why a system still uses MD5 or SHA-1, the answer is usually a compatibility constraint such as legacy data or a third-party integration — confirm the source before proposing replacement.

Practical Snippet

Key points: (1) choose by purpose — CRC32 or xxHash for integrity, SHA-256 or better for adversarial cases, and never a general hash for passwords; (2) hand-rolled hash(secret + data) is vulnerable to length extension, so use crypto.createHmac for any keyed operation; (3) password storage needs a salted KDF with a cost parameter (Argon2id, bcrypt, scrypt, PBKDF2) because general hashes are fast enough for GPUs to brute force billions per second; (4) compare any token or signature with timingSafeEqual to avoid a timing side channel; (5) migrate legacy hashes progressively by upgrading to KDF format on successful login.

import { createHash, createHmac, randomBytes, scryptSync, timingSafeEqual } from 'crypto'

// ① 按用途选算法
const BY_PURPOSE = {
  integrity:  'sha256',   // 校验数据是否被改(可配 HMAC)
  signature:  'sha256',   // 对抗性场景:碰撞必须难构造
  password:   null,       // 🔴 密码绝不用 createHash,走 KDF
  dedup:      'xxhash64', // 仅做分片/去重,可以快
}

// ② 内容指纹:数据量大时可只取前 8 字节十六进制
function fingerprint(data, algo = 'sha256') {
  const hex = createHash(algo).update(data).digest('hex')
  return hex.slice(0, 16)   // 16 字符 = 64 bit,亿级条目碰撞率可接受
}

// ③ 🔴 密钥场景必须用 HMAC,不能自己拼 hash(secret + data)
function mac(data, secret) {
  return createHmac('sha256', secret).update(data).digest()
}
// ❌ 有长度扩展攻击:
//   const bad = createHash('sha256').update(secret + data).digest('hex')
//   攻击者可算出 hash(secret + data + padding + extra) 的合法值

// ④ 密码存储:用 KDF + 随机盐,绝不用 sha256
function hashPassword(password) {
  const salt = randomBytes(16)
  const key = scryptSync(password, salt, 64, { N: 16384, r: 8, p: 1 })
  return { salt: salt.toString('hex'), key: key.toString('hex') }
}
function verifyPassword(password, stored) {
  const key = scryptSync(password, Buffer.from(stored.salt, 'hex'), 64, { N: 16384, r: 8, p: 1 })
  // 定长比较,防时序侧信道
  return timingSafeEqual(key, Buffer.from(stored.key, 'hex'))
}

// ⑤ 常量时间比较:任何 token / 签名校验都要用
function safeEqual(a, b) {
  const ba = Buffer.from(a), bb = Buffer.from(b)
  return ba.length === bb.length && timingSafeEqual(ba, bb)
}

// ⑥ 迁移旧哈希:登录成功时升级为 KDF
function upgradeIfNeeded(password, legacyMd5) {
  const mine = createHash('md5').update(password).digest('hex')
  if (!safeEqual(mine, legacyMd5)) return null
  return hashPassword(password)   // 登录时顺手换成 KDF 格式

Practical Notes

  • MD5 and SHA-1 are unfit for security useBoth have practical collisions (MD5 collisions can be built in seconds). They are acceptable for transport integrity checks, never for signatures, passwords or tamper protection. Start at SHA-256 for anything security-relevant.
  • Hashing a password directly hands the attacker the databaseUnsalted SHA-256 can be tried billions of times per second on a GPU. Passwords need a work-factor algorithm (bcrypt, scrypt, Argon2) with a unique salt per user; hashing and password verification are different problems.
  • HMAC is not "a hash with a salt"HMAC is H(K ⊕ opad ‖ H(K ⊕ ipad ‖ m)), structurally resistant to length-extension, whereas a plain H(secret ‖ message) is vulnerable to it. Concatenating a secret with a message is not a safe substitute for a MAC.

Data Sources

  • NIST FIPS 180-4 (SHA family)
  • RFC 1321 (MD5)
  • RFC 9106 (Argon2)
  • RFC 8018 (PBKDF2)
  • FIPS 197 (AES)
  • RFC 8017 (RSA)

Codes, names and definitions above come from public specifications; we claim no originality over the specification data itself. The arrangement, Chinese annotations and practical notes on this page are written by us.

AlgorithmTypeOutput / LengthSecurityBest use
MD5Hash128 bitBrokenFile checksums (non-security only)
SHA-1Hash160 bitCollided, deprecatedLegacy compatibility, Git objects
SHA-224Hash (SHA-2)224 bitSecureRarely used SHA-2 variant
SHA-256Hash (SHA-2)256 bitSecureCertificates, blockchain, signatures (most common)
SHA-384Hash (SHA-2)384 bitSecureHigher security requirements
SHA-512Hash (SHA-2)512 bitSecureHigher security requirements
SHA-3Hash (Keccak)224/256/384/512 bitSecureStandardized alternative to SHA-2
RIPEMD-160Hash160 bitMostly secureBitcoin address generation
HMACMACFollows base hashSecure (needs key)API signing, webhook verification
bcryptPassword hashing60 charsSecure (tunable cost)Password storage (widely supported)
scryptPassword hashingVariableSecure (memory-hard)ASIC-resistant password storage
Argon2Password hashingVariableSecure (modern default)Preferred for new projects
PBKDF2Password hashingVariableSecure (iterations)Scenarios needing compatibility
AESSymmetric encryption128/192/256 bitSecureData encryption (prefer GCM mode)
RSAAsymmetric encryption2048/4096 bitSecure (long keys)Key exchange, digital signatures
ECCAsymmetric encryption256 bit and upSecure (short keys)Mobile and TLS, high efficiency
TOTPOne-time password6-8 digitsSecure (short-lived)Two-factor authentication
CRC32Checksum32 bitNot cryptographicTransfer integrity checks
Base64Encoding (not crypto)VariableNot cryptographicBinary to text transport

Frequently Asked Questions

Is MD5 still safe to use?

Not for any security purpose: MD5 collisions can be crafted deliberately, allowing forged signatures and certificates. It is acceptable only for non-adversarial integrity checks (e.g. verifying a download). For security, use SHA-256 or stronger.

Which algorithm should I use to store passwords?

Always use a dedicated password-hashing function, in this order of preference: Argon2 (modern default) > scrypt > bcrypt > PBKDF2. Never store passwords with fast hashes like MD5, SHA-1 or SHA-256, even salted, because they are cheap to brute-force on GPUs. Let a mature library handle salting and the cost parameter.

What is the difference between hashing and encryption?

Hashing is one-way: any input maps to a fixed-length digest that cannot be reversed, used for integrity checks and password storage. Encryption is two-way: a key turns plaintext into ciphertext and back, used to keep data confidential in transit or at rest. Base64 is merely an encoding and is neither.

Should I choose SHA-256 or SHA-3?

Default to SHA-256: it has the best performance, ecosystem support and hardware acceleration. SHA-3 uses a completely different internal construction, making it a good diversification fallback if SHA-2 is ever weakened. Both are currently considered secure.