为什么更大的密钥数字并不等于更安全的 VPN

广告说 256 位，另一个产品说 128 位，结论似乎不言自明，直到你注意到这些数字描述的是不同的东西。对称加密的密钥、证书的公钥和密钥交换参数不在同一个尺度上衡量。它们之中没有一个涵盖客户端到底有没有验证服务器。这个数字是真实的信息，但它比周围的营销所暗示的要窄得多。

在比较任何东西之前，先问清楚数的是哪一把密钥，它保护的是什么。

三把密钥，三种职责

数据加密负责加密隧道的载荷，其密钥为每个会话重新派生。证书的公钥在认证时证明某个端点的身份。密钥交换步骤通常是一种临时的 Diffie-Hellman 变体，它建立一个之后双方都无法重建的共享秘密。每一种都有自己的强度假设和自己的长度惯例。

这就是为什么 256 和 2048、32 放在一起时无法按大小排序；它们回答的是不同的问题。

即使在单一职责之内，这个数字也只有相对于所用算法族才有意义。

数字有帮助的地方，以及它停下的地方

在一种算法内部，更大的密钥提高暴力搜索的代价，而公开的指南会随着算力的变化为证书密钥设定下限。那是一种正当而狭窄的比较：AES-128 和 AES-256 都以很大的余量抵御直接攻击，所以这个差别在实践中很少成为决定性因素。

超出那种比较之外，这个数字对配置错误、证书校验或协议版本都毫无预测力。

读懂整套协商结果

一条连接实际使用的是一套组合：加密模式、完整性或认证加密的构造、密钥交换组以及认证方式。即使标称的密钥长度相同，搭配正确握手的现代 AEAD 模式，与搭配独立 MAC 的旧模式也是完全不同的提议。

openvpn --show-ciphers | head -20
openvpn --show-tls | head -20
openssl x509 -in server.crt -noout -text | grep -E 'Public-Key|Signature Algorithm'
wg show

要读协商出来的结果，而不是配置的上限。提供强套件的客户端，如果服务器选择了较弱的选项而配置文件又允许，依然会以弱方式连接。如果关心性能，就在具体的设备与路径上测量，因为一旦涉及硬件加速和包大小，密钥长度就不是吞吐量的好预测指标。

数字永远测不到的部分

软件维护是第一处缺口。建立在不再接收修复的库之上的隧道，比它的密钥长度所暗示的要弱，而任何配置值都修不好这一点。运营方的行为是第二处：连接记录、账户数据和支持流程完全在密码学之外。一个保留超出你预期的数据的服务，不会因为密钥更长而更安全。

对端验证是第三处，也是后果最重的一处。接受任何证书的客户端，只是在未经认证的对端外面包了一层强加密，这比正确校验下的普通加密更糟。先检查这三件事，数字才会回到它应有的位置。