Conversation
|
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:
|
9a5be19 to
f0c0895
Compare
|
latest version now passes all MLKEM / MLDSA wycheproof tests |
|
@sjaeckel ping |
|
in all submissions there are KATs (vectors) included |
sjaeckel
left a comment
sjaeckel
left a comment
There was a problem hiding this comment.
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.
| LTC_PKA_MLDSA, | ||
| LTC_PKA_SLHDSA, | ||
| LTC_PKA_MLKEM, |
There was a problem hiding this comment.
What's the reasoning to put them in the middle of the enum and not at the end?
| * LibTomCrypt tagged-union for holding a Public Key | ||
| */ | ||
|
|
||
| #include "tomcrypt_pqc.h" |
There was a problem hiding this comment.
Please move this to the top of the file.
| /* DER INTEGER decodes into an MPI, so fail cleanly when no math provider is active. */ | ||
| if (ltc_mp.name == NULL) { | ||
| return CRYPT_INVALID_ARG; | ||
| } | ||
|
|
There was a problem hiding this comment.
Please put this in a separate commit.
| /* Flexi INTEGER nodes are MPI-backed, so reject no-math builds before ltc_mp_init(). */ | ||
| if (ltc_mp.name == NULL) { | ||
| err = CRYPT_INVALID_ARG; | ||
| goto error; | ||
| } | ||
|
|
| int ltc_pqc_algname_match(const char *left, const char *right) | ||
| { | ||
| char lc_r, lc_l; | ||
|
|
||
| if (left == NULL || right == NULL) return 0; | ||
|
|
||
| while ((*left != '\0') && (*right != '\0')) { | ||
| while ((*left == '-') || (*left == '_')) left++; | ||
| while ((*right == '-') || (*right == '_')) right++; | ||
| if (*left == '\0' || *right == '\0') break; | ||
| lc_r = *right; | ||
| lc_l = *left; | ||
| if ((lc_r >= 'A') && (lc_r <= 'Z')) lc_r += 32; | ||
| if ((lc_l >= 'A') && (lc_l <= 'Z')) lc_l += 32; | ||
| if (lc_l != lc_r) return 0; | ||
| left++; | ||
| right++; | ||
| } | ||
|
|
||
| if ((*left == '\0') && (*right == '\0')) return 1; | ||
| return 0; | ||
| } |
There was a problem hiding this comment.
That's a near copy of
libtomcrypt/src/pk/ecc/ecc_find_curve.c
Line 193 in a8ed78c
4 participants
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