liboqs
liboqs copied to clipboard
open-quantum-safe
Establish interop with Circl and other implementations
Circl implements several algorithms also provided by liboqs. An automated interop test set would be good to avoid issues like #909 in the future. Possibly an application for liboqs-go?
Although more testing is generally better, both liboqs and circl already do KAT tests. They also do development at different paces....
They also do development at different paces
And also seem to have different goals (integrations of more/different PQ algs into different apps, say). But 4 months difference (judging for example for Kyber from https://github.com/cloudflare/circl/commit/6168cdb13aecffecb3962ba88cfab16f29555b09) is a bit steep, indeed. Good we now have more upstream-pull automation.
--> Would anyone be in favour of setting a date for releasing liboqs 0.5? Would also be good to finally upgrade the pretty dated https://test.openquantumsafe.org to r3 (servers)...
I've yolo-opened a discussion on release schedules here https://github.com/open-quantum-safe/liboqs/discussions/912
I'm currently updating to the latest changes in some pq algorithms at CIRLC. It could be good to test between the two projects, and I can provide an status of them.
@claucece Thanks for that update and your interest to look into this issue. In case you didn't find them yet, here's pointers to some interop test scripts we already have distributed across the various projects and that may provide thoughts:
- openssl/boringssl interop CI test
- script driving curl docker image against nginx test server
- script driving openssl3 provider image against nginx test server
Upon glancing at them, the latter two are particularly badly "documented" (my fault), so please don't hesitate to ask questions if you'd want to build off this if you also want run tests against the server. If you'd want to do something that runs as part of CI, I'd recommend the first link.
Having looked into checking all KATs for each KEM (let alone signatures) I see two issues:
- Time (as suggested in the meeting):
python3 tests/test_kat.pywent from taking43.70 sto taking461.13 s - KAT hashes:
copy_from_upstreamcan update the KAT hashes, which are taken over just the first KAT value. Modifying this to update and cover all 100 KAT values will take some doing
One way to move forward would be to test interop on the one KAT set, and then run a few more tests on randomly sampled inputs
One way to move forward would be to test interop on the one KAT set, and then run a few more tests on randomly sampled inputs
Sounds like a good compromise.
@baentsch Can we close this due as having been satisfactorily resolved via https://github.com/open-quantum-safe/oqs-provider/pull/278?
OK for me if the only truly supported PQ feature CIRCL has is two specific TLS KEMs (which https://github.com/open-quantum-safe/oqs-provider/pull/278 ascertains interop of). My original impression was that it is much broader in scope, both in terms of algorithms as well as protocols supported.
OK for me if the only truly supported PQ feature CIRCL has is two specific TLS KEMs (which open-quantum-safe/oqs-provider#278 ascertains interop of). My original impression was that it is much broader in scope, both in terms of algorithms as well as protocols supported.
You're right, there's also Dilithium and FrodoKEM in Circle. Nevermind.