Erlang/OTP 加密功能改进：分离 Ed25519 和 Ed448 曲线支持

在密码学领域，Ed25519 和 Ed448 是两种基于椭圆曲线的数字签名算法，而 X25519 和 X448 则是基于相同曲线的密钥交换算法。这些算法在现代加密通信中扮演着重要角色，特别是在 TLS 1.3 协议中。

Erlang/OTP 作为一个成熟的分布式系统平台，其加密功能需要与各种加密库保持兼容。在最新版本中，开发团队对加密功能的实现进行了重要改进，解决了之前存在的一个兼容性问题。

问题背景

原先 Erlang/OTP 的加密模块将 Ed25519/X25519 和 Ed448/X448 的支持绑定在一起，通过统一的 HAVE_EDDH 和 HAVE_EDDSA 宏来控制。这种设计在 OpenSSL 环境下工作良好，因为 OpenSSL 同时支持这两种曲线。然而，对于 LibreSSL 这样的加密库，情况有所不同——LibreSSL 只支持 Ed25519/X25519 而不支持 Ed448/X448。

这种设计导致了一个实际问题：当使用 LibreSSL 构建 Erlang/OTP 时，系统会默认禁用 TLS 1.3 支持，因为 TLS 1.3 依赖于 HAVE_EDDH/HAVE_EDDSA 宏定义。对于 OpenBSD 用户来说，他们不得不维护一套补丁来绕过这个限制。

解决方案

开发团队通过代码重构解决了这个问题，主要改进包括：

1. 将 HAVE_EDDH 和 HAVE_EDDSA 宏拆分为更细粒度的控制选项
2. 引入独立的 HAVE_ED25519 和 HAVE_ED448 宏定义
3. 使系统能够单独检测和启用不同曲线的支持

这种改进带来了几个显著优势：

• 提高了与不同加密库的兼容性，特别是对 LibreSSL 的支持更加完善
• 允许系统在只支持部分曲线的情况下仍然启用相关功能
• 为未来的加密算法扩展提供了更灵活的框架

技术影响

这项改进对 Erlang/OTP 用户和开发者都有重要意义：

1. TLS 1.3 支持：使用 LibreSSL 构建的系统现在可以默认启用 TLS 1.3 支持
2. 系统安全性：确保即使在不支持所有曲线的情况下，也能充分利用可用的加密算法
3. 跨平台兼容性：减少了特定平台（如 OpenBSD）需要维护补丁的需求
4. 未来扩展性：为将来可能引入的新加密算法提供了更好的支持框架

这项改进体现了 Erlang/OTP 团队对系统兼容性和安全性的持续关注，也展示了开源项目如何通过社区反馈不断优化和完善自身功能。