安全与隐私freedom-to-tinker.com
NSA 是如何破解这么多加密的？（2015）
How is NSA breaking so much crypto? (2015)
2016 — 2020，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章讨论 NSA 为何能破解大量加密通信，核心在广泛使用的 1024 位 Diffie-Hellman 密钥交换：当时大量 VPN、HTTPS 和 SSH 握手依赖少数硬编码素数，攻击者可对这些素数做大规模预计算，进而恢复会话密钥。作者推测 NSA 正是投入资源针对这些常见参数，才获得规模化解密能力。
为什么经久不衰：它把“公共参数和默认配置”这一系统性风险讲透：只要少数被广泛复用的弱 DH 参数还在，国家级攻击者就能以预计算获得规模优势，至今仍是协议部署的重要教训。
HN 评论精选
概括文章核心：少数硬编码 1024 位 DH 素数被广泛使用，使 NSA 可预计算并解密大量流量；并补充后续协议改进。
总结一下：作者推测 NSA 投入了大量资源来破解某些 1024 位素数下的 Diffie-Hellman 密钥交换。2015 年，全球大多数 VPN 握手以及相当一部分 HTTPS 和 SSH 握手，只使用了少数几个硬编码的 1024 位素数。这使 NSA 有能力恢复这些加密通信所用的共享对称密钥，从而解密它们。此后一些协议转向优先使用不受同样攻击的椭圆曲线 Diffie-Hellman，或至少为普通 DHKE 使用更大的素数（1536 位及以上）。但我不知道这种转变有多普遍——至少很多 VPN 仍在使用旧的弱 DH 密钥。
hyper_reality查看英文原文
To summarise: the authors speculate that the NSA invested in a lot of resources into breaking Diffie-Hellman key exchange for certain 1024-bit primes. Just a few hardcoded 1024-bit primes were used in the majority of VPN handshakes and a significant minority of HTTPS and SSH handshakes worldwide in 2015. This would give the NSA the ability to recover the shared symmetric key used in these encrypted communications, and therefore decrypt them. Since then several protocols have shifted towards preferring Elliptic Curve Diffie-Hellman key exchange which doesn't suffer from the same attack, or at least using larger primes for plain DHKE (1536-bit and above). However I don't know the extent of this - a lot of VPNs at least are still using the old, weak DH keys.
指出浏览器对 DH 素数下限的校验曾极宽松，参数验证本身是攻击面。
在我们这项工作之前，Internet Explorer、Chrome、Firefox 和 Opera 都接受 512 位素数，而 Safari 允许的群小到 16 位。不知道今天的最低要求是多少！（文章写于 2015 年）
vmarsy查看英文原文
"Prior to our work, Internet Explorer, Chrome, Firefox, and Opera all accepted 512-bit primes, whereas Safari allowed groups as small as 16 bits" I wonder what the minimum are today! (Article was from 2015)
提醒标准参数/曲线可能被刻意操纵，Dual EC-DRBG 和 Crypto AG 是现实案例。
魔法数和曲线的选择并不是一个天真的过程。Dual EC-DRBG 中明显的后门就是一个好例子，而且还有一些公司在很多方面帮助 NSA（例如 Crypto AG）。这就是逻辑：NSA 的目标是保护美国利益，如果为了（至少美国视角下的）‘更大善’而推动被操纵或弱化的算法，他们就会这么做。这合法，也合乎逻辑。
rvnx查看英文原文
The way magic numbers and curves are elected is not a naive process. The obvious backdoor in Dual EC-DRBG is a good example, and you have companies helping the NSA in very extensive ways (e.g. Crypto AG). It's just logic, the goal of the NSA is to protect interests of the US, if it involves pushing rigged / weak algorithms for the greater "good" (at least from a US perspective), they'll do it. It's legal, and logical.
从另一角度反思‘不要自造密码学’：常规算法也可能被国家级行为者集中利用，因此不应只做最低限度的安全投入。
这篇文章触及了我长期以来的一个疑问。经典教材通常建议开发者不要自己造密码学轮子，因为更聪明的人已经考虑过更多漏洞，并在久经考验的代码里处理了它们。但这类新闻显示了反面：常规加密技术也可能被国家级行为者大规模利用。如果我是掌握某些广泛使用算法所精选素数解法的人，我可能也会在每次有人写定制库时大声反对；我会出钱出版‘不要自己写密码学’的书，因为这问题太难了，何况已有那么多高质量替代品。当然，出于种种好理由，人们确实应避免自造密码学，但这让我觉得值得投入远超最低限度的努力，尤其当人命关天时。
clord查看英文原文
This article cuts to the heart something I've wondered for a long time. The common advice in all the classic texts is that developers should not roll their own crypto because smarter people have thought of more vulnerabilities and addressed them in battle-tested code. But news like this shows that there is an antithesis: the conventional encryption techniques are also potentially widely exploitable by state-level actors. Furthermore if I was someone holding solutions to cherry-picked primes for well-understood algorithms in wide use, I'd be complaining loudly every time someone wrote a bespoke library too. I'd be paying to publish books that recommend no one write their own crypto because it's just such a darned hard problem, especially with so many high quality alternatives out there tested and ready to go. Granted, one should certainly have a repulsion to to writing custom crypto for all of the many good reasons, but it makes me think it's worth putting in more than the minimal effort into it, especially when lives are on the line.
历次讨论
同类还值得读
非法素数
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编辑精选