[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [pkcs11] CKM_ECDH_AES_KEY_WRAP investigation
|
All, Iâve uploaded a draft document for RSA KEM and ECDH key agreement in an attempt to address this. Sincerely, Jonathan From: Daniel Minder <Daniel.Minder@utimaco.com> Jonathan, All, thank you for your input. What you describe for RSA-KEM is quite similar to CKM_RSA_AES_KEY_WRAP. The crucial point is what you state at the beginning: âTo decrypt, you need to know the length of the RSA key, the KDF information, and the size of the symmetric key.â This is true for all such schemes (or implicit protocols) where two blobs are concatenated. For RSA, you can deduce the length of the encrypted random value from the RSA key because there is only one possible encoding. However, for CKM_ECDH_AES_KEY_WRAP
the first part is a temporary (transport) public EC key, which can be encoded in different formats of different length. In that case, splitting the concatenated blob becomes cumbersome as Iâve elaborated in my previous mail. The same approach as CKM_RSA_AES_KEY_WRAP or CKM_ECDH_AES_KEY_WRAP might be used for future asymmetric PQC algorithms. However, the exact encoding of the two parts of the final BLOB need to be described each time. Therefore, I would assume
that a new mechanism (CKM_XXX_AES_KEY_WRAP) has to be invented every time. Your remark concerning NIST SP800-56a rev3 is very valid. IFF there is no current implementation of CKM_ECDH_AES_KEY_WRAP anywhere we could now 1. define a format for the public key part of the BLOB and 2. switch to the cofactor primitive
to get a NIST compliant key wrapping algorithm. In any case we should do #1, and for #2 we could also add CKM_ECDH_COF_AES_KEY_WRAP (or something like that). Regards, Daniel From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org>
On Behalf Of Jonathan Schulze-Hewett All, Bob asked for protocol level documentation that could act as an example for CKM_ECDH_AES_KEY_WRAP. The closest thing Iâve found is RFC 5990 which covers RSA-KEM in CMS and requires the output of a random value encrypted with the RSA public
key of the recipient and the AES wrapped symmetric key. Basically to wrap/encrypt a symmetric key:
To decrypt, you need to know the length of the RSA key, the KDF information, and the size of the symmetric key. This additional data and the output of the KEM/Wrap is conveyed in the RecipientInfo field of the resulting CMS data. This basic key wrapping mechanism (generate a random value, encapsulate, derive, wrap) appears to be how all the PQC KEM algorithms are designed to be used.
PKCS#11 has the functions to do most of this in a generic way: Encrypt: C_DeriveKey with mechanism CKM_ECDH1_COFACTOR_ONE_PASS_UNIFIED, CKM_KEM (which should cover RSA and PQC since the key type defines the algorithm to use),
etc., takes the base public key and creates a new object whose CKA_VALUE contains the shared secret, and a new attribute CKA_SHARED that holds either the ECDH/DH ephemeral public key or the wrapped random value (whatever the âsharedâ information needs
to be). C_DeriveKey with a KDF mechanism (this might take some doing as most of the KDFs are defined as parameters), takes the key output from the first call, performs the KDF on the CKA_VALUE attribute as usual, and creates a new key object whose
CKA_VALUE is the derived key as usual. C_Encrypt/C_Wrap as usual with AES key wrapping. Decrypt: C_DeriveKey with the normal mechanism for ECDH or C_UnwrapKey for RSA/PQC which will create an object whose CKA_VALUE is the shared secret. C_DeriveKey with a KDF mechanism (this might take some doing as most of the KDFs are defined as parameters), takes the key output from the first call, performs the KDF on the CKA_VALUE attribute as usual, and creates a new key object whose
CKA_VALUE is the derived key as usual. C_Decrypt/C_Unwrap as usual with AES key wrapping. Finally, NIST SP800-56a rev3 uses the cofactor primitive for the key agreement step and CKM_ECDH_AES_KEY_WRAP does not which seems odd to me. Perhaps we should deprecate CKM_ECDH_AES_KEY_WRAP and do something more generic?
Sincerely, Jonathan
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]