使用 Diffie-Hellman 密钥交换和 AES 通过 HTTP 进行客户端加密答案

【问题标题】：Client-side encryption over HTTP with Diffie-Hellman Key Exchange and AES使用 Diffie-Hellman 密钥交换和 AES 通过 HTTP 进行客户端加密
【发布时间】：2014-03-28 21:22:08
【问题描述】：

在Diffie-Hellman Key Exchange 上观看 YouTube 视频后，我想尝试用 JavaScript（阿特伍德定律）实现。

我用以下规则在 Node.js 上勾勒出一个密码：

第 1 步：客户端和服务器就共享密钥达成一致：
- 客户端和服务器以 512 位素数公钥 pK 开始
- 客户端生成 512 位素数私钥 kC 并发送 powMod(3, kC, pK)
- 服务器生成 512 位素数私钥 kS 并发送 powMod(3, kS, pK)
- Client & Server 使用 powMod(response, privatekey, pK) 作为共享密钥
第 2 步：沟通
- 在客户端发送数据之前，使用斯坦福 Javascript 加密库（256 位 AES、HMAC 身份验证、PBKDF2 密码强化和 CCM 身份验证加密）使用共享密钥对其进行加密。
- 一旦服务器使用共享密钥解密数据，它就会生成一个新的 512 位素数私钥并将其作为 SJCL 加密响应发送。
- 客户端和服务器使用 powMod(3, prevSharedKey, newPrivKey) 切换到新的共享密钥

现在我有几个问题..

与 HTTPS 或其他算法相比，这样的系统的安全性如何？这种系统的弱点是什么？

在安全性/实用性方面，使用 1024 位密钥会更好吗？ HMAC/PBKDF2/CCM 选项是否矫枉过正？是否值得调制共享密钥？感谢阅读！

【问题讨论】：

标签： javascript node.js encryption aes diffie-hellman

【解决方案1】：

您的系统非常不安全，但我并不是要劝阻您或任何人不要玩弄这样的东西。你应该继续。但至关重要的是，您将创建的任何东西都视为“玩具”系统，绝不应将其视为或宣传为“安全”。

让我们把安全问题分成两部分。

密钥交换的安全性如何？
获得共享密钥后，您使用的加密有多安全？

让我先回答（2），因为那将是最简单的。除非您比所有多年来从事和研究 TLS 的人都聪明，否则它将非常不安全。 1.2 版之前的 TLS（很少有网站使用）原则上容易受到选择密文攻击 (CCA) 的攻击，而在实践中则容易受到 BEAST attack 的攻击，具体取决于密码套装的选择。而且 SSL 2.0 被破坏得更严重。

关键是非常非常聪明的人，多年来一直在研究这些协议，但在一些事情上出错了。完全有理由相信你是我自己做这些事情会犯巨大的错误。基本的加密算法很好。他们没有坏。但协议是。

因此，如果您还没有研究并完全理解 SSL 的所有细节、它们存在的原因以及它们在某些情况下是如何出错的，那么几乎可以肯定，您设计的任何协议都会很糟糕。

现在问题 (2)。这有两个问题。 (a) Diffie-Hellman 并非旨在提供您可能需要的那种安全性； (b) 我认为您没有正确实施 DH。

2.a:

Diffie-Hellman 密钥交换如果操作正确，对密钥交换是安全的，但对身份验证没有任何作用。这就是为什么“它是否安全”这个问题通常是错误的问题。它在某些用途上是安全的，但对于其他用途却非常不安全，因为它不是为其他用途而设计的。

正如Josh3737 指出的那样，客户端和服务器无法知道他们正在与正确的一方交谈。如果 Sam 是服务器，而 Charlie 是客户端，那么没有什么可以阻止 Mallory 设置自己的伪装成 Sam 的服务器。因此，Cathy 可以通过与 Mallory 的密钥交换，认为她正在与 Sam 交谈。与 Sam 交谈时，Mallory 可以伪装成 Charlie。

一旦以这种方式设置，马洛里就可以充当山姆和查理之间的中间人。当 Charlie 向 Sam 发送数据时，Mallory 将使用 C 和 M 之间的共享密钥对其进行解密，读取它（并可能更改它），然后使用 M 和 S 之间的共享密钥对其进行重新加密并将其发送给 S .

要解决身份验证问题，您需要某种公钥基础设施 (PKI)，而这些确实很麻烦。我们使用 SSL/TLS 的证书颁发机构等系统充满了问题，但它仍然是目前最好的系统。

