Goals for next milestones

[dstebila]

This thread is for discussing what goals we want to work towards in our next release of liboqs as well as other OQS subprojects.

liboqs

• Algorithm improvements and additions:
  • Endianness issues with BIKE #1101: Endianness issues with BIKE
  • Add stateful hash-based signatures #1098: Add stateful hash-based signatures
  • SPHINCS+ memcpy source and destination overlap - undefined behavior #1038: SPHINCS+ memcpy source and destination overlap - undefined behavior
  • Add NTRU HPS-4096-1229 #1031: Add NTRU HPS-4096-1229
  • Known non-constant time behaviour in HQC #995: Known non-constant time behaviour in HQC
  • Update Classic McEliece to more recent version
• Code quality
  • Enabling more compiler warnings #1083: Enabling more compiler warnings
  • scan-build errors #194: scan-build errors
  • Code coverage #167: Code coverage
• Common code and building
  • Android Buildscript problem with Cross Compilation #1072: Android Buildscript problem with Cross Compilation
  • Investigate integrating pqcrystals common code to OQS common code #973: Investigate integrating pqcrystals common code to OQS common code
  • Establish interop with Circl and other implementations #910: Establish interop with Circl
  • Graceful runtime CPU feature handling #624: Graceful runtime CPU feature handling
  • Add options for iOS and Android cross-compilation #594: Add options for iOS and Android cross-compilation

OpenSSL

• Add X.509 implementation using composite keys and sigs drafts openssl#333: Add X.509 implementation using composite keys and sigs drafts
• Implement more stuff in oqs-provider
  • Interoperability with oqs-openssl? oqs-provider#32: Interoperability with oqs-openssl?
  • Hybrid KEM: more combiners, more abstraction oqs-provider#17: Hybrid KEM: more combiners, more abstraction
  • Implement full TLS1.3 OQS signature support oqs-provider#9: Implement full TLS1.3 OQS signature support
  • Implement interoperable CMS oqs-provider#8: Implement interoperable CMS
  • Implement interoperable X509 read/write oqs-provider#7: Implement interoperable X509 read/write
  • Implement interoperable key gen & storage oqs-provider#6: Implement interoperable key gen & storage
  • Add hybrid support oqs-provider#3: Add hybrid support
  • Implement encoder/decoder oqs-provider#2: Implement encoder/decoder

[baentsch]

I can already state that my goal is to complete open-quantum-safe/oqs-provider#2, open-quantum-safe/oqs-provider#3, open-quantum-safe/oqs-provider#7, probably open-quantum-safe/oqs-provider#8 at latest by year-end. It would be nice to have a clear perspective what "Interoperability" shall mean in general (before closing out open-quantum-safe/oqs-provider#32): Across different (TLS) prototype implementations or even implementing IETF drafts? If the latter, which ones?

General question: By when do we want to do a next release? Coinciding with the next NIST decision or before?

[dstebila]

I can already state that my goal is to complete open-quantum-safe/oqs-provider#2, open-quantum-safe/oqs-provider#3, open-quantum-safe/oqs-provider#7, probably open-quantum-safe/oqs-provider#8 at latest by year-end. It would be nice to have a clear perspective what "Interoperability" shall mean in general (before closing out open-quantum-safe/oqs-provider#32): Across different (TLS) prototype implementations or even implementing IETF drafts? If the latter, which ones?

I would say interoperability would be about each of our subprojects implementing the current version of whatever Internet Draft is relevant, and being able to interoperate with each other at the very least at the protocol level. I don't have strong opinions about whether they should be able to interoperate at a command-line file level, e.g., that private key files saved to disk by OpenSSL 1.1.1 can be used in OpenSSL 3 provider and vice versa. That would be nice, but in the absence of an external spec saying what format those key files should have, I don't see it as strictly necessary.

General question: By when do we want to do a next release? Coinciding with the next NIST decision or before?

How about a release by the end of November? That would more or less tie a ribbon on everything pre-NIST decision and then we can decide how to move forward once we see the NIST decision.

[baentsch]

Agree to all of the above with one caveat:

That would be nice, but in the absence of an external spec saying what format those key files should have, I don't see it as strictly necessary.

In the absence of an external spec I'd see it as very sensible to not create more different file formats, particularly by a single team. It's bad enough when/if different companies create non-interoperable QSC data structures but an open source project should strive to avoid that/do that only with a good reason (say implementing a draft RFC).

In addition we'll have more/stronger NTRUPrime algs (#1111) in an 0.7.1 release.

[christianpaquin]

Just added issue #1113 (new Picnic update); should be quick and one more thing for 0.7.1