- Welcome
- Minutes/actions from previous meeting
- Updates from related communities:
- Review status of sub projects:
- API requirements - random source, rust vs C, unpacked keys
- open TSC issues:
- Any other business
Nothing to note.
- Continuing review of Project Lifecycle document.
- Sub-projects expected to be clear on their production quality.
- Added Mayo signature scheme (including @bhess + @mkannwischer).
- PR in review for libjade Kyber implementation (help from @tfaoliveira) - preview/test run of what we will do with pqcp in future.
- 0.11 expected in August.
- trail of bits audit underway - started Monday, will last 4 weeks. @ajbozarth leading initiative to revive oqs-demos - feedback invited on priority of each demo.
- Adding RISC-V support - harder than expected due to toolchain support (nix)
- In process of adding fast keccak - needs more work on an infrastructure project
- Minor release/update to provide updated license to liboqs. (changes to CI, infra updates, compiler/easycrypt). Next major release will have a restructure to split into multiple repositories. Currently prototyping. Will update to SHA3 to move to mlkem. Doesn't block current integration but sets future direction.
- De-randomized api makes testing easier, discussion about private keys & what part part may explicitly be public - to help with constant time checking. Using timecop. Should document info about key.
- @franziskuskiefer has first PR. Need to fix up licenses. Then will open up more issues.
A lot of discussion around the API
- #86
- Many libraries such as nss have their own random number generators.
- NIST require both.
- wonder underway in liboqs to add derandomized api.
- probably should have a random function - may be harder to integrate without.
- Q about whether this affects certification - lib wouldn't be certified, rather a full module like openssl, so another team would take our library, bundle it with a random number generator, and that would be tested together.
- liboqs provides random function, delegates to reasonable dependency library/platform (windows, mac, openssl etc)
- Any real implementation needs drpg for certification in any case
- continue discussion towards decision in issue
- Deserialized API
- Many implementations offer this (Microsoft, BoringSSL)
- Avoids need to constantly serializing/deserializing when you already have the key.
- Structured api (vs. byte)- relates also to doc above on keys and what is secret.
- Should have both serialised and deserialized apis.
Andrés asked if there's any help needed with open reach, such as getting input from community.
None.
No updates.
- Recordings are available on your Open Profile page under Past Meetings.
The next meeting is canceled (multiple vacation), we will continue in in 4 weeks time - 1300 UTC on 2024-08-15.
- Manuel Barbosa, University of Porto
- Hanno Becker, AWS
- Nigel Jones, IBM
- Matthias J. Kannwischer, Chelpis Quantum Tech
- Franziskus Kiefer, Cryspen
- Tiago Oliveira, Sandbox AQ
- John Schanck, Mozilla
- Douglas Stebila, University of Waterloo
- Alex Bozarth, IBM
- Andrés Vega, Fianu Labs