客户端和服务器具有长期永久密钥，并且每个密钥都有 连接，他们创造并安全地交换短期瞬态 键。每个密钥都是公共/秘密密钥对，遵循椭圆形 曲线安全模型。
要启动安全连接，客户端需要服务器永久连接 公钥。然后它生成一个临时密钥对并发送一个HELLO 命令到包含其短期公钥的服务器。该 HELLO命令对攻击者来说毫无价值;它没有识别出来 客户端。
服务器在获得HELLO时会生成自己的短期密钥 对（一个连接总共使用四个键），并编码这个新的 私有密钥在＆＃34; cookie＆＃34;，中，它将其发送回客户端作为 WELCOME命令。它还发送其加密的短期公钥 只有客户才能阅读。然后丢弃这个短期密钥 对
在此阶段，服务器尚未存储客户端的任何状态。它＆＃39; S 生成了一个密钥对，以某种方式将其发送回客户端 客户可以阅读并扔掉它。
客户端返回一个提供的INITIATE命令 服务器及其cookie返回，以及客户端永久公钥， 加密为＆＃34;保证＆＃34;所以只有服务器可以读取它。至于 客户端而言，服务器现在已经过身份验证，因此它也可以 在命令中发回元数据。
服务器读取INITIATE，现在可以验证客户端 永久公钥。它还解包了cookie并获得了它的简短 用于连接的术语密钥对。至于服务器现在 有关，客户端现在已经过身份验证，因此服务器可以发送它 元数据安全。然后双方都可以发送消息和命令。
这次握手提供了许多保护，但主要是完美的 转发安全性（您无法破解使用短期加密的数据 键即使你录制它，然后才能访问永久物 密钥）和客户身份保护（客户永久公开 密钥不以明文形式发送。）
我可以理解，它们基本上为每个通信会话生成一组新的密钥对，因此破解和获取一个会话的临时私钥或获取永久私钥仍将保护通过以下方式完成的记录过去的通信。一组不同的私钥。
我不能得到的是饼干部分。 Cookie准确用于什么目的？为什么服务器应该将cookie传递给客户端，只是为了让它再次恢复？看起来客户端无论如何都不会使用cookie。
答案 0 :(得分：0)
我也遇到了同样的问题。我在HELLO Command的the documentation部分找到了答案。
当服务器获得有效的HELLO命令时，它将生成一个新命令 临时密钥对，并对a中的公钥和密钥进行编码 WELCOME命令，如下所述。 服务器不应保留此信息 临时密钥对，应该为客户端保持最小状态，直到 客户端使用有效的INITIATE命令进行响应。 这可以保护 防止未经身份验证的客户端发送的拒绝服务攻击 许多HELLO命令消耗服务器资源。
答案 1 :(得分：0)
我猜zeromq使用TCP SYN cookie（可能是事务cookie不确定）。 这是为了保护服务器免受DDOS攻击。
当使用第一个序列号'n'（具有一些复杂的数学函数）发送TCP数据包时。接收器然后需要用'n + 1'序列来确认。发送者然后减去1并获得初始序列号（'n'）。
SYN cookie放在这个初始序列中，这样如果有DDOS泛滥，序列将被篡改，服务器无法检索cookie。然后它无法完成握手过程，从而终止连接。
在任何合法的握手中，cookie都不能被篡改。因此，Curve Server在发送给客户端以验证客户端的真实性后立即将其丢弃。
更多信息： https://en.wikipedia.org/wiki/SYN_cookies
此握手过程主要有两个目的：
两端验证
一个。第一个客户端获取使用客户端临时公钥加密的cookie和服务器临时密钥对。现在从客户端角度对服务器进行身份验证，因为它以客户端可以理解的加密方式发送数据。
湾第二，当客户端发回cookie（服务器临时密钥对），使用服务器长期公钥加密，服务器解密，验证cookie并获取客户端永久公钥。现在客户端已通过身份验证