安全与隐私matasano.com编辑精选
JavaScript 密码学被认为有害
Javascript Cryptography Considered Harmful
2011 — 2014，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇 Matasano 的文章主张，在浏览器里用 JavaScript 实现加密通常弊大于利：服务端可以随时下发恶意脚本，浏览器运行时和密钥存储都不可信，JS 加密容易制造虚假安全感；而如果已有 TLS/SSL 安全通道，往往就不需要它。文章也承认某些场景（如客户端解密服务器上的密文）仍有需求，但强调必须从威胁模型出发，不能把 JS 加密当成万能的安全边界。
为什么经久不衰：它把浏览器内加密的根本信任问题讲得直白，成为之后 Keybase、Google End-to-End 等客户端加密方案反复被拿来对照的经典文本。
HN 评论精选
SSL 传输 JS 加密可行且会使其多余，但客户端解密等非安全通道场景仍可能需要 JS 加密。
小异议：文章问“为什么不能用 TLS/SSL 来传输 JavaScript 加密代码？”其实可以。用 SSL 安全传输 JS 加密代码比听起来难，但可行。问题是一旦用 SSL 建好安全通道，你就不再需要 JS 加密了，你已经有了“真正”的加密；同时 JS 加密代码仍受其他浏览器问题威胁。我的小异议是，除了建立安全通道，人们可能还有其他理由需要加密，所以 SSL 不一定解决原本想用 JS 加密解决的问题。例如客户端需要服务器上加密存储的数据，并希望在客户端解密。
tzs查看英文原文
Minor quibble: WHY CAN'T I USE TLS/SSL TO DELIVER THE JAVASCRIPT CRYPTO CODE? You can. It's harder than it sounds, but you safely transmit Javascript crypto to a browser using SSL. The problem is, having established a secure channel with SSL, you no longer need Javascript cryptography; you have "real" cryptography. Meanwhile, the Javascript crypto code is still imperiled by other browser problems My minor quibble is that there are other reasons one might want cryptography besides establishing a secure channel, and so using SSL does not necessarily solve whatever problem one was trying to solve with JavaScript. For instance, the client might need data that is stored encrypted on the server, and you want to do the decryption on the client.
这些批评同样适用于桌面下载软件，并非 JS 独有。
通过网络下发加密软件、让它在“可塑”的运行时里运行，并让用户以为它安全，这并不新鲜；桌面软件多年如此。我想问作者：你们“JavaScript 加密有害”的前提，不也同样适用于下载的桌面软件吗？鸡生蛋问题、拥有管理员权限应用的可塑运行时、代码验证被系统其他恶意应用击败、安装加密应用前已有敌意应用导致无法信任安全密钥库、伪随机性弱点。
d2查看英文原文
Delivering cryptographic software via a network, having it run in a "maleable" runtime and creating a user expectation that it will be secure, is not new. We've been doing this on the desktop for years. I'd like to pose a question to the authors: Don't all the premises you've based "Javascript Cryptography Considered Harmful" on apply equally to downloaded desktop software? -A chicken egg problem -A malleable runtime for apps with admin access -Code verification being defeated by other hostile apps on the system -Inability to trust the secure keystore because of the chicken-egg problem and other hostile apps installed prior to the crypto app's installation. -The weakness of pseudo-randomness
应按威胁模型评估：JS 加密虽不完美，但能显著提高大规模拖库和针对性窃取的门槛。
我不同意：仅因恶意或被攻陷的服务器可能发送恶意 JavaScript，就不该做 JS 加密。要看威胁模型。以笔记 Web 应用为例：不用 JS 加密，任何攻破服务器的人都能读所有人的笔记；FBI 也可凭搜查令让站长交出所有人的笔记。若用 JS 加密，FBI 就不能只查机器，还得说服站长修改源码以针对单个用户窃取密钥，这是很大差别；而且受害者须重新登录攻击才成功，若几周前用过就离开则安全。入侵者也不能一次拖走所有笔记；须改源码，可能被站长和用户发现，且比普通扫射攻击更复杂。所以 JS 安全现在不完美，但不该被否定。
utnick查看英文原文
I disagree that just because its possible for a malicious or comprimised server to send evil javascript, javascript crypto should not be done. You have to analyze the threat model. Take the note taking webapp they use as an example. Without javascript crypto, anyone who breaks into the server can read everyones notes. Likewise, the FBI can get a warrant and have the owner of the web application turn over everyones notes. If they do use javascript crypto, instead of just getting a warrant for the machine, the fbi has to convince the owner of the site to modify their source code to target an individual user to steal their key. That is a significant difference. Also, the victim user has to log in again for that attack to be successful, if they just used the server for a couple weeks and left, they are safe. Likewise, an attacker who breaks into the server can't get a dump of all the notes in the system. They again have to modify the source code which could be noticed by the owners and users and takes some level of sophistication more than the average aim and shoot attacker So is javascript security perfect right now? no... but that doesn't mean it should be dismissed
Google End-to-End 直接挑战了文章论点，而作者一方未见公开回应。
自本文发表后，Google 发布了基于 JS 的加密工具 End-to-End 的 alpha 版；他们直接回应了部分反对 JS 加密的论点。End-to-End 发布时我好奇“JavaScript 加密有害”的支持者会不会回应，但我没看到，这里也没看到。我很想看到为何 Google 方案有缺陷的回应。
haberman查看英文原文
Since this article was written, Google released an alpha version of a JS-based crypto tool: http://googleonlinesecurity.blogspot.com/2014/06/making-end-to-end-encryption-easier-to.html They directly address some of the arguments against JS crypto: https://code.google.com/p/end-to-end/ When End to End was released I was curious if any proponents of "JS Crypto Considered Harmful" would have a response, but I didn't see one, nor do I see one here. I would be interested to see a response for why the Google approach is flawed.
历次讨论
同类还值得读
非法素数
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编辑精选