安全与隐私valerieaurora.org
密码学哈希函数的寿命
Lifetimes of cryptographic hash functions
2013 — 2017，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇页面以一张彩色时间表的形式，梳理了各大加密哈希函数（MD5、SHA-1、SHA-2、SHA-3 等）从诞生到被攻破或发现弱点的'寿命'，并附上对每个哈希的简评和'Slashdot 式反应'栏目。它直观展示了密码学哈希函数如何随时间被逐步削弱，帮助开发者判断何时该迁移。
为什么经久不衰：它把'哈希函数何时会失效'这一抽象问题变成一张可查的历史图表，多年来反复被引用，是评估现有系统哈希安全性的实用参考。
HN 评论精选
SHA-2 被标为'削弱'有失公允，它其实仍是目前最被推荐的哈希函数
我认为 SHA-2 应该标为'发现轻微弱点'（甚至算不上'被攻破'），而不是'被削弱'。SHA-3 竞赛初期大家都担心 SHA-2 会像 SHA-1 一样被攻破，但预期中的攻击始终没有出现。如今 SHA-2 相当安全，SHA-3 竞赛的真正意义变成了选一个设计上与 SHA-2 足够不同的算法（Keccak 正是如此），而非直接替代品。实际上密码学家最常推荐的就是 SHA-2，因为 SHA-3 的软件性能相当差。
ReidZB查看英文原文
I think SHA-2 should be "minor weakness discovered" (if not outright "unbroken"), not "weakened". At the onset of the SHA-3 competition, everyone was nervous about SHA-2: it appeared as though a good attack was inevitable, what with the cryptanalytic attacks on SHA-1. But as the competition went on, things got calmer. The attacks against SHA-2 that were so expected simply weren't coming[1]. And so now the status quo is that SHA-2 seems pretty darn safe, and the real focus of the SHA-3 competition shifted towards not necessarily having a direct replacement for SHA-2, in the sense of performance, but instead having a design that was sufficiently different to not allow SHA-2 attacks to apply to it. And Keccak is just that: quite different. Anyway, my point is that SHA-2 is mislabeled. Honestly, I think cryptographers recommend it the most out of any of the hash functions currently; SHA-3's software performance is rather... lacking. [1] Some may argue that this is because cryptographers were focused on the SHA-3 candidates, but I'm not so sure
SHA-2 十年来未被实质攻破，与 SHA-3 都可用于生产环境
SHA-256 的'弱点'说法有些名不副实——那篇论文发表十年后，所谓弱点完全没有被扩展。SHA-3 竞赛的初衷是担心 SHA-2 被攻破后无替代品，但 SHA-2 一直很稳固，所以最终选择了与 SHA-2 差异最大的 Keccak，因为密码学多样性比实际替换更重要。两者都可用于生产环境，我个人会选 SHA-2，除非有特定理由需要 SHA-3 的特性（如海绵结构支持的增量哈希）。
kobeya查看英文原文
The SHA-256 "weakness" is a bit disingenuous. As far as I'm aware in the 10 years since that paper was published the "weakness" hasn't been extended _at all_. The main reason for the SHA3 competition was because we were all concerned at the time that SHA2 would be broken and there'd be nothing to replace it with. However as it happens, SHA2 has remained rock solid, so the outcome of SHA3 was to pick something (Keccak) maximally different from SHA2, since in the intervening years cryptographic diversity became more desired than actual replacement. Both SHA2 and SHA3 are fit for use in production systems -- I would personally pick SHA2 unless I had some specific reason to benefit from SHA3 (e.g. incremental hashing modes that the sponge construction makes possible).
性能不应成为留守 SHA-1 的理由，Blake2 是兼顾安全与速度的选择
如果你因为性能原因不愿迁移到 SHA-256，至少应该换到 Blake2。到了今天，继续用 SHA-1 已经没有任何借口了。
mtgx查看英文原文
If you're not willing to move to SHA256 "because of performance," you should at least move to Blake2. https://blake2.net/ There's no excuse for staying with SHA1 at this point.
比特币对 SHA-2 的依赖使其成为检验该算法安全性的高价值目标
如果 SHA-2 家族真有弱点，而比特币区块正是用 SHA-2 生成的，那么第一个攻破它的人会一夜暴富——只要注意每天最多慢慢破解约 20 个区块以免引起怀疑，尽量多卖出后再发表论文。
josephagoss查看英文原文
If the SHA-2 family have weaknesses, and SHA-2 is used for generating Bitcoin blocks, whoever breaks this first will be an overnight millionaire, just make sure you break them slowly (about 20 a day max) to avoid suspicion that the hashing is compromised. Sell as much as possible and then release your paper.
历次讨论
同类还值得读
非法素数
Illegal prime
维基百科条目，介绍“非法素数”：某些素数之所以被称为“非法”，是因为它们经特定编码后，恰好对应一段被法律禁止传播的数据——最著名的是 DVD 解密程序 DeCSS 的代码，有人把…
安全与隐私上首页 5 次 · 2010–2021en.wikipedia.org编辑精选关于 /dev/urandom 的常见误区
Myths about /dev/urandom
（Thomas Hühn 撰写，2014 年首发并持续更新）逐条反驳关于 /dev/urandom 的常见误解：它与 /dev/random 使用的是同一个 CSPRNG，一旦完…
安全与隐私上首页 5 次 · 2014–20202uo.de编辑精选AES 高级加密标准火柴人图解
A Stick Figure Guide to the Advanced Encryption Standard (AES)
一篇用火柴人漫画形式讲解 AES（高级加密标准）算法的经典科普文章。
安全与隐私上首页 5 次 · 2009–2022moserware.com编辑精选指纹是用户名，不是密码
Fingerprints are Usernames, not Passwords
作者（eCryptfs 维护者、Ubuntu 安全工程师）认为指纹等生物特征是公开、不可更改的标识，应视作用户名而非密码，不能当作秘密凭据用于认证。
安全与隐私上首页 4 次 · 2013–2017blog.dustinkirkland.comHTTPS 连接的最初几毫秒（2009）
The First Few Milliseconds of an HTTPS Connection (2009)
逐毫秒拆解一次 HTTPS 连接建立时发生了什么，重点讲 TLS 握手、证书验证、RSA 签名与密钥协商等机制，面向不熟悉该领域的读者。
安全与隐私上首页 4 次 · 2009–2020moserware.com编辑精选