end of live openssl 1.1 vs slow openssl 3.0

【英文原文】
你可能已经注意到，openssl 1.1.1 系列将于下周一（2024 年 5 月 27 日）达到寿命终止（eol）……
最明智的选择是尽快切换到 3.0 或 3.1 版本。

当然，我们的 mormot 2 openssl 单元在 1.1 和 3.x 分支上运行，并在运行时自适应每个分支之间存在的各种 api 不兼容性。
但我们也发现，切换到 openssl 3.0 可能会导致性能大幅下降……那么你需要使用哪个版本呢？
openssl 1.1 将寿命终止

众所周知，广泛使用的 openssl 1.1.1 系列将于 2023 年 9 月 11 日（下周一）达到寿命终止（eol）。：（
openssl 1.1.1 的用户应该考虑他们的选择，并计划他们可能需要采取的任何行动。

请注意，indy 用户仍然停留在 openssl 1.0 分支，甚至 1.1 还没有正式支持。一些替代的 io 处理程序能够在一定程度上使用最新版本。
indy 用户应该转而使用支持更好的库，比如我们的小 mormot。

还要注意的是，1.1 和 3.x 之间存在一些 api 不兼容性。函数被重命名，甚至被删除；出现了新的上下文构造函数；一些参数类型甚至发生了变化！
我们的单元试图在运行时解决所有这些问题，并针对 openssl 库的多个版本进行了测试，以确保您不必担心这些低级问题。

openssl 3.x 的好处

随着 openssl 3.0 的发布，开发人员对库的内部进行了大规模的重构。
公平地说，openssl 的 1.x 源代码有点混乱，难以维护。最大的 it 公司甚至创建了自己的分支或切换到其他库。最著名的是 boringssl，由 google 维护，并在 chrome 和 android 等中使用。
因此，进行重构是时候了，特别是对于像 openssl 这样对许多项目至关重要的库。

在新的 3.x 分支中，许多低级 api 函数已被弃用。
实际上，您不再直接访问库的内部结构，现在应该始终使用高级 api 来访问上下文属性或执行处理方法。例如，低级的 aes_encrypt 函数不再可用：从现在开始，您需要使用高级的 evp_encrypt* api。
官方的迁移指南页面显然非常庞大，如果您想为未来几年使用 openssl 做好准备，值得一读。

openssl 3.0 性能回归

3.0 分支的新代码可能看起来更漂亮，更易于维护，但它也有缺点。新的并不总是更好的。
这个新版本的大多数用户在从 1.x 切换到 3.0 时观察到了巨大的性能回归。它影响了许多项目，来自各种语言，甚至是在性能方面本来就不突出的脚本语言。据报道，时间回归从 3 倍到 10 倍不等。在我们这边，x509 证书操作确实比以前慢得多——最糟糕的是关于 x509 存储。

一些减速是预期的并记录在案（例如 rsa 密钥生成，现在使用 64 轮）。但回归要严重得多。
罪魁祸首似乎不是核心加密代码，如 aes 缓冲区编码（asm 声称在 3.x 分支上进一步优化），而是 openssl 上下文结构本身。它们是为了未来的可维护性而重写的，但没有关注它们的实际性能。

openssl 3.1 的数字

3.1 分支声称已经解决了这些问题中的大部分。

可以肯定的是，我们使用多个版本的 openssl 运行 mormot 加密回归测试。实际上，openssl 3.1 比 openssl 3.0 快得多，但仍落后于 openssl 1.1。

以下是在 win32 上执行整个 ttestcorecrypto 方法时观察到的数字：

openssl 1.1 = 15 秒
openssl 3.0 = 33 秒
openssl 3.1 = 18 秒

有几个方面需要强调：

这些测试还运行了 mormot 引擎加密，因此您不仅仅是在测试 openssl：在上述数字中，“纯 mormot”测试大约需要 4.5 秒；

任何严肃的项目都应该考虑在 win64 上编译，并在 x86_64 linux 上运行服务器 - 在这个平台上，回归确实存在，但只是稍微好一点；

与 ttestcorecrypto.catalog（即证书处理）相比，ttestcorecrypto.benchmark（即原始缓冲区加密）受到的减速影响较小；

我们的测试是单线程的，并且在重度线程化的进程中报告了更严重的减速（高达 x10）。

在 mormot openssl 包装器中，我们尝试尽可能多地缓存上下文。例如，我们不会为每个调用按名称查找 openssl 算法，而是在运行时缓存它以避免任何减速。

但对于 openssl 3.0 来说，这似乎还不够，这可能会影响您的应用程序性能。

支持还是不支持

因此，openssl 3.1 似乎是前进的方向。

在 linux（或其他 posix 系统）上，您可能会使用系统附带的库。

因此，您不必担心使用哪个版本。而且，可悲的是，您的发行版很可能提供 openssl 3.0 而不是 openssl 3.1。

在 windows（或 mac）上，您可以（应该？）使用您“自己的”dll/so 文件，因此您必须考虑库的支持级别。

openssl 3.0 是一个长期支持（lts）版本，将维护到 2026 年 9 月 7 日。

openssl 3.1 将仅支持到 2025 年 3 月 14 日。

这些支持结束日期可能看起来违反直觉，但这是开源项目中的常见方式，最著名的可能是 ubuntu lts 版本。

有关 openssl 支持生命周期的更多信息，请查看官方 openssl 下载页面。

因此，对于大多数项目，特别是在 windows 上，您可能会发布带有自己可执行文件的 openssl dll，切换到 openssl 3.1 可能是前进的方向。

如果您需要为您的产品收集一些安全认证，您可以考虑使用 openssl 3.0 lts 版本，这可能有助于您的认证在更长时间内保持有效。

一如既往，欢迎在我们的论坛上提供任何反馈！