RE: [pkcs11] Groups - Kem Algorithms uploaded

I’ve added some questions/comments inline below in response to your comments.

And here I have some additional questions/comments I had.

1) I know this is an early draft, but there are grammatical mistakes (or just inconsistencies) where you added “and key encapsulation and key decapsulation”. I sure this wasn’t the your main focus for the draft.

2) ECDH/DH. should we be more specific about the format of the returned public keys? We’ve had issues related to this in the paste. This may apply to some of the other KEM mechanisms too.

3) Kyber

a. Why did you choose to include wrap/unwrap using Kyber.CPAPKE yet exclude encrypt/decrypt? Its limitations? complexity? or you didn’t see a need for it?

b. should the CKA_VALUE attribute really be a Big Integer? shouldn’t it be a byte array given that it is a compressed and encoded polynomial?

c. section 1.4.4, CKA_BASE and CKA_PRIME are used. I assume this is a type.

And finally, below are other questions I received from various people at Thales. I didn’t have time to review them internally with them.

- (1.4.1 Definitions): Why introduce new CK_KYBER_PARAMETER_SET_TYPE (CKP_KYBER512, CKP_KYBER768, CKP_KYBER1024) attribute? I like it... but, why introduce this new parameter if we can reuse CKA_VALUE_LEN just like Symmetric keys do to determine strength (i.e. AES: 16, 24, 32)?

- (1.4.2 Kyber public key objects): The Kyber public key should have the CKA_ENCAPSULATE attribute set during creation. Just like the private key template has CKA_DECAPSULATE:

{CKA_ENCAPSULATE, &true, sizeof(true)},

- (1.4.3 Kyber private key objects): The statement below does NOT match the example attribute template. It DOES contain CKA_PARAMETER_SET

"Note that when generating a Kyber private key, the parameter set is not specified in the key’s template.

This is because Kyber private keys are only generated as part of a Kyber key pair, and the parameter

set for the pair is specified in the template for the Kyber public key."

[DJ] The example was for “creating a private key”, which implies C_CreateObject.

With that in mind, I think the sample code is valid?

CK_ATTRIBUTE template[] = {

{CKA_CLASS, &class, sizeof(class)},

{CKA_KEY_TYPE, &keyType, sizeof(keyType)},

{CKA_TOKEN, &true, sizeof(true)},

{CKA_LABEL, label, sizeof(label)-1},

{CKA_SUBJECT, subject, sizeof(subject)},

{CKA_ID, id, sizeof(id)},

{CKA_SENSITIVE, &true, sizeof(true)},

{CKA_DECAPSULATE, &true, sizeof(true)},

{CKA_PARAMETER_SET, &param_set, sizeof(param_set)},

{CKA_VALUE, value, sizeof(value)}

In my opinion, the parameter_set attribute should be on both public and private key attribute templates.

- (1.4.4 Kyber key pair generation): What are "CKA_PRIME” and “CKA_BASE" attributes used to generate a new private key? The library (liboqs) we use to generate Kyber keys does NOT require such attributes.

[DJ] I assume this is a typo or copy-paste error.

From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org> On Behalf Of Robert Relyea
Sent: Tuesday, January 31, 2023 7:09 PM
To: pkcs11@lists.oasis-open.org
Subject: [pkcs11] Groups - Kem Algorithms uploaded

Submitter's message
General decisions in this and the KEM API proposal which bear more discussion:

1) I called the new functions C_Encapsulate and C_Decapsulate rather than C_EncapsulateKey and C_DecapsulateKey. It might make sence to go with the former as it matches C_WrapKey, C_UnwrapKey, and C_DeriveKey.

[DJ] I assume you are suggesting that we should stick with the C_xxxKey convention?

2) I added C_Encapsulate/C_Decapsulate definitions several existing mechanisms: CKM_RSA_PKCS, CKM_RSA_OAEP, CKM_RSA_X509, CKM_ECDH_DERIVE, CKM_ECDH_COFACTOR_DERIVE, CKM_DH_DERIVE, CKM_DH_X9_42_DERIVE.
I didn't add C_Encapsulate/C_Decapsulate definitions for any of the RSA TPS mechanisms. The seemed pretty specific for TPS.

[DJ] You mean TPM right? just making sure there isn’t something else I’m not aware of.
I didn't add C_Encapsulate/C_Decapsulate definitions for any of the ECDH/DH variants which use 2 keys (They don't really map to KEMS).

I added CKM_RSA_X509 KEM as the NIST RSASVE. It might make since, to define a separate mechanism fro RSASVE (which is KEM only).

[DJ] I agree. That might make it easier to leverage things like CKA_ALLOWED_MECHANISMS.
3) For Kyber, I defined a single mechanism and key type and the Parameter set is an attribute of the key. I defined the parameter set as a PKCS #11 constant and not a set of parameters since the security of Kyber is tightly tied to getting the parameters correct (and it avoids issues we have with using parameterized curves in ECC).
I also defined the mechanism as providing Kyber.CPAPKE if used with wrap/unwrap. Should this really be a separate mechanism. The private key in Kyber CPAPKE is a subset of the CCAKEM private key. The public keys are identical. It's possible NIST will not define a public CPAPKE interface, but just define it as a primitive used to build CCAKEM.

[DJ] Given that the keys are not identical, they probably need their own key type and mechanism. Either that, or some other way to identify the key. CKA_KEY_GEN_MECHANISM would help, but wouldn’t work well for unwrapped keys.
Kyber key lengths are a bit a a mash. I chose the public key length as key length specified in C_MECHANISM_INFO, and set it's length to bytes (which is different than our existing public key algorithms, but consistent with all the new Post Quantum algorithm documentation).

[DJ] I had the same thoughts. I can’t see any clean way to manage this.
I did not define any of the 90s Parameter sets (though everything is specified in a way that adding future parameter sets would not be difficult). it's even possible we could define experimental Parameter sets that match the Round 3 Proposal.
We could also define the parameter sets as an oid, and push the definition back to x509/ansi.
-- Mr. Robert Relyea

Document Name: Kem Algorithms

Description
Algorithms that can use the new Kem APIs
Download Latest Revision
Public Download Link

Submitter: Mr. Robert Relyea
Group: OASIS PKCS 11 TC
Folder: Working Drafts
Date submitted: 2023-01-31 16:09:14

pkcs11 message