Post-Quantum Cryptography (PQC) support #720
No reviewers
Labels
No labels
bug
duplicate
enhancement
feature
help wanted
improve API
invalid
needs documentation
not-planned
rtfm
stale
support
wishlist
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-libtom/libtomcrypt!720
Loading…
Reference in a new issue
No description provided.
Delete branch "pr/pqc1"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This pull request introduces an initial proposal for Post-Quantum Cryptography (PQC) support
It adds support for the following NIST PQC standards:
Further details on the standards can be found here: https://csrc.nist.gov/projects/post-quantum-cryptography#pqc-standards
The implementation is based on the official reference implementations (all of them public domain):
I also considered adding support for NTRU Prime (as currently used for hybrid kex in OpenSSH 9), but it appears that the OpenSSH project is planning to move to ML-KEM in version 10. Therefore, I kept only the NIST PQC stuff.
A new public API has been introduced in:
src/headers/tomcrypt_pqc.hThe aim was to keep the interface simple/compact (unfortunately PQC itself is far from being simple/compact), while aligning with existing LTC design patterns.At present, the test coverage is limited to basic functional checks:
MISSING: Official NIST test vectors still need to be identified (ACVP?) and added to the test suite.
MISSING: Interoperability with other crypto libraries was not tested at all.MISSING: Functions for key import/export currently handle only raw data; sooner or later PKCS#8 (for privkeys) and/or SPKI/X.509 (for pubkeys) will be probably needed.IMPORTANT: The code in this initial PR is very lightly tested and is not suitable for production use.
This change is intended as a first step towards PQC support and is open for discussion, review, and further improvements.
Checklist
As for key formats, there are some very recent standards:
It looks doable with the infrastructure we have in LTC, but quite a lot of work. It may be worth creating a separate PR.
I don't know what OpenSSH's plan is for hybridizing any or all of these, but sntrup761x25519 was a very, very good idea in that it is provably at least as secure as both. There are still questions about the FIPS PQ algos' classic security. I would encourage dialog with the OpenSSH project to replicate this great idea. And with Jan Mojžíš of TinySSH who was, I understand, the driver behind that idea originally. Curve448 would be a great primitive to use for this, as it has some support already in several implementations (and in OpenSSL).
Secondly, does your implementation include the 256-bit (classic-strength) versions of these? ML-KEM-1024 & ML-DSA-87?
We support all parameter sets defined in NIST FIPS 203:
We also support all parameter sets defined in NIST FIPS 204:
And all from NIST FIPS 205:
So yes, this includes the higher-security parameter sets such as ML-KEM-1024 and ML-DSA-87.
As for OpenSSh see https://www.openssh.org/releasenotes.html it looks as they already switched the default to mlkem768x25519-sha256 in OpenSSH 9.9.
On adding further algorithms such as NTRU Prime 761, our preference is to follow widely adopted standards. NIST remains a credible standards body (even if some people see it negatively for geopolitical reasons). In the past, we added a few algorithms that were close to becoming standards but never quite got there and that usually created extra maintenance work.
Update:
However, we are now getting some segfaults in the GitLab tests(edit: fixed)latest version now passes all MLKEM / MLDSA wycheproof tests
@sjaeckel ping
https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization/round-4-submissions
in all submissions there are KATs (vectors) included
This isn't a deep review, I only skimmed over it. It basically looks fine, just some nitpicks here and there, but I'll do a deep review hopefully soon'ish.
Additional to those comments I'd prefer to see the different algos put in a separate folder and duplicated stuff like those oid-enum maps being de-duplicated. I guess I can spend some time next week and bring this in shape as well.
What's the reasoning to put them in the middle of the
enumand not at the end?Please move this to the top of the file.
Please put this in a separate commit.
and this
That's a near copy of
github.com/libtom/libtomcrypt@a8ed78c2ca/src/pk/ecc/ecc_find_curve.c (L193)... maybe make this a private API function (not in pqc namespace) instead and use that?As for "separate folders" you mean to turn this:
into:
?
Can move it a bit higher but it has to stay after "typedef struct password_ctx {...}"
How about forward declaring the typedef in the pqc header?
ends up with:
tomcrypt_pk.h:823:7: error: unknown type name ‘mlkem_key’ends up with:
tomcrypt_pqc.h:197:77: error: unknown type name ‘password_ctx’View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.Merge
Merge the changes and update on Forgejo.Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.