OpenSSL 中的 SHA1 摘要名称：一份旧清单意味着什么

旧摘要清单读起来像密码学决策的转录，其实并不是。像 SHA1、DSA-SHA1-old 或 RSA-SHA1-2 这样的名称在旧版 OpenSSL 构建中并排出现，是因为该库围绕相关哈希机制注册了多个入口点。清单里的 RSA 或 DSA 标签 OpenVPN 并不能说明它对数据包做了什么。你读到的是库的清单，不是某次会话的记录。

在下任何结论之前，必须把三件事分开：注册名、它下面的摘要计算，以及消费它的操作。

注册是接口，不是强度评级

在 OpenSSL 1.0.2 中，摘要注册表把名称、别名和实现串在同一个文件里。旧的 DSS1 描述符是最清楚的例子：它报告 SHA-1 的输出长度并调用 SHA-1 的收尾例程，却带着一个暗示完全不同算法的名字。因此，注册项里多出的字母并不表示不同的哈希、更长的输出或新的安全级别。

同一份源码为更早的调用者保留了别名关系，这解释了清单为何显得拥挤。这是兼容性文档，而不是承诺当前的 OpenSSL 提供者会暴露完全相同的名称。

签名用的名称并不产生签名

签名框架可以把摘要绑定到另一个算法的接口上，使现有调用者继续编译通过。真正的公钥签名既需要密钥，也需要使用该密钥的签名步骤，而菜单里的名称两者都不提供。带 RSA 色彩的一条摘要记录只是调用者可以使用的名称，并不是每个 VPN 数据包都携带 RSA 签名的证据。

正是这一步让较早的文章滑向民间传说。如果你需要知道数据包是如何被认证的，请找到选择该机制的选项，并阅读它在你实际运行的版本中做了什么。与该版本一同发布的手册页才是唯一与眼前程序相符的描述。存档的指南描述的是它们写作时所针对的版本，可能落后好几套命名惯例。

找到消费该名称的选项

在 OpenVPN 2.6 记录的包认证情形中，auth 选择一个由 HMAC 使用的摘要，这是带密钥的消息认证构造，而不是证书签名。TLS 证书的签名算法是握手的另一个属性。

使用 AEAD 数据加密时，单独的 auth 设置不再适用于数据通道，而它对 tls-auth 的作用仍是另一个问题。因此摘要清单无法告诉你当前数据包由哪个哈希保护、协商了哪套 TLS，也无法告诉你对端证书如何签名。只有生效的配置加上版本才能回答，而且只适用于眼前的连接。

记录你实际拥有的东西

写下 OpenVPN 版本、链接的加密库、配置中的确切选项，以及一次真实连接的结果。这一组信息能回答摘要菜单截图无法回答的问题，而且它点明的是版本而非印象，所以能经受下一次升级。

最重要的是，不要因为旧别名的名字听起来更强或更具体就选择它。为整条连接选择受支持的策略，并把旧名称当作库过去如何自我呈现的记录。