Choosing a hash function for 2030 and beyond: SHA-2 vs. SHA-3 vs. BLAKE3

Battle for the 2030 “digital fingerprint”: BLAKE3 hype, SHA‑3 purists, and MD5 memes

TLDR: The article weighs SHA‑2, SHA‑3, and BLAKE3 for future‑proof hashing while reminding everyone not to use hash functions for passwords. Comments explode into a BLAKE3 speed-and-tree lovefest, push back on reduced‑round SHA‑3 variants, and meme on MD5—highlighting a split between speed fans and safety purists.

The piece asks which “digital fingerprint” we’ll trust in 2030—SHA‑2, SHA‑3, or BLAKE3—and the comments instantly turn into Hash Wars. First, a big PSA: hashes aren’t for passwords. The article calls out Argon2id as the go‑to and dunks on old habits like SHA1 and bcrypt’s 72‑character gotcha, prompting collective facepalms and the meme‑worthy quip: “just add +1 MD5 each year,” courtesy of jswelker.

Cue the drama: Octoth0rpe genuinely asks if “second‑preimage” vs “collision” resistance are the same, sparking explainers that boil down to “finding a match for one specific message” vs “any two messages colliding.” The thread turns into a crash course for normal humans—and a reminder that crypto terms confuse even pros.

Then the stanning begins. BLAKE3 fans, led by amluto, rave about its tree hash superpower: you can verify just a chunk of a file, hash pieces as they stream in, and go fully parallel. Meanwhile, the SHA‑3 crowd shows off new toys: robobully drops TurboSHAKE & KangarooTwelve, faster spins on the same core, with K12 being tree‑based too.

But skeptics like scatbot throw shade: reduced‑round Keccak “trades safety margin for speed,” while BLAKE3 “already covers real‑world needs.” Verdict? The community is split between speed freaks and safety purists, with compliance folks quietly clutching SHA‑2/3.

Key Points

  • The article compares SHA-2, SHA-3, and BLAKE3 for long-term use, focusing on speed, security, and availability.
  • It defines key security properties of cryptographic hash functions: preimage, second-preimage, and collision resistance.
  • It states that hashes should not be used for password storage; Argon2id is recommended, with PBKDF2-SHA-512 as a FIPS-compliant option.
  • bcrypt is discouraged due to 72-character input truncation, which has led to real-world vulnerabilities, including a case at Okta.
  • Checksums like CRC32 and xxh3 are for error detection only and provide no security guarantees, distinguishing them from secure hash functions.

Hottest takes

“Each year just add +1 MD5 iteration” — jswelker
“You can generate a proof that a portion of the file is correct” — amluto
“Reduced‑rounds Keccak trades a conservative security margin for speed” — scatbot
Made with <3 by @siedrix and @shesho from CDMX. Powered by Forge&Hive.