FIPS self-test refactoring
OpenSSL 3.5 brings post-quantum algorithms in FIPS provider.
Unfortunately, it means significant slow-down of FIPS startup (especially because of SLH-DSA variants).
The way forward we see is refactoring of FIPS POST so the algorithms would be tested on demand (on fetch). I would like to get feedback from the distro and large business communities and put it to the TAC agenda
Simo Sorce Wed 30 Jul 2025 5:31PM
Yes, only the first time the algorithm needs to be actually used
Paul Dale Wed 30 Jul 2025 9:45PM
This is a good suggestion. The thing that needs to be quantified is how much this will slow everything down because of the "has been self tested check" on every fetch/init.
Building without SLH-DSA remains an option for those who don't require the algorithm.
Paul Dale Wed 30 Jul 2025 11:21PM
Some care would also be required to avoid increasing the number of POSTs yet retaining flexibility to change the specific tests performed.
FIPS 140-3 is fairly generous in allowing specific tests to be subsumed into others (e.g. testing AES-GCM is sufficient to sign off all AES based ciphers). Often the different algorithms follow different code paths and once NIST realises this, more tests are likely to be mandated & we'd need to retain the ability to switch and change tests as required. By instrumenting all the myriad AES cipher flavours, we'd lose flexibility in adapting to changes.
Paul Dale Thu 31 Jul 2025 1:55AM
Another thought: could we introduce the test on demand just for SLH-DSA. Given how glacial the algorithm is, the overhead should be negligible.
Dmitry Belyavsky Thu 31 Jul 2025 11:15AM
It's also an option but I'd prefer to have some universal mechanism if possible
Benjamin Thu 31 Jul 2025 5:31PM
If we go that way, can there be an explicit option to "pre-warm" the self-tests in order to avoid surprising performance behavior during runtime?
Jeff Johnson · Wed 30 Jul 2025 4:33PM
On fetch first time only??