[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [pkcs11] CKM_ECDH_AES_KEY_WRAP investigation
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 Utimaco IS GmbH Germanusstr. 4, D.52080 Aachen, Germany, Tel: +49-241-1696-0, www.utimaco.com Seat: Aachen â Registergericht Aachen HRB 18922 VAT ID No.: DE 815 496 496 Managementboard: Stefan Auerbach (Chairman) CEO, Malte Pollmann CSO, Martin Stamm CFO This communication is confidential. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. Please inform us immediately and destroy the email. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]