first cut adding ML-* #348
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -38,6 +38,16 @@ As standardization for these algorithms within TLS is not done, all TLS code poi | |
| | p256_kyber768 | 0x639A | Yes | OQS_CODEPOINT_P256_KYBER768 | | ||
| | kyber1024 | 0x023D | Yes | OQS_CODEPOINT_KYBER1024 | | ||
| | p521_kyber1024 | 0x2F3D | Yes | OQS_CODEPOINT_P521_KYBER1024 | | ||
| | mlkem512 | 0x0247 | Yes | OQS_CODEPOINT_MLKEM512 | | ||
| | p256_mlkem512 | 0x2F47 | Yes | OQS_CODEPOINT_P256_MLKEM512 | | ||
| | x25519_mlkem512 | 0x2FB2 | Yes | OQS_CODEPOINT_X25519_MLKEM512 | | ||
| | mlkem768 | 0x0248 | Yes | OQS_CODEPOINT_MLKEM768 | | ||
| | p384_mlkem768 | 0x2F48 | Yes | OQS_CODEPOINT_P384_MLKEM768 | | ||
| | x448_mlkem768 | 0x2FB3 | Yes | OQS_CODEPOINT_X448_MLKEM768 | | ||
| | x25519_mlkem768 | 0x2FB4 | Yes | OQS_CODEPOINT_X25519_MLKEM768 | | ||
| | p256_mlkem768 | 0x2FB5 | Yes | OQS_CODEPOINT_P256_MLKEM768 | | ||
| | mlkem1024 | 0x0249 | Yes | OQS_CODEPOINT_MLKEM1024 | | ||
| | p521_mlkem1024 | 0x2F49 | Yes | OQS_CODEPOINT_P521_MLKEM1024 | | ||
| | bikel1 | 0x0241 | Yes | OQS_CODEPOINT_BIKEL1 | | ||
| | p256_bikel1 | 0x2F41 | Yes | OQS_CODEPOINT_P256_BIKEL1 | | ||
| | x25519_bikel1 | 0x2FAE | Yes | OQS_CODEPOINT_X25519_BIKEL1 | | ||
|
|
@@ -61,6 +71,13 @@ As standardization for these algorithms within TLS is not done, all TLS code poi | |
| | p384_dilithium3 | 0xfea4 |Yes| OQS_CODEPOINT_P384_DILITHIUM3 | ||
| | dilithium5 | 0xfea5 |Yes| OQS_CODEPOINT_DILITHIUM5 | ||
| | p521_dilithium5 | 0xfea6 |Yes| OQS_CODEPOINT_P521_DILITHIUM5 | ||
| | mldsa44 | 0xfed0 |Yes| OQS_CODEPOINT_MLDSA44 | ||
| | p256_mldsa44 | 0xfed3 |Yes| OQS_CODEPOINT_P256_MLDSA44 | ||
| | rsa3072_mldsa44 | 0xfed4 |Yes| OQS_CODEPOINT_RSA3072_MLDSA44 | ||
| | mldsa65 | 0xfed1 |Yes| OQS_CODEPOINT_MLDSA65 | ||
| | p384_mldsa65 | 0xfed5 |Yes| OQS_CODEPOINT_P384_MLDSA65 | ||
| | mldsa87 | 0xfed2 |Yes| OQS_CODEPOINT_MLDSA87 | ||
| | p521_mldsa87 | 0xfed6 |Yes| OQS_CODEPOINT_P521_MLDSA87 | ||
| | falcon512 | 0xfeae |Yes| OQS_CODEPOINT_FALCON512 | ||
| | p256_falcon512 | 0xfeaf |Yes| OQS_CODEPOINT_P256_FALCON512 | ||
| | rsa3072_falcon512 | 0xfeb0 |Yes| OQS_CODEPOINT_RSA3072_FALCON512 | ||
|
|
@@ -126,6 +143,13 @@ adapting the OIDs of all supported signature algorithms as per the table below. | |
| | p384_dilithium3 | 1.3.9999.2.7.3 |Yes| OQS_OID_P384_DILITHIUM3 | ||
| | dilithium5 | 1.3.6.1.4.1.2.267.7.8.7 |Yes| OQS_OID_DILITHIUM5 | ||
| | p521_dilithium5 | 1.3.9999.2.7.4 |Yes| OQS_OID_P521_DILITHIUM5 | ||
| | mldsa44 | 1.3.6.1.4.1.2.267.12.4.4 |Yes| OQS_OID_MLDSA44 | ||
| | p256_mldsa44 | 1.3.9999.7.1 |Yes| OQS_OID_P256_MLDSA44 | ||
| | rsa3072_mldsa44 | 1.3.9999.7.2 |Yes| OQS_OID_RSA3072_MLDSA44 | ||
| | mldsa65 | 1.3.6.1.4.1.2.267.12.6.5 |Yes| OQS_OID_MLDSA65 | ||
| | p384_mldsa65 | 1.3.9999.7.3 |Yes| OQS_OID_P384_MLDSA65 | ||
| | mldsa87 | 1.3.6.1.4.1.2.267.12.8.7 |Yes| OQS_OID_MLDSA87 | ||
| | p521_mldsa87 | 1.3.9999.7.4 |Yes| OQS_OID_P521_MLDSA87 | ||
| | falcon512 | 1.3.9999.3.6 |Yes| OQS_OID_FALCON512 | ||
| | p256_falcon512 | 1.3.9999.3.7 |Yes| OQS_OID_P256_FALCON512 | ||
| | rsa3072_falcon512 | 1.3.9999.3.8 |Yes| OQS_OID_RSA3072_FALCON512 | ||
|
|
@@ -164,48 +188,58 @@ If [OQS_KEM_ENCODERS](CONFIGURE.md#OQS_KEM_ENCODERS) is enabled the following li | |
|
|
||
| |Algorithm name | default OID | environment variable | | ||
| |---------------|:-----------------:|----------------------| | ||
| | frodo640aes | 1.3.9999.99.58 | OQS_OID_FRODO640AES | ||
| | p256_frodo640aes | 1.3.9999.99.57 | OQS_OID_P256_FRODO640AES | ||
| | x25519_frodo640aes | 1.3.9999.99.43 | OQS_OID_X25519_FRODO640AES | ||
| | frodo640shake | 1.3.9999.99.60 | OQS_OID_FRODO640SHAKE | ||
| | p256_frodo640shake | 1.3.9999.99.59 | OQS_OID_P256_FRODO640SHAKE | ||
| | x25519_frodo640shake | 1.3.9999.99.44 | OQS_OID_X25519_FRODO640SHAKE | ||
| | frodo976aes | 1.3.9999.99.62 | OQS_OID_FRODO976AES | ||
| | p384_frodo976aes | 1.3.9999.99.61 | OQS_OID_P384_FRODO976AES | ||
| | x448_frodo976aes | 1.3.9999.99.45 | OQS_OID_X448_FRODO976AES | ||
| | frodo976shake | 1.3.9999.99.64 | OQS_OID_FRODO976SHAKE | ||
| | p384_frodo976shake | 1.3.9999.99.63 | OQS_OID_P384_FRODO976SHAKE | ||
| | x448_frodo976shake | 1.3.9999.99.46 | OQS_OID_X448_FRODO976SHAKE | ||
| | frodo1344aes | 1.3.9999.99.66 | OQS_OID_FRODO1344AES | ||
| | p521_frodo1344aes | 1.3.9999.99.65 | OQS_OID_P521_FRODO1344AES | ||
| | frodo1344shake | 1.3.9999.99.68 | OQS_OID_FRODO1344SHAKE | ||
| | p521_frodo1344shake | 1.3.9999.99.67 | OQS_OID_P521_FRODO1344SHAKE | ||
| | kyber512 | 1.3.6.1.4.1.22554.5.6.1 | OQS_OID_KYBER512 | ||
| | p256_kyber512 | 1.3.6.1.4.1.22554.5.7.1 | OQS_OID_P256_KYBER512 | ||
| | x25519_kyber512 | 1.3.6.1.4.1.22554.5.8.1 | OQS_OID_X25519_KYBER512 | ||
| | kyber768 | 1.3.6.1.4.1.22554.5.6.2 | OQS_OID_KYBER768 | ||
| | p384_kyber768 | 1.3.9999.99.69 | OQS_OID_P384_KYBER768 | ||
| | x448_kyber768 | 1.3.9999.99.47 | OQS_OID_X448_KYBER768 | ||
| | x25519_kyber768 | 1.3.9999.99.48 | OQS_OID_X25519_KYBER768 | ||
| | p256_kyber768 | 1.3.9999.99.49 | OQS_OID_P256_KYBER768 | ||
| | kyber1024 | 1.3.6.1.4.1.22554.5.6.3 | OQS_OID_KYBER1024 | ||
| | p521_kyber1024 | 1.3.9999.99.70 | OQS_OID_P521_KYBER1024 | ||
| | mlkem512 | 1.3.6.1.4.1.22554.5.6.1 | OQS_OID_MLKEM512 | ||
|
There was a problem hiding this comment. ML-KEM (e.g., mlkem512) has the same OID as Kyber (e.g., kyber512), is this intentional? There was a problem hiding this comment. Kind-of: In the absence of a spec (or can you point to one, @bhess ?) I took the OIDs chosen by the IETF hackathon (assuming that's the latest ... is it, @praveksharma ?) And if they chose the same OID as for Kyber, well, that points to bad OID management (in this case apparently by the Legions of Bouncy Castle owning that range) and/or the need for someone to take the lead and draft a spec (@dstebila -- what about an "independent" PQ alliance taking that lead?) There was a problem hiding this comment.
I don't know who is meant to assign the permanent OID for an algorithm -- is it the inventor? the standards body? the first implementer? an alliance? @bhess, if memory serves, IBM assigned some OIDs for earlier rounds of Kyber and Dilithium, are you planning to assign OIDs for ML--ipd or ML-? There was a problem hiding this comment. NIST usually registers OIDs for approved/standardized algorithms in CSOR. We have in the past reserved OIDs for algorithms used but not already assigned (earlier round versions and ML-DSA-ipd). There was a problem hiding this comment.
Please document this in generate.yml as per #351; more people taking responsibility for proper (O)ID allocation very welcome: We could split this task among all of us, e.g., along algorithms: Volunteers welcome! |
||
| | p256_mlkem512 | 1.3.6.1.4.1.22554.5.7.1 | OQS_OID_P256_MLKEM512 | ||
| | x25519_mlkem512 | 1.3.6.1.4.1.22554.5.8.1 | OQS_OID_X25519_MLKEM512 | ||
| | mlkem768 | 1.3.6.1.4.1.22554.5.6.2 | OQS_OID_MLKEM768 | ||
| | p384_mlkem768 | 1.3.9999.99.71 | OQS_OID_P384_MLKEM768 | ||
| | x448_mlkem768 | 1.3.9999.99.50 | OQS_OID_X448_MLKEM768 | ||
| | x25519_mlkem768 | 1.3.9999.99.51 | OQS_OID_X25519_MLKEM768 | ||
| | p256_mlkem768 | 1.3.9999.99.52 | OQS_OID_P256_MLKEM768 | ||
| | mlkem1024 | 1.3.6.1.4.1.22554.5.6.3 | OQS_OID_MLKEM1024 | ||
| | p521_mlkem1024 | 1.3.9999.99.72 | OQS_OID_P521_MLKEM1024 | ||
| | bikel1 | 1.3.9999.99.74 | OQS_OID_BIKEL1 | ||
| | p256_bikel1 | 1.3.9999.99.73 | OQS_OID_P256_BIKEL1 | ||
| | x25519_bikel1 | 1.3.9999.99.53 | OQS_OID_X25519_BIKEL1 | ||
| | bikel3 | 1.3.9999.99.76 | OQS_OID_BIKEL3 | ||
| | p384_bikel3 | 1.3.9999.99.75 | OQS_OID_P384_BIKEL3 | ||
| | x448_bikel3 | 1.3.9999.99.54 | OQS_OID_X448_BIKEL3 | ||
| | bikel5 | 1.3.9999.99.78 | OQS_OID_BIKEL5 | ||
| | p521_bikel5 | 1.3.9999.99.77 | OQS_OID_P521_BIKEL5 | ||
| | hqc128 | 1.3.9999.99.80 | OQS_OID_HQC128 | ||
| | p256_hqc128 | 1.3.9999.99.79 | OQS_OID_P256_HQC128 | ||
| | x25519_hqc128 | 1.3.9999.99.55 | OQS_OID_X25519_HQC128 | ||
| | hqc192 | 1.3.9999.99.82 | OQS_OID_HQC192 | ||
| | p384_hqc192 | 1.3.9999.99.81 | OQS_OID_P384_HQC192 | ||
| | x448_hqc192 | 1.3.9999.99.56 | OQS_OID_X448_HQC192 | ||
| | hqc256 | 1.3.9999.99.84 | OQS_OID_HQC256 | ||
| | p521_hqc256 | 1.3.9999.99.83 | OQS_OID_P521_HQC256 | ||
| <!--- OQS_TEMPLATE_FRAGMENT_OIDS_END --> | ||
|
|
||
| # Key Encodings | ||
|
|
||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like all KEM OIDs changed, is this necessary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are generated OIDs, i.e. ones that no-one ever cared about (to specify). I'm thus inclined to leave as-is (and take complaints as indications that they ought to be defined in "generate.yml" -- with the complaints pointing to a spec about whose existence I'd gladly learn).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fine with me to use generated ones with the absence of specified ones. Just wondering why the PR updates the OIDs of algorithms unrelated to ML-KEM/DSA (e.g., frodo640aes:
1.3.9999.99.50->1.3.9999.99.58), did these algorithms change (in liboqs)?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oqs-provider/oqs-template/generate.py
Lines 121 to 125 in 510fea6
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the pointer, I see two issues with the get_tmp_kem_oid() code.
oqs-provider/oqs-template/generate.py
Lines 95 to 98 in 510fea6
1.3.9999.99.50->1.3.9999.99.581.3.9999.99.54was for frodo976aes, now the same OID is forx448_bikel3But maybe I misunderstand the purpose of the temp KEM OIDs. If they are just dummy values not supposed to be globally unique, why not assign the same temp OID for all algorithms without specified OID?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No(t that I knew): How would the cert signature be done in such scenario? These OIDs are solely used to register a KEM en/decoder for public and private keys. Had I known that this would create such a fuzz, I'd never have done #266.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The OIDs have changed already. They're random, after all -- since October 2023.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The subject's public key can be a KEM / public key encryption key, but the CA must use a digital signature scheme key in order to produce a signature on such a certificate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So how is this facilitated using
openssl? I for sure have never done this. If you know how to, please contribute a test for this.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did they change in October 2023, or were they introduced in October 2023? I'm looking at 5515b4b#diff-ef6f384f213c1efa6cdc7974fec75a672ce414650acb8ec1f0abdd5984076595R167 which is dated October 5 2023 and it looks to me like this when OIDs for e.g. FrodoKEM were first added, and then they've been stable since them.