Python library QuantCrypt uses PQClean #539
Replies: 2 comments 7 replies
-
|
I think we could look at a PR that does so. Separately I would encourage you to add a SECURITY.md and the appropriate notes to your README and documentation that implementations from PQClean are of experimental quality and relying on them for security is at your own risk. |
Beta Was this translation helpful? Give feedback.
-
|
So how should one obtain implementations that are of verified quality? Is PQClean not intending to become the source of truth for PQC algorithm implementations in C code? I was left with the impression that is precisely the goal of PQClean, as per librarys own description, or have I misunderstood something? What steps need to be taken to create verified implementations for PQClean? |
Beta Was this translation helpful? Give feedback.
-
|
We do our best, but we're basically a bunch of scientists and technologists that want to experiment with this stuff; this code has not been audited. "verified implementations" is a bit of a technical term. If you are looking for formally verified implementations (using proof tools etcetera), look at the Formosa project who are working on that. It's very much science in progress, though. If you are looking for implementations that have been audited for side-channel vulnerabilities, you will probably need to license them from someone with a lab and a bunch of people who do constant analysis, like my employer. |
Beta Was this translation helpful? Give feedback.
-
|
It seems to me the issue here is the definition of "experimental quality" and what it entails. There are multiple ways an algorithm can be vulnerable. Are we talking about a lapse in security in the underlying mathematics, or side-channel attack surface? I would guess side-channel attacks are irrelevant for like 99% of users, because side-channel attacks require direct access to the device (more or less). Therefore, I think its unnecessarily paranoid to label all PQClean source code as "potentially vulnerable", if the vulnerabilities might be of nature which do not affect 99% of the end users. It is important to make this distinction, because otherwise you're going to turn people off from using your library for unnecessary reasons. If the underlying math is correct and the algorithm produces the expected output as per its creators specifications, then the algorithm can be considered relevantly secure, if we assume that its creators have done their due diligence to evaluate the security of their algorithm, which they must have done to participate in the NIST PQC competition. If you should agree with my statements, then the SECURITY.md file of the PQClean project should be edited to be more specific about what the experimental quality is being claimed about. |
Beta Was this translation helpful? Give feedback.
-
This would be implementation vulnerabilities, which includes both 'regular' programming errors and (timing) side-channel attacks.
This is an often made assumption, and it is very much incorrect. Timing side channels are routinely exploited over the network. Additionally, you often load other people's code onto your devices through Javascript; this has also been used to exploit timing side-channels (including SPECTRE). https://www.usenix.org/conference/12th-usenix-security-symposium/remote-timing-attacks-are-practical
The amount effort put into this project closely matches its operational goals: best effort. We do not employ people to work on and improve this code, so bugs, like the recent side-channel issues like the recent Kyber bug (#534) take a while to get fixed. The ARM64 code hasn't received this fix. We have had other problems including memory-unsafe code that have persisted as "known issue" for a while because they didn't immediately break everything. We do not publish security bulletins, see also "best effort" and "experimental quality". As PQClean, much like most open-source cryptographic libraries, can not make predictions on the applications in which it is integrated, it is important to communicate what we are targeting. For PQClean, this means that this does not include production-level, security-critical use cases. People having such requirements are advised to take the appropriate caution. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, thank you for your clarifications! :) It is what it is for PQClean, but my point still stands that continuation on the current path will turn people away from using PQClean implementations in their applications, because why should an end-user trust PQClean if the creators of the library do not trust their own code? If PQClean should desire to become the go to source for PQC implementations, then the current course must be altered. |
Beta Was this translation helpful? Give feedback.
-
|
We are not aiming to become that (as we don't have the bandwidth to do this anyway), so that is fine. |
Beta Was this translation helpful? Give feedback.
-
|
Just out of curiosity, what would you need to achieve this bandwith? Developer resources? Monetary resources? In what capacity? |
Beta Was this translation helpful? Give feedback.
-
|
Developers is one thing, which indirectly implies funding; also I personally have other thing I find more interesting than the 'hard-core' software engineering (management) that this requires (mostly in research) |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I propose to include QuantCrypt into the Projects integrating PQClean-distributed source code section of the README.md file of the PQClean repository.
Beta Was this translation helpful? Give feedback.
All reactions