CurveZMQ 安全性如何运作？
How does CurveZMQ security work?
Clients and servers have long-term permanent keys, and for each
connection, they create and securely exchange short-term transient
keys. Each key is a public/secret keypair, following the elliptic
curve security model.
To start a secure connection the client needs the server permanent
public key. It then generates a transient key pair and sends a HELLO
command to the server that contains its short term public key. The
HELLO command is worthless to an attacker; it doesn't identify the
client.
The server, when it gets a HELLO, generates its own short term key
pair (one connection uses four keys in total), and encodes this new
private key in a "cookie", which it sends back to the client as a
WELCOME command. It also sends its short term public key, encrypted so
only the client can read it. It then discards this short term key
pair.
At this stage, the server hasn't stored any state for the client. It's
generated a keypair, sent that back to the client in a way only the
client can read, and thrown it away.
The client comes back with an INITIATE command that provides the
server with its cookie back, and the client permanent public key,
encrypted as a "vouch" so only the server can read it. As far as the
client is concerned, the server is now authenticated, so it can also
send back metadata in the command.
The server reads the INITIATE and can now authenticate the client
permanent public key. It also unpacks the cookie and gets its short
term key pair for the connection. As far as the server is now
concerned, the client is now authenticated, so the server can send its
metadata safely. Both sides can then send messages and commands.
This handshake provides a number of protections but mainly, perfect
forward security (you cannot crack data encrypted using the short term
keys even if you record it, and then later get access to the permanent
keys) and protection of client identity (the client permanent public
key is not sent in clear-text).
我可以理解他们基本上是为每个通信会话生成一组新的密钥对，因此破解和获取一个会话的临时私钥，或获取永久私钥，仍然会保护记录的过去通信通过一组不同的私钥完成。
我没有得到的是 cookie 部分。 cookie 的确切用途是什么？为什么服务器要将 cookie 传递给客户端，然后再取回来？无论如何，客户端似乎都没有使用 cookie。
我遇到了同样的问题。我在 HELLO Command section of the documentation.
中找到了答案
When the server gets a valid HELLO command, it SHALL generate a new
transient key pair, and encode both the public and secret key in a
WELCOME command, as explained below. The server SHALL not keep this
transient key pair and SHOULD keep minimal state for the client until
the client responds with a valid INITIATE command. This protects
against denial-of-service attacks where unauthenticated clients send
many HELLO commands to consume server resources.
我猜 zeromq 使用 TCP SYN cookies（不确定可能是交易 cookies）。
这是为了保护服务器免受DDOS攻击。
当 TCP 数据包以第一个序列号 'n' 发送时（带有一些复杂的数学函数）。然后接收方需要使用 'n+1' 序列确认这一点。发件人然后减去 1 并得到初始序列号 ('n').
SYN cookies 放置在这个初始序列中，这样如果有 DDOS 泛滥，序列将被篡改并且服务器无法检索 cookie。则无法完成握手过程，从而终止连接。
在任何合法的握手中，cookie 都不能被篡改。因此 Curve Server 在发送给客户端后立即丢弃它以验证客户端的真实性。
更多信息：
https://en.wikipedia.org/wiki/SYN_cookies
这次握手过程主要有两个目的：
- 在客户端通过身份验证之前，不要存储与客户端（或其状态）相关的任何内容。因此短期密钥对被丢弃（记住，每个与客户端的连接都有一个单独的密钥对 - 瞬态）
两端认证
一个。第一个客户端获取使用客户端瞬态 public 密钥加密的 cookie 和服务器瞬态密钥对。现在从客户端的角度来看，服务器已通过身份验证，因为它以客户端可理解的加密方式发送数据。
b。其次，当客户端发回 cookie（服务器临时密钥对）时，使用服务器长期 public 密钥加密，服务器解密，验证 cookie 并使客户端永久 public key.Now 客户端已通过身份验证
Clients and servers have long-term permanent keys, and for each connection, they create and securely exchange short-term transient keys. Each key is a public/secret keypair, following the elliptic curve security model.
To start a secure connection the client needs the server permanent public key. It then generates a transient key pair and sends a HELLO command to the server that contains its short term public key. The HELLO command is worthless to an attacker; it doesn't identify the client.
The server, when it gets a HELLO, generates its own short term key pair (one connection uses four keys in total), and encodes this new private key in a "cookie", which it sends back to the client as a WELCOME command. It also sends its short term public key, encrypted so only the client can read it. It then discards this short term key pair.
At this stage, the server hasn't stored any state for the client. It's generated a keypair, sent that back to the client in a way only the client can read, and thrown it away.
The client comes back with an INITIATE command that provides the server with its cookie back, and the client permanent public key, encrypted as a "vouch" so only the server can read it. As far as the client is concerned, the server is now authenticated, so it can also send back metadata in the command.
The server reads the INITIATE and can now authenticate the client permanent public key. It also unpacks the cookie and gets its short term key pair for the connection. As far as the server is now concerned, the client is now authenticated, so the server can send its metadata safely. Both sides can then send messages and commands.
This handshake provides a number of protections but mainly, perfect forward security (you cannot crack data encrypted using the short term keys even if you record it, and then later get access to the permanent keys) and protection of client identity (the client permanent public key is not sent in clear-text).
我可以理解他们基本上是为每个通信会话生成一组新的密钥对，因此破解和获取一个会话的临时私钥，或获取永久私钥，仍然会保护记录的过去通信通过一组不同的私钥完成。
我没有得到的是 cookie 部分。 cookie 的确切用途是什么？为什么服务器要将 cookie 传递给客户端，然后再取回来？无论如何，客户端似乎都没有使用 cookie。
我遇到了同样的问题。我在 HELLO Command section of the documentation.
中找到了答案When the server gets a valid HELLO command, it SHALL generate a new transient key pair, and encode both the public and secret key in a WELCOME command, as explained below. The server SHALL not keep this transient key pair and SHOULD keep minimal state for the client until the client responds with a valid INITIATE command. This protects against denial-of-service attacks where unauthenticated clients send many HELLO commands to consume server resources.
我猜 zeromq 使用 TCP SYN cookies（不确定可能是交易 cookies）。 这是为了保护服务器免受DDOS攻击。
当 TCP 数据包以第一个序列号 'n' 发送时（带有一些复杂的数学函数）。然后接收方需要使用 'n+1' 序列确认这一点。发件人然后减去 1 并得到初始序列号 ('n').
SYN cookies 放置在这个初始序列中，这样如果有 DDOS 泛滥，序列将被篡改并且服务器无法检索 cookie。则无法完成握手过程，从而终止连接。
在任何合法的握手中，cookie 都不能被篡改。因此 Curve Server 在发送给客户端后立即丢弃它以验证客户端的真实性。
更多信息： https://en.wikipedia.org/wiki/SYN_cookies
这次握手过程主要有两个目的：
- 在客户端通过身份验证之前，不要存储与客户端（或其状态）相关的任何内容。因此短期密钥对被丢弃（记住，每个与客户端的连接都有一个单独的密钥对 - 瞬态）
两端认证
一个。第一个客户端获取使用客户端瞬态 public 密钥加密的 cookie 和服务器瞬态密钥对。现在从客户端的角度来看，服务器已通过身份验证，因为它以客户端可理解的加密方式发送数据。
b。其次，当客户端发回 cookie（服务器临时密钥对）时，使用服务器长期 public 密钥加密，服务器解密，验证 cookie 并使客户端永久 public key.Now 客户端已通过身份验证