Proposal: Remove bundled libaes_siv, use OpenSSL native AES-SIV
mark.atwood at ntpsec.org
mark.atwood at ntpsec.org
Sun Jun 28 02:31:36 UTC 2026
Hal,
Thanks for the detailed response. Let me address both points.
On FIPS:
I have a consulting client doing FIPS certification work, so I can speak to this directly. The bundled libaes_siv is a pain point for certification. It's a separate cryptographic implementation that has to be evaluated independently, even though it just wraps OpenSSL primitives underneath. Auditors see "custom crypto library" and the paperwork multiplies.
Routing through OpenSSL's EVP interface is simpler than trivial for FIPS. AES-SIV uses FIPS-approved primitives (AES, CMAC), and when you call it through EVP on a FIPS-enabled OpenSSL build, it just works. No separate evaluation needed. The provider architecture handles it.
Your memory that libaes_siv "works with FIPS" is backwards. The deprecated CMAC_CTX APIs bypass the provider layer entirely, which means they bypass FIPS enforcement. That's a compliance problem, not a feature.
On performance:
The EVP dispatch overhead is a few function pointer indirections per operation. Nanoseconds. NTS cookie operations happen once per key exchange, not per packet. The actual NTP packet processing doesn't touch AES-SIV at all. Even on a server handling thousands of NTS-KE sessions per second, the difference would be unmeasurable noise.
Happy to run benchmarks if you want numbers, but I'm confident we're optimizing something that doesn't matter.
I'm going to move forward with this change. If something unexpected shows up in testing, we can revisit, but I don't think a configure-time switch for the old code is warranted. Maintaining two code paths for deprecated APIs with no practical benefit isn't worth it.
Mark
More information about the devel
mailing list