2.b：

512 位公共模数和 512 位私钥不够强大。 DH 密钥需要更大。我不会使用少于 2048 位的任何东西。您可能会逃脱 1024 位，您并不担心五年后有人能够破解今天的秘密。

您没有就如何选择素数提供足够的信息。并非每个素数都会起作用。您需要对模数使用“安全素数”，否则攻击者可以使用快捷方式来计算离散对数。

【讨论】：

我实际上认为基于 HTTPS/TLS 的 DH 可以很好地工作......我担心可能会损坏 CA，并且将 DH 与经过身份验证的通道结合起来可能至少很有趣......感谢您对模数/密钥长度的建议，尽管我更关心的是浏览器在 JS 中计算共享密钥（例如在典型的智能手机上）可能需要多长时间。
@Tracker1，谈到安全性，只有两条路可以走：认真对待或根本不考虑。如果数据值得在开始之前等待一整分钟，甚至更长时间，那么用户会抱怨、诅咒和发誓，但会等待，否则，使用超轻量级的东西，只是为了让最懒惰的黑客远离，因为在任何方面，包括黑客的努力，都不值得。请注意，任何“中间替代方案”很可能是不安全的。我的银行应用程序很慢，占用内存并且设置起来很糟糕，但我对此很满意，因为它比去银行更安全。
@Cyberknight 这不是需要多长时间的问题......它是否实际工作的问题......如果它杀死了浏览器，那么它就不起作用了。

【解决方案2】：

我见过像 before 这样的问题 - 这是完全不安全 for a number of reasons，其中最重要的事实是 JavaScript 客户端无法验证服务器的密钥是正宗的。

简而言之，如果没有 SSL，您很容易受到中间人攻击。没有基于浏览器的 JavaScript 加密实现可以克服这个事实。

【讨论】：

实际上，以受信任的方式将 JS 传递给客户端的唯一方法是通过 SSL。既然你的连接已经是安全的，那你自己加密又有什么意义呢？
@josh3736，例如，重点可能是防主机托管 (ajaxpatterns.org/Host-Proof_Hosting)。诸如密码管理器之类的保险箱。但这可能与上述情况无关。
他从未说过他的工作是基于浏览器的。他特别说他是在 node.js 中编写的。即使他没有，它也可以在许多其他地方和离线应用程序中使用。无视他的问题，只是告诉他这完全不安全是非常没有效率的。
这是一个非常不具建设性的答案，不应被接受。源代码出处问题与在 JS 中编写 DH 相关的任何可能问题是正交的。这个答案是“中庸之道”的教科书示例：news.ycombinator.com/item?id=4693920。尖酸刻薄，足以获得支持，但没有增加讨论。
-1 可怕而刻薄的答案。所描述的方案是对普通 HTTP 的巨大改进，因为成功地攻击它需要主动的中间人攻击。换句话说，只有沿途的某些路由器受到损害时，它才可能受到损害。是的，不理想，但并不完全常见——例如，您上一次遇到欺骗性 DNS 回复是什么时候？这个问题值得一个正确的答案。

【解决方案3】：

如果你想绕过 SSL 证书和中间人的问题，你可以使用比特币区块链。（或山寨币区块链。）

巨大的警告：客户端必须下载或维护区块链的整个文件。

有两个公钥/私钥对：

CERTpublic CERTprivate

CLIENTpublic CLIENTprivate

姓名注册：

Server -> CERTpublic and name_to_register -> Bitcoin Blockchain

经过验证的连接：

Client <- CERTpublic <- Bitcoin Blockchain
Client -> CERTpublic(CLIENTpublic) -> Server or Adversary
Client <- No_response_or_incorrect <- Adversary 
Client <- CLIENTpublic(CERTprivate(content)) <- Server

【讨论】：

我想我在这里遗漏了一些东西。第一步，客户必须从比特币区块链接收 CERTpublic。这不是来自服务器吗？客户如何确定 CERTpublic 来自比特币区块链，而不是来自冒充它的中间人？
因为比特币是解决拜占庭将军问题的方法。换句话说，由于比特币的工作方式，客户端有可能知道它收到的证书是合法的。这类似于比特币客户判断付款是否合法的方式。实际上，这个确切的用例是在 Namecoin 中实现的。我在这里写过：sequentialread.com/…