安全与隐私signal.org
Signal 的私有联系人发现技术预览
Technology preview: Private contact discovery for Signal
2017 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Signal 官方博客介绍其“私密联系人发现”技术预览：借助 Intel SGX 安全飞地，让服务器在无法得知用户通讯录明文的情况下完成联系人匹配，避免传统“上传通讯录”带来的隐私泄露。文章详细讲解了基于哈希、盲化和远程证明的服务端设计。
为什么经久不衰：它是隐私工程领域将安全飞地用于大规模真实服务的早期经典案例，其设计思路与权衡至今仍是隐私计算讨论的参照。
HN 评论精选
批评 HN 上对 Signal 的吹毛求疵，认为推荐 imperfect 但优秀的隐私工具才是对隐私事业负责
我预感到 HN 评论区会是什么样，果然。总有人抱怨它不是完美安全、要信任 CPU 厂商、权限太侵入、用手机号做标识、依赖 Google 服务。请抬头看森林而不是盯着树木：人类急需“隐私群体免疫”，而你在扮演数字反疫苗者。Signal 是目前最好的隐私选择之一：由领域领袖精心设计、可靠、UI 良好、真正开源。人们需要一个替代 Facebook Messenger、WhatsApp、闭源 Telegram 和运营商短信的方案。拒绝推荐这么强的竞争者，实际上是在伤害隐私和开源事业。有意见就去提 PR 或做兼容分支，别再劝阻人们保护自己。
ohthehugemanate查看英文原文
I cringed in anticipation of the HN comments on this one. Cue the inevitable HN complaints that it's not perfect security, that you still have to trust your CPU manufacturer, that the app permissions are too invasive, that it uses phone numbers as identifiers, and that it runs on Google play services. Pull your head out of the trees and look at the forest: humanity desperately needs privacy herd immunity, and you are taking the part of digital anti-vaxxer. Signal is one of the best options available for privacy: thoughtfully architected by a leader in the field, reliable, with a good UI and reasonable adoption, and genuinely open source. People NEED an alternative to Facebook messenger, Facebook WhatsApp, closed source Viber and Telegram, and carrier SMS. By refusing to recommend this extremely good, strong contender, you are actively hurting the causes of privacy and open source. Stop being a digital anti-vaxxer. If you have complaints, submit a PR or make a compatible fork. But stop discouraging people from protecting themselves. Or alternatively: if you're going to be a digital anti-vaxxer, hit up Facebook, Google, or the NSA to see if they'll send you a paycheck for it. Because doing their jobs for free is just dumb.
指出 SGX 在物理侧信道和 Intel 签名垄断两方面的局限
这确实有趣（可能是我见过的第一个对终端用户有价值的 SGX 服务器端应用），但有两个问题：1) SGX 并不能真正抵御有一定能力的物理侧信道攻击，对单一中心服务来说不如传统 HSM；2) Intel 仍是 SGX 应用的守门人，release 模式需要 Intel 签名的密钥，获取需要商业协议；debug 模式下任何人用调试器就能拿到密钥。如果 Intel 修复后者，前者在很多场景下就不再是致命问题。
rdl查看英文原文
This is definitely interesting (and probably the first end-user-valuable SGX-on-server application I've seen), but there are two issues IMO: 1) Intel SGX isn't really capable of resisting moderately serious physical side channel attacks by someone with physical proximity or access to the server. It's decent for low-value, or widely deployed apps where compromise of a single instance only hurts once user, but for a central singular service, less so. Inferior to, say, a conventional HSM with code run inside it. (SGX would be great for client-side stuff, or for, say, a Tor or multi-server VPN server array, which is something I worked on using TXT before.) 2) Intel's still a gatekeeper on what SGX applications can be meaningfully distributed; to run in release-mode, you need a key signed by them, and to get this requires a commercial agreement. If you run in debug or pre-release, anyone with a debugger can pull keys. If Intel were to fix the latter (even if it cost, say, $100 to get the signing rights, or some non-discriminatory "you must do X, Y and not A, B" were published), the former wouldn't be a deal-killer for some things. If the server operator were a mostly-trusted third party (e.g. a cloud provider), and the people writing and signing the code were never able to get physical access to the hardware, it might work a lot better in most server threat models. In Signal's particular case it's probably true that most Signal users trust Moxie/OWS, and this is really about putting a much higher bar in place for government compulsion to tamper with or disclose the contact info, so this is a net win.
质疑远程证明后流量被重定向的可能，以及 Intel 验证服务带来的元数据泄露
Signal 用 SGX 安全飞地设计新的联系人发现服务器，无疑很有前景。我的问题是：服务器给客户端发了正确的远程证明后，能否立刻把网络流量重定向到另一台跑着非 SGX 代码的服务器？另外，验证 SGX 远程证明是否需要联系 Intel？如果是，Intel 是否能据此画出 Signal 用户的 IP 关系图？Matthew Green 对第一个问题给出了可信的回答。
mintplant查看英文原文
In case someone from Open WhisperSystems is reading: please add stickers. Seriously, I know so many people who are on Telegram just because of its sticker system and won't consider anything without that feature. This comes up again and again in online discussions where Signal is mentioned, and it hurts to see all the care and effort the OWS team has put into providing real security rejected out of hand because of it. For the uninitiated, stickers are essentially a UI layer on top of image sending. Each user has a collection of stickers which they can add images to. This collection can be scrolled through quickly and any sticker can be sent to a chat with a tap, like a sort of custom emoji. Other users who see a sticker can add it to their own local collection by tapping on the sticker message. I see no technical reason why this couldn't be built on top of the Signal Protocol.
认为 SGX 信任链过于复杂难以验证，简单哈希方案反而更可信
这如何确保服务器上的代码真的运行在安全飞地里而不是模拟器中？或者整个证明本身就是伪造的？我们怎么知道开发 SGX 的团队没有和 NSA 密切合作？我可能只会把电话号码和用户号码拼接，加个难猜的盐（比如道琼斯指数），再用 bcrypt 哈希。不完美，但够用，而且最重要的是更容易验证。SGX 依赖 Intel 的远程证明服务，代码由 Intel 签名，信任链根植于 Intel 持有的密钥——构造很聪明，但聪明得让人不放心。
captainmuon查看英文原文
How does this ensure that the code on the server is running on the secure enclave, and not in an emulation[2]? Or that the whole attestation is not emulated? How do we know that the team who built the SGX does not work closely with the NSA[1]? I would probably just concatenate the phone numbers with the user's numbers, throw in some hard to guess salt like the Dow Jones index, and hash it with bcrypt. It's not perfect, but I would consider it good enough. And most importantly, easier for me to verify. ([1] Only half kidding: My favorite paranoid theory is that most security tech is thoroughly backdoored, and most of the 30000-40000 employees of NSA are actually doing parallel contruction all day long for the data they get this way.) [2] Edit: from skimming the previous HN discussion, it seems that SGX relies upon Intel's remote attestation service. The code you run is signed by Intel, and you have a chain of trust stemming from a key held by Intel. It's a clever construction, but I still feel it is too clever to be comfortable with.
希望 Signal 保持纯粹的加密通讯工具定位，而非社交化
“Signal 是社交软件，我们不认为隐私意味着苦行。”我不同意。我只想要一个端到端加密、跨平台的短信替代品。我不认为短信是“社交软件”，Signal 越想做成社交网络，我就越不安。我感谢它不像 Telegram 那样要求通讯录权限，但我希望它根本别碰我的联系人列表。
mikece查看英文原文
"Signal is social software. We don’t believe that privacy is about austerity, or that a culture of sharing and communication should mean that privacy is a thing of the past." I don't agree. All I want from Signal is an e2ee, cross-platform replacement for SMS. I don't think of SMS as "social software" and to the degree Signal keeps acting like it wants to be a social network the more uneasy it makes me. I do appreciate that, unlike Telegram, I can use Signal without giving it access to my contacts but I wish it didn't try to leverage my contacts list at all.
历次讨论
同类还值得读
非法素数
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编辑精选