On Tue, 10 Feb 2026 08:24:10 GMT, Shawn M Emery <[email protected]> wrote:
> Thank you for the contribution @reverse-kong. Could you please add the > `security` label to this PR? In addition, could you describe the use case for > this mode of AES? Thanks for your reply. I have added the security label to this PR. Regarding the use case of AES/ECB mode: This optimization targets the existing AES/ECB implementation in the JDK, which is still widely used in several scenarios, including: - Legacy systems and protocols that rely on AES/ECB for backward compatibility. - Internal cryptographic primitives such as key wrapping, test vectors, and deterministic encryption where block independence is required. - Performance-sensitive workloads that process large amounts of fixed-size data blocks and currently suffer from high per-block intrinsic invocation overhead. Although ECB mode is not recommended for general-purpose encryption due to its security properties, it remains part of the JCA API and is actively used in practice. This PR does not change the cryptographic semantics or security model of AES/ECB; it only improves the performance of the existing implementation by enabling parallel processing of multiple blocks in a single intrinsic call. The goal is to reduce stub call overhead and improve instruction-level parallelism for workloads that already depend on AES/ECB, while keeping behavior fully compatible with the current implementation. I would be happy to further clarify the design or provide additional benchmarks if needed. Thank you again for your feedback. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29385#issuecomment-3876208921
