HackerURLs

一次又一次被重新发现的经典。

同一个链接,相隔一年以上,一次又一次被人重新发现、再次冲上 Hacker News 首页。能经受住这种时间检验的,大多是值得一读再读的文章。每篇附中文标题,讨论最热的那些再加上中文导读和高赞评论翻译。

从名人堂开始
  • 4,700+篇经过时间检验的经典

Hall of fame

名人堂

在经典库里看全部精选

上首页次数最多、而且有中文导读的 30 篇。时间轴上每个黑点是一次上首页,空心点是一次没冲上去的投稿。

  1. 正在载入经典…

Archive

经典库

按第一次上首页的年份分布,点柱子筛选。

排序

    About

    这些经典是怎么挑出来的

    1. 01

      合并同一个链接

      读取 Hacker News 自 2006 年以来的全部链接投稿,把 http/https、www、跟踪参数等写法不同的同一篇文章合并成一条。

    2. 02

      只留经得起时间的

      同一链接至少两次拿到 50 分以上(约等于上首页),而且两次相隔一年以上;再由 AI 剔除状态页、产品首页和新闻事件。

    3. 03

      写导读、译评论

      上首页次数最多的 2,000 篇配上中文导读、"为什么经久不衰",并精选翻译 HN 高赞评论。导读由 AI 生成,可能有误。

    安全与隐私2uo.de编辑精选

    关于 /dev/urandom 的常见误区

    Myths about /dev/urandom

    5次上首页
    6年跨度
    777累计得分
    485条评论

    2014 — 2020,它一次次回到首页

    黑点是上首页(≥ 50 分)的那次投稿,空心点是没冲上去的投稿,点越大分数越高。

    导读

    这篇文章(Thomas Hühn 撰写,2014 年首发并持续更新)逐条反驳关于 /dev/urandom 的常见误解:它与 /dev/random 使用的是同一个 CSPRNG,一旦完成种子初始化就不会“耗尽熵”,而对 /dev/random 的阻塞读取本身会带来问题。作者承认真正需要担心的只是系统启动早期熵不足的情形,并建议使用 getrandom()、getentropy() 之类的接口。

    为什么经久不衰:它把流传多年的“urandom 不安全”迷思和真实的启动期熵问题分开讲清楚,多年来反复被引用,是理解 Linux 随机数接口的经典参考。

    关键词 随机数/dev/urandomLinux密码学

    HN 评论精选

    文章把特定平台的实现当成通用事实,据此写不可移植代码有风险。

    这些不是迷思,而是平台保证。只是碰巧几个最常见的 Unix(Linux、BSD)实现了非常好的 /dev/urandom,作者却在建议我们写依赖这些平台实现细节的不可移植软件。依赖不可移植的实现细节有好处,但也有明显的缺点。

    throwaway092834查看英文原文

    These aren't myths, they're platform guarantees. It just so happens that a few of the most common unixes (Linux, BSD) implement a very good /dev/urandom and the author is suggesting that we write non-portable software that depends on implementation details of these platforms. There can be benefits from depending on non-portable implementation details but also significant drawbacks.

    启动期熵不足会导致静默失败,阻塞读取至少能暴露问题。

    我可能记错,但之前不是有过用 /dev/urandom 在启动时生成密钥的安全问题吗?由于熵不足,urandom 造成了安全设计中的静默失败。我认为这是文章遗漏的关键点。静默的安全失败非常糟糕;阻塞至少能保证要么一切正常,要么问题被尽早发现。

    belorn查看英文原文

    I could be mistaken, but weren't there a security issue a while back with keys generated at boot time by using /dev/urandom? Since there weren't enough entropy, using urandom created an silent failure in the security design. I think this is a key point that the article is missing. Silent security failures are very, very bad. Blocking will at least provide assertion that either things are as expected, or the issue will be detected early.

    实证研究显示启动期熵空洞确实会造成可分解的 RSA 密钥等实际危害。

    虽然一般用 /dev/urandom 更好,但《Mining Your Ps and Qs》那篇论文呢?它发现:我们检查的每个软件包都依赖 /dev/urandom 生成密钥;然而 Linux 的 RNG 存在启动时熵空洞,在无头设备和嵌入式设备上可能出现的条件下会让 urandom 输出确定性结果。实验显示,重复输出不仅会导致重复的长期密钥,还会导致可分解的 RSA 密钥和重复的 DSA 临时密钥。文章末尾略有提及。Linux 在启动时阻塞 urandom 会是破坏性变更吗?

    Paul-ish查看英文原文

    While it may be generally better to use /dev/urandom, what about the Mining Your Ps and Qs paper?[1]. It finds that: > Every software package we examined relies on /dev/urandom to generate cryptographic keys; however, we find that Linux’s random number generator (RNG) can exhibit a boot-time entropy hole that causes urandom to produce deterministic output under conditions likely to occur in headless and embedded devices. In experiments with OpenSSL and Dropbear SSH, we show how repeated output from the system RNG can lead not only to repeated long-term keys but also to factorable RSA keys and repeated DSA ephemeral keys due to the behavior of application-specific entropy pools. This is mentioned a little at the end of the article. Would it be a breaking change for Linux to block urandom at startup? [1] https://factorable.net/weakkeys12.conference.pdf

    迷思在真实项目中反复造成 bug,作者呼吁把这些内容写进 man page。

    我已放弃这些迷思会消失的希望。每次相关话题出现,总有人跳出来抱怨 urandom 不安全或会耗尽熵。看看 Node、Ruby 和 WordPress 的 bug 就知道了。而最终诉诸权威时,引用的又总是这些项目。认真问一句:如果我提交一个补丁,把本页内容写进 man page,有没有可能被采纳,从而多少终结这些说法?

    technion查看英文原文

    I've given up on the hope that these myths will ever die. Every time it's relevant, someone pipes up complaining urandom isn't safe for use, or will run out of entropy. Have a look at the bugs for Node, Ruby and Wordpress. And inevitably, the appeal to authority ends up referring to these projects. Serious question, if I submitted a patch for the man page detailing the content of this myths page, is there a chance it might go somewhere and put somewhat of an end to some of this?

    历次讨论

    同类还值得读

    1. 非法素数

      Illegal prime

      维基百科条目,介绍“非法素数”:某些素数之所以被称为“非法”,是因为它们经特定编码后,恰好对应一段被法律禁止传播的数据——最著名的是 DVD 解密程序 DeCSS 的代码,有人把…

      安全与隐私上首页 5 次 · 2010–2021en.wikipedia.org编辑精选
    2. AES 高级加密标准火柴人图解

      A Stick Figure Guide to the Advanced Encryption Standard (AES)

      一篇用火柴人漫画形式讲解 AES(高级加密标准)算法的经典科普文章。

      安全与隐私上首页 5 次 · 2009–2022moserware.com编辑精选
    3. 指纹是用户名,不是密码

      Fingerprints are Usernames, not Passwords

      作者(eCryptfs 维护者、Ubuntu 安全工程师)认为指纹等生物特征是公开、不可更改的标识,应视作用户名而非密码,不能当作秘密凭据用于认证。

      安全与隐私上首页 4 次 · 2013–2017blog.dustinkirkland.com
    4. HTTPS 连接的最初几毫秒(2009)

      The First Few Milliseconds of an HTTPS Connection (2009)

      逐毫秒拆解一次 HTTPS 连接建立时发生了什么,重点讲 TLS 握手、证书验证、RSA 签名与密钥协商等机制,面向不熟悉该领域的读者。

      安全与隐私上首页 4 次 · 2009–2020moserware.com编辑精选
    5. Google 拥有我的大部分邮件,因为它拥有你所有的邮件(2014)

      Google has most of my email because it has all of yours (2014)

      作者(2014年)分析了自己社交网络中的邮件往来数据,发现由于大多数联系人都在用 Gmail,Google 实际上能看到他与几乎所有人的通信内容——即使他自己不用 Gmail,隐…

      安全与隐私上首页 4 次 · 2014–2025mako.cc

    打赏支持

    打赏二维码

    觉得有用,请作者喝杯咖啡。

    WeChat

    关注向阳乔木

    微信公众号「向阳乔木推荐看」

    微信公众号「向阳乔木推荐看」二维码

    微信扫一扫;在微信里打开本页时,长按二维码识别。