Noise 协议框架

Noise 协议框架（Trevor Perrin，2016 年；当前修订版为 2018 年）是一个使用少量密码学基元和模式语言来构建安全信道协议的框架。Noise 不规定单一协议，而是定义了一套握手模式词汇，用于描述 DH 操作及其顺序。任何有效的 Noise 模式都可以使用具体的 DH（Curve25519 或 Curve448）、加密算法（AESGCM 或 ChaChaPoly）以及哈希函数（SHA-256、SHA-512、BLAKE2）进行实例化。Noise 被用于 WireGuard、WhatsApp、Signal（作为 X3DH 的基础）、Lightning Network 和 I2P。

每次 Noise 握手都有一个发起方（I）和一个响应方（R）。每一方都可能拥有两种类型的密钥：静态密钥（长期身份密钥，记作 s/S）和临时密钥（每个会话新生成，记作 e/E）。小写字母表示本方的密钥；大写字母表示远端一方的公钥。Noise 模式规定发送哪些密钥（以明文或加密形式发送）以及执行哪些 DH 操作。例如，“e”表示“发送我的临时公钥”；“es”表示“执行 DH(my_ephemeral, remote_static)”。每个 DH 输出都会混入握手持续更新的哈希状态。

Noise 的核心是 SymmetricState，它维护三个值：ck（链式密钥，初始化为协议名称的哈希值）、h（握手哈希，即持续更新的交换记录哈希）以及 k（当前加密密钥）。MixKey(input) 运行 HKDF(ck, input)，以更新 ck 和 k。MixHash(data) 将 data 的哈希值混入 h。EncryptAndHash(plaintext) 使用 k 加密明文，并将密文混入 h。DecryptAndHash(ciphertext) 解密密文，并将密文混入 h。握手哈希 h 提供交换记录绑定——对手对任何消息进行的任何修改都会改变 h，从而导致解密失败。握手结束时，Split() 会生成两个独立的 CipherStates，分别用于发送和接收。

Noise_XX 是最常用的双向认证模式。它提供双向静态密钥认证，双方的静态密钥都会在握手期间传输。模式为：(1) -> e（发起方发送临时公钥）。(2) <- e, ee, s, es（响应方发送临时公钥，执行 DH(e,e) 和 DH(e,s_resp)，并发送加密的静态密钥）。(3) -> s, se（发起方发送加密的静态密钥，并执行 DH(s_init, e_resp)）。第 3 步之后，双方都已将三个 DH 输出混入会话密钥：ee（前向保密）、es（服务器认证）、se（客户端认证）。会话结束后，即使长期密钥遭到泄露，会话密钥仍与这些长期密钥无关。

WireGuard 使用源自 Noise_IK 的模式，其中发起方预先知道响应方的静态密钥。(1) -> e, es, s, ss（发起方发送临时密钥，执行 DH(e, S_resp)，发送加密的静态密钥，并执行 DH(s_init, S_resp)）。(2) <- e, ee, se（响应方发送临时密钥，执行 DH(e_resp, e_init) 和 DH(e_resp, S_init)）。IK 模式为发起方提供身份隐藏功能（发起方的静态密钥在第 1 步中使用响应方的静态密钥加密），并可在一个 RTT 内完成。WireGuard 在加密的发起方载荷中加入时间戳，以防止重放。这使 WireGuard 具有简洁的特点：通过两个 UDP 数据包即可完成 VPN 握手。

Noise 握手结束时的握手哈希 h 是覆盖所发送每条消息的交换记录哈希。它充当信道绑定值——双方会计算出相同的 h，任何希望绑定到 Noise 会话的第三方协议都可以将 h 作为随机数或信道 ID 包含其中。这支持组合认证：类似 TLS 的证书认证步骤可以在 Noise 握手之后运行，并通过 h 将证书绑定到这一特定会话。信道绑定可以防止凭据转发攻击，在这类攻击中，一个会话的认证凭据会被重放到另一个会话中。Split() 会将 h 与会话密钥一起提供给应用程序。

Noise 支持延迟模式，用于发起方事先不知道响应方静态密钥的情况。Noise_NX（发起方没有静态密钥；响应方发送自己的静态密钥）类似于单向 TLS。Noise_XX 处理双方都需要交换密钥的情况。如果发起方猜测的响应方静态密钥不正确（例如密钥轮换之后），Noise_IK 可以回退到 Noise_XXfallback。回退模式允许响应方发出“您使用了错误的密钥；这是我的新公钥”的信号，同时不会让外部观察者发现发生了回退，从而保持协议的隐蔽性。

WhatsApp 和 Signal 使用 Noise_XX 在客户端与服务器之间建立安全信道。WhatsApp 的二进制协议使用 Curve25519、ChaChaPoly 和 SHA-256 的 Noise_XX。客户端的静态密钥就是其长期身份密钥。Noise 握手之后，应用层会执行额外的认证（Signal 注册、电话号码验证）。Signal 的 X3DH（扩展三重 Diffie-Hellman）密钥协商通过异步消息交换执行四次 DH 操作，在两个用户之间建立共享密钥——这不是标准的 Noise 模式，但使用了类似的 DH 混合概念。随后由 Double Ratchet 接管持续的消息加密。

Noise 和 TLS 1.3 以不同理念解决同一个问题（经认证的密钥交换）。TLS 1.3 是一个单一协议，规定了密码套件、证书格式（X.509）和扩展。它面向 Web 浏览器和服务器设计，是一种适用于大多数场景的通用协议。Noise 是一个框架：它不规定证书格式、PKI 或传输绑定。因此 Noise 更小（WireGuard 的完整 Noise 实现不到 400 行代码），也更容易进行形式化分析，但要求应用程序单独处理身份管理。在 PKI 过于复杂的封闭系统（应用到服务器、VPN）中，通常更偏好 Noise；而在需要证书互操作性的开放系统（Web）中，则使用 TLS。

Noise 模式已在 eCK（扩展 Canetti-Krawczyk）安全模型中经过形式化分析。Kobeissi、Bhargavan 和 Blanchet 使用 Proverif 分析了 Noise，并为全部 12 种基础 Noise 模式证明了认证性和密钥保密性。证明假设标准的 DH 困难性假设（Curve25519），以及底层 AEAD 和哈希函数的安全性。Noise 的组合性质（每个 DH 都会逐步混入）使其比包含许多状态转换的复杂 TLS 类协议更容易分析。在部署之前，对 Noise 进行密码学验证让 WireGuard 和 WhatsApp 对其协议安全性有了很高的信心。

Noise 实现中常见的陷阱包括：(1) 模式混淆——如果响应方的静态密钥没有可靠地预先分发，使用 Noise_IK 会导致身份不匹配（发起方可能会在不知情的情况下将数据加密给错误的密钥）。(2) 重放保护——Noise 提供认证，但不提供对传输阶段消息的重放保护；必须强制使用随机数（64 位计数器），并且计数器回绕（发送 2^64 条消息之后）必须触发重新换钥。(3) Prologue 完整性——Noise prologue（在握手开始前混入 h 的字节串）必须包含所有协议上下文（版本、算法选择），以防止降级攻击。(4) PSK 误用——Noise 支持用于混合预共享密钥的 PSK 扩展；PSK 必须具有高熵，不能使用用户密码。

在握手模式中，符号“es”表示什么？

Noise 是一个使用 DH 操作模式语言构建经认证密钥交换协议的框架。SymmetricState 维护链式密钥（ck）、交换记录哈希（h）和加密密钥（k），并通过 MixKey/MixHash 更新。Noise_XX 在 1.5 个 RTT 内提供双向认证；Noise_IK（WireGuard）在已知响应方密钥的情况下可在 1 个 RTT 内完成。握手哈希 h 充当信道绑定值。所有核心模式都已通过 Proverif 进行形式化验证。在不需要 PKI 的封闭系统协议（WireGuard、WhatsApp）中，Noise 比 TLS 更受偏好。正确实现 Noise 需要重放保护、Prologue 完整性和高熵 PSK。