12

在观看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 选项是否矫枉过正？是否值得调制共享密钥？谢谢阅读！

4

3 回答 3

18

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

让我们将安全问题分为两部分。

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

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

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

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

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

2.一：

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

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

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

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

2.b：

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

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

于 2013-05-09T17:46:53.297 回答
7

我以前见过这样的问题——这是完全不安全 的，原因有很多，其中最重要的是 JavaScript 客户端不可能验证服务器的密钥是真实的。

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

于 2012-03-23T03:13:50.607 回答
0

如果你想绕过 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
于 2014-01-24T04:08:35.303 回答