Question

在观看Diffie-Hellman Key Exchange上的YouTube视频后，我想尝试使用JavaScript实现（Atwood定律）。

我使用以下规则在Node.js上绘制了一个密码：

步骤1：客户端和服务器就共享密钥达成一致：
- 客户＆amp;服务器以512位主要公钥pK
- 客户端生成512位主要私钥kC并发送powMod（3，kC，pK）
- 服务器生成512位主要私钥kS并发送powMod（3，kS，pK）
- 客户＆amp;服务器使用powMod（响应，私钥，pK）作为共享密钥
第2步：沟通
- 在客户端发送数据之前，使用Stanford Javascript加密库（256位AES，HMAC身份验证，PBKDF2密码加密和CCM身份验证加密）使用共享密钥对其进行加密。
- 一旦服务器使用共享密钥解密数据，它就会生成一个新的512位主要私钥，并将其作为SJCL加密响应发送。
- 客户端和服务器使用powMod（3，prevSharedKey，newPrivKey）切换到新的共享密钥

现在我有几个问题..

与HTTPS或其他算法相比，这样的系统有多安全？这种系统最薄弱的地方是什么？

在安全性/实用性方面，使用1024位密钥以提高安全性会更好吗？ HMAC / PBKDF2 / CCM选项是否过度杀伤？是否值得调整共享密钥？谢谢你的阅读！

Answer 1

你的系统非常不安全，但我并不是想阻止你或任何人玩弄这样的东西。你应该继续。但至关重要的是，你认为你创造的任何东西都是一个永远不应被视为“安全”的“玩具”系统。

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

密钥交换有多安全？
获得共享密钥后使用的加密有多安全？

让我先回答（2）因为那是最简单的。除非你比那些多年来一直在研究和研究TLS的所有人更聪明，否则这将是非常不安全的。版本1.2之前的TLS（少数站点使用）在原则上容易受到选择的密文攻击（CCAs）的影响，并且在实践中容易受到BEAST attack的影响，具体取决于密码套装的选择。而SSL 2.0则更为严重。

关键是非常聪明的人，多年来研究这些协议，有些不对劲。我有充分的理由相信你是我自己在做这些事情会犯很大的错误。基本的加密算法很好。他们没有被打破。但协议是。

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

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

2.A：

Diffie-Hellman密钥交换，当正确完成时，对于密钥交换是安全的，但它不会对身份验证做任何事情。这就是为什么“它是安全的”这个问题通常是错误的问题。它对于某些目的是安全的，但对于其他目的而言是非常不安全的，因为它不是为其他目的而设计的。

正如Josh3737指出的那样，客户端和服务器无法知道他们正在与正确的一方通话。如果Sam是服务器而Charlie是客户端，那么没有什么可以阻止Mallory建立自己伪装成Sam的服务器。所以凯茜可以和马洛里进行密切交流，以为她正在和萨姆谈话。马洛里在与萨姆交谈时可以假装成查理。

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

要解决身份验证问题，您需要某种公钥基础结构（PKI），这些真的很痛苦。我们拥有SSL / TLS的证书颁发机构系统充满了问题，但它仍然是最好的系统。

2.B：

512位公共模数以及512位私钥不够强大。 DH键需要更大。我不会选择低于2048位的东西。你可能会忘记1024位，你不担心有人能够在五年之后打破今天的秘密。

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

Answer 2

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

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

Answer 3

如果您想绕过SSL证书并解决中间问题，可以使用比特币区块链。（或者是一个山寨币区块链。）

The Huge Caveat：客户必须下载或维护区块链的整个文件。

有两个公钥/私钥对：

CERTpublic CERTprivate

CLIENTpublic CLIENTprivate

姓名注册：

Server -> CERTpublic and name_to_register -> Bitcoin Blockchain

AUTHENTICATED CONNECTION：

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

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

3 个答案: