JEP 246：利用 GHASH 和 RSA 的 CPU 指令

概括

利用最近推出的 SPARC 和 Intel x64 CPU 指令提高 GHASH 和 RSA 加密操作的性能。

成功指标

JDK 8 中包含的对 AES-CBC 的支持（请参阅JEP 164）显示出比纯基于软件的实现提高了 8 倍。不同的算法会有所不同，但我们应该会看到类似的显着性能提升。

动机

我们使用本机库（例如 PKCS#11）越少，与复杂的本机 API 交互所引起的复杂代码和内存问题就越少。对本机库的 JNI 调用越少，加密速度就越快。通过直接在 JVM 中实现加密操作，我们可以通过内置提供程序控制其实现和管理，从而提供开箱即用的支持。

描述

现有的 API 不会被修改或扩展。

算法

当 HotSpot 支持 AES 指令时，现有实现会调用这些指令。除了 CBC 模式之外，还有一些优化可以帮助 AES 和 CBC 快速协同工作。这些指令和优化取代了当前的 SunJCE 字节码方法。该计划是对 GCM 和 RSA 实施类似的优化，这可以极大地受益于硬件的帮助。 AES-GCM 和 RSA 都是 TLS 密码套件的一部分。

GHASH 是 GCM 的一部分，将pclmulqdq在 Intel x64 和xmul/ xmulhiSPARC 上使用进行加速。

RSA 将通过使用位操作指令集 2 来加速。其他非对称算法很可能会从这些变化中受益，但它们将由 RSA 来衡量。鉴于“montmul”和“montsqr”指令的复杂性和局限性，未添加 SPARC 指令。使用本机库可提供完整的 RSA 功能，且没有任何缺点。此外，由于 RSA 是一种缓慢的操作，因此 JNI 和本机 API 层在整体性能图中的成本很可能很低。

供应商

算法的管理是一个重要问题，随着时间的推移变得越来越复杂。一个极端的情况是 Solaris 的默认提供程序配置。 SunPKCS11 提供程序在提供程序列表中领先于 SunJCE。 SunPKCS11 提供程序支持 Solaris 的所有硬件加速和优化算法。要使用 JDK 8 AES-CBC 支持，必须将 SunJCE 移至 SunPKCS11 之前。对于只需要 AES-CBC 的应用程序（例如性能测试），不需要其他算法，因此这是可行的。然而，对于使用多种算法的应用程序，其他算法将使用基于未加速的软件实现而不是 SunPKCS11 的硬件加速实现来运行。当使用 NSS（通过 SunPKCS11 提供程序配置）时，其他操作系统也可能会出现此问题。

因此，新的安全属性已添加到文件中java.security，jdk.security.provider.preferred以允许在检查有序提供程序列表之前将某些算法和算法组定向到特定提供程序。此属性适用于高级用户，默认情况下不设置。当前使用许多不同版本的 x86 和 SPARC CPU，设置默认值可能会导致旧系统的性能下降，并且需要持续维护，因为新 CPU 提供了更多支持。此外，现有的 JDK 配置（例如 FIPS 140 或其他专用提供商）可能会在不知不觉中定向到不同的提供商。因此，最好jdk.security.provider.preferred默认情况下取消设置该属性，但让供应商和高级用户将该属性设置为其 CPU 支持的属性。

测试

现有的已知答案测试 (KAT) 应足以进行功能测试。将使用现有基准和内部测试进行大量性能测试。