experimental/not production ready status

[embetrix]

Hello,

The project emphasizes that is intended for prototyping and experimentation and not production ready.

I’d like to better understand what specifically drives this wording today:

• limited adoption and usage ?
• limited third-party security/auditing ?
• support for non-standard algorithms along side with NIST-approved ?

I ask because this wording can hinder adoption or downstream integration in other software projects even when only NIST-standardized schemes are used.

any clarification on the current maturity expectations would be very helpful.

[baentsch]

fwiw, there's been lots of discussions around this topic, see e.g., open-quantum-safe/tsc#1 or PQCA/TAC#44.

The jist in my eyes: There's just not enough development time, commitment and brainpower (to avoid any gender-specific term :) nor sufficient secure code development capability available to allow OQS to change this wording (and more importantly, the code).

This project is run by researchers for researchers.

Other code bases are doing a much more diligent job creating production quality code, e.g., BoringSSL or OpenSSL. Those projects also control the pedigree of their code, OQS does not: liboqs first and foremost is a collection of third-party code bases of (widely) varying quality and support levels.

All told, I think it's natural to see differences in code quality comparing projects with substantial funding and development capability to projects like OQS that move along on a best effort and/or research project basis.

I ask because this wording can hinder adoption or downstream integration in other software projects even when only NIST-standardized schemes are used.

This is well (and painfully) understood. But (not just) for secure software, it is not (just) the standardization level of algorithms that define the quality/usefulness of the code: Standardization is only one aspect. Other aspects are secure coding practices, auditing, pentesting, maintenance, continued development commitments, etc. Other projects, proprietary as well as FOSS ones, are much further along these properties for single (specifically, NIST-approved) algorithms than OQS is.

OQS in turn excels in the breadth of algorithms it makes available -- not their "depth" (if you allow me to use that term as a proxy for quality or reliability).

Of course, contributors are very welcome that are willing to improve OQS in this regard. Caveat Emptor, though: This would imo entail more than a few bells and whistles here and there -- it would require a complete change of code base and development methodology, i.e., substantial investment.

[hippi777]

i think having timestamp/commit based labels for achieved/ensured qualities/properties, preferably alongside a checklist for what aspects can/should be tested would pave the way and put the focus to the right place... the pedigree doesnt matter if anything can be upstreamed, and it is a matter of developer commitment to write anything beyond running codes... also, i think those who want to experiment with these would like to experiment with such aspects as side channel attacks/protections/properties... i know its a whole industry segment without static knowledge on the field (i mean it evolves continuously) to test sw 4 security, but some1 with a cert that they are able to do such blackmagic could approve even a checklist whether it is complete or fulfills the requirements required by whichever cert... its a matter of writing things down... if something was true at a point, then if the point is known, then any1 with the right knowledge can pick up that flag and move it forward, if such should be found out from nothing, then it will move forward by accident and greater efforts...