使用Diffie-Hellman密钥交换和AES进行客户端HTTPencryption

在观看Diffie-Hellman密钥交换中的YouTubevideo后，我想尝试使用JavaScript实现（阿特伍德定律）。

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

• 第1步：客户端和服务器在共享密钥上达成一致：

  • 客户端和服务器从512位主要公钥pK开始

  • 客户端生成一个512位主密钥kC，并发送powMod（3，kC，pK）

  • 服务器生成一个512位主密钥kS，并发送powMod（3，kS，pK）

  • 客户端和服务器使用powMod（response，privatekey，pK）作为共享密钥

• 第二步：沟通

  • 在客户端发送数据之前，使用Stanford Javascript Crypto Library（256位AES，HMACauthentication，PBKDF2密码加强和CCMauthenticationencryption）使用共享密钥encryption。

  • 一旦服务器使用共享密钥解密数据，它将生成一个新的512位主密钥，并将其作为SJCLencryption响应发送。

  • 客户端和服务器使用powMod（3，prevSharedKey，newPrivKey）切换到新的共享密钥

现在我有几个问题

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

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

Answer 1

我曾经见过这样的问题 – 由于多种原因 ，这是完全不安全 的 ，其中最主要的是JavaScript客户端无法validation服务器的密钥是否可信。

简而言之，没有SSL，就容易受到中间人攻击。 没有基于浏览器的JavaScriptencryption实现可以克服这个事实。

Answer 2

你的系统是大规模的不安全的，但我不是想阻止你或任何人玩弄这样的东西。 你应该继续。 但是，至关重要的是，您认为您创build的任何东西都是“玩具”系统，绝对不应该被视为“安全”或被宣传为“安全”。

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

1. 密钥交换有多安全？
2. 一旦获得共享密钥，您使用的encryption有多安全？

我先回答（2），因为那将是最简单的。 除非你比那些多年来从事和研究过红绿灯系统的人都聪明，否则这将是非常不安全的。 在1.2版之前的TLS（很less有站点使用）在原则上容易受到select的密文攻击（CCA）的影响，在实践中受到密码套装select的影响。 而且SSL 2.0更糟。

关键是非常非常聪明的人，在这些协议上工作多年，有些事情是错误的。 有充分的理由相信你是我自己在做这些事情会犯很大的错误。 基本的encryptionalgorithm很好。 他们没有破碎。 但协议是。

所以，如果你没有学习和完全理解SSL的所有细节，为什么他们在那里，在某些情况下他们是怎么出错的，那么几乎可以肯定的是，你devise的任何协议都是可怕的。

现在来质疑（2）。 这有两个问题。 （a）Diffie-Hellman不是为了提供您可能需要的种类的安全性而devise的; 和（b）我不认为你已经正确实施了DH。

2.A：

Diffie-Hellman密钥交换（如果正确完成）对于密钥交换来说是安全的，但它对于身份validation没有任何作用。 这就是为什么“安全”这个问题往往是错误的问题。 对某些目的来说是安全的，但是对于其他目的而言，这是不安全的。

正如Josh3737所指出的那样，客户端和服务器无法知道他们正在与正确的方进行对话。 如果山姆是服务器，查理是客户，那么没有什么能够阻止马洛里build立自己的服务器来伪装山姆。 所以凯茜可以通过与马洛里的重要交stream，认为她正在和山姆交谈。 与马林谈话时，马洛里可以假扮成查理。

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

为了解决authentication问题，你需要某种公钥基础设施（PKI），这真的很痛苦。 证书颁发机构和SSL / TLS的系统充满了问题，但它仍然是最好的系统。

2.B：

一个512位的公共模数和512位私钥不够强大。 DH键需要更大。 我不会用任何less于2048位的东西去。 你可能会离开1024位，你不担心有人能够打破五年的今天的秘密。

你没有提供足够的关于你的素数是如何select的信息。 不是每个素数都能工作。 你需要为你的模数使用一个“安全素数”，否则攻击者就有快捷方式来计算离散对数。

Answer 3

如果你想解决中间问题的SSL证书和人，你可以使用比特币区块链。 （或者一个altcoin区块链。）

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

有两个公钥/私钥对：

CERTpublicCERTprivate

CLIENTpublic CLIENTprivate

名字注册：

Server -> CERTpublic and name_to_register -> Bitcoin Blockchain 

authentication连接：

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