安全与隐私latacora.micro.blog
别再使用加密邮件了
Stop Using Encrypted Email
2020 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 Latacora（安全公司，作者包括 tptacek、lvh 等知名密码学工程师）的一篇文章，主张不要再折腾 PGP/S-MIME 这类邮件加密：邮件所依赖的 RFC 822/5321/IMAP 协议栈本身就无法做到安全——元数据（收发双方、时间、主题）暴露，没有前向保密，密钥管理复杂，端到端加密只在理想路径下成立。作者的结论是，与其教人配置 GPG，不如直接改用现代安全即时通讯工具，或者干脆不要把敏感信息放进邮件。
为什么经久不衰：它把“加密邮件等于安全”这个流行直觉拆得干净利落，而且提出的争论——用什么替代邮件的社会性功能——至今仍没有公认答案，所以每隔几年就会被重新翻出来吵一遍。
HN 评论精选
作者本人总结：易用性论证与安全无关，不该让真正需要安全的人去冒险用加密邮件。
简单概括这篇文章：每当有人说加密邮件在密码学上不如安全即时通讯时，人们就列出一堆易用性理由说即时通讯不可行——平台支持不好、没人想在手机上打字、要去中心化、不想装新软件等等。问题是这些理由都和安全无关。根本无法论证加密邮件和现代安全通讯工具一样安全；人们容忍邮件里糟糕的加密，只是因为易用性对他们比安全更重要。真正的麻烦在于，有些人是真的依赖消息安全的，让他们去搞一套加密邮件工作流是在冒不合理的风险。我们该告诉这些人的是：要么用安全通讯工具，要么别把自己置于风险之中。
tptacek查看英文原文
Sort of just generally, to word this post more simply: whenever the point is made that encrypted email is cryptographically inferior to secure messengers, people respond with a litany of ergonomic reasons why secure messengers aren't viable: they don't have the right platform support, nobody wants to type on their phones, people want decentralized platforms, nobody wants to install new software, and on and on. The problem with these arguments is that they have nothing to do with security. There's simply no case that can be made that encrypted email is as secure as a modern secure messenger. People tolerate shoddy encryption in email because ergonomics are more important to them than security. The problem here is that there are real people who depend on the security of their messages who would be taking unreasonable risks in trying to get an encrypted email workflow going. Rather than telling these people to read a GPG tutorial or install Enigmail or whatever, we should be telling them either to use a secure messenger, or not to put themselves at risk at all.
质疑：邮件的长篇、异步、可冷启动等社会性功能无可替代，而作者没给出替代方案。
我再说一遍上次说过的：那我们该用什么？如果想要安全的消息传递，又要保留邮件的那些社会性功能，该用什么？至今没有答案！Signal 不行，它复制的是短信而不是邮件。具体来说：1）邮件可以是长篇的，我坐下来在电脑上敲；短信总是短的，一连串短邮件只会让人烦，你也不会用邮件快速来回对话。2）邮件意味着你不必立刻读——短信大概几分钟内会被读、当天回复；邮件大概几小时内读、几天内回。3）给陌生人发冷邮件是正常的，发短信得先有手机号，那是给认识的人用的；而邮箱地址常常是公开出来专门让陌生人联系的。那么，要复制这些的安全消息方案是什么？除了据说很糟的 PGP，我得到的最好答案是“装个 Signal……”。
Sniffnoy查看英文原文
I'm going to say the same thing I said last time this came up -- so what should we use instead, then? What do we use if we want secure messaging, but with the (social) affordances of email? There still doesn't seem to be any answer to that! No, Signal is not an acceptable answer; it replicates text messaging, not email. In more detail: 1. Email is potentially long-form. I sit down and type it from my computer. Text-messaging is always short, although possibly it's a series of short messages. A series of short emails, by contrast, is an annoyance; it's something you try to avoid sending (even though you inevitably do when it turns out you got something wrong). Similarly, you don't typically hold rapid-fire conversations over email. 2. On that point, email says, you don't need to read this immediately. I expect a text message will be probably be read in a few minutes, and probably replied to later that day (if there's no particular urgency). I expect an email will be probably read in a few hours, and probably replied to in a few days (if there's no particular urgency). 3. It's OK to cold-email people. To text someone you need their phone number; it's for people you know. By contrast, email addresses are things that people frequently make public specifically so that strangers can contact them. So what am I supposed to do for secure messaging that replicates that? The best answer I've gotten for this so far -- other than PGP which is apparently bad -- is "install Signal on your computer in addition to your phone and just use it as if it's email". That's... not really a satisfactory answer. Like, I expect a multi-page Signal message talking about everything I've been up to for the past month to annoy its recipient, who is likely reading it on their phone, not their computer. And I can't send someone a Signal message about a paper they wrote that I have some comments on, not unless they're going to put their fricking phone number on their website. So what do I do here? The secure email replacement just doesn't seem to be here yet. (I'm guessing in case (3), the authors would suggest just using unencrypted email, but what about problems (1) and (2)?)
批评文章陷入零和谬误：不完美不等于无用，部分防护仍有价值。
作者说不该用邮件加密，但纯文本发邮件又有什么道理？加密邮件难道会在某种程度上有损我的隐私？还是说论点其实是加密邮件没用、和明文一样（因为服务器上总是明文），那为什么还要避开它？两者不是等价、这个区分毫无意义吗？这就是我对这篇文章的不满：它有点零和谬误——“能被攻破所以根本就是坏的”。更合理的思路是概率：我给 SSH 关掉密码认证只允许公钥，攻击者仍可偷我私钥进来，但这不构成反其道而行的理由——僵尸网络天天扫全网猜密码，所以不完美并不等于没用。安全没有银弹，只有层层策略和对边界情况的适应。文章里关于邮件加密局限的部分（邮件链的例子很好，提醒安全常常是人的行为问题而非软件问题）我挺喜欢，但如果标题改成“邮件加密救不了你”这种不那么教条的论点会更有说服力。
supernintendo查看英文原文
The author says not to use email encryption but what is the case for sending email in plain text? Is encrypted email detrimental to my privacy in some way that unencrypted email is not? Or if the argument is that encrypted email is useless and no better than unencrypted email (since it is always unencrypted at rest) then what is the point of avoiding it in favor of the alternative? Aren't they equivalent, making the distinction meaningless? This is my problem with the article. It feels like it suffers from a bit of zero-sum fallacy. The statement here is, "it can be broken therefore it's fundamentally broken." I think it's more useful to think in terms of probabilities. If I disable password authentication for SSH and require public key authentication on my web server, an attacker can still get in by stealing my private key. That isn't a reason to take the opposite approach however - botnets commonly employ password-guessing attacks against entire IP ranges so you're not actually safer by avoiding this practice just because it isn't a perfect solution. There is no silver bullet for security, only endless layers of strategies and adaptations to edge cases. I did enjoy some of the points about the limitations of email encryption (the email chain example is a great reminder of how security is often more about human behavior than software). But I think the article could have been more compelling had it presented a less dogmatic thesis - perhaps "Email Encryption Won't Save You" or something like that.
强调邮件的开放协议属性是最大优点，替代方案必须保留去中心化的可互操作实现。
邮件和作者推荐的系统有个巨大差别：邮件是标准和协议，而那些系统基本是单一权威维护的单一实现。有些权威有防腐败的结构——热心的人、非营利或开放治理——但它们仍然是单点故障、是攻击目标。这些年受够了规格描述不力、实现难以验证的痛苦后，现代密码系统开始流行“严格集中控制参考实现以保证正确性”（也就是苹果模式）。这确实能保证高质量、少出问题的实现，但也带来单点故障问题。我认为邮件的替代品必须保留邮件最大的优点：它是开放规格，而不是某个实体拥有或控制的系统或实现。真正的挑战不只是聪明的协议和密码学设计，还在于协议定义与实现验证上的实质进步，使任何有能力的开发者都能实现可互操作的组件并接入。
a-dub查看英文原文
one big difference between email and the systems that the author suggests is that email is a standard and a protocol, where the systems referenced by the author are pretty much single implementation systems maintained by a single authority. some of these authorities have all sorts of structure to prevent corruption. passionate people, nonprofit or open governance. however, they are still single points of failure, or targets, or whatever you'd like to call them. it seems that after years of pain with poor effectiveness of specification or poor verification tools for implementations, it has become en vogue for modern cryptosystems to insist on tight centralized control of reference implementations to ensure correctness. (otherwise known as the apple computer model). while this does seem to work in terms of ensuring high quality and problem free implementations, it does open up the single point of failure issue. i'd argue that email's replacement must retain email's greatest quality: it's an open specification, not a system or implementation owned or controlled by a single entity and that the true challenge in bringing it to fruition won't be clever protocol and cryptographic design (although these will be crucial) but also substantial advances in protocol definition and implementation verification such that any competent developer can implement compatible components and plug them in.
历次讨论
同类还值得读
非法素数
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编辑精选