First, according to PKCS#11:
The mechanisms will accept an optional mechanism parameter as the Initialization vector which, if present, must be a fixed size array of 8 bytes, and, if NULL, will use the default initial value defined in Section 22.214.171.124 of [AES KEYWRAP].
The type of this parameter is CK_BYTE_PTR and the pointer points to the array of 8 bytes to be used as the initial value. The length shall be either 0 and the pointer NULL, or 8, and the pointer non-NULL.
However, according to SP800-38F, the ICV2 value for AES-Key Wrap PAD must be four bytes in order to correctly pad the input to the cipher routine (section 6.3 algorithm 5).
Secondly, PKCS#11 specifies that CKM_AES_KEY_WRAP_PAD is used for Encryption/Decryption only, not for Wrapping/Unwrapping operations (Table 65, in section 2.14 in the PKCS#11 current mechanism specification). This seems inconsistent with the goals of the AES KEY Wrap Pad algorithm.
So my questions are:
- Is this a known inconsistency and has Cryptoki released any updates to how the CKM_AES_KEY_WRAP_PAD algorithm can be used? I cannot find anything on Google but maybe I missed something.
- In my PKCS#11 implementation, can my solution be to inform the user (through documentation) that the IV for CKM_AES_KEY_WRAP_PAD will be truncated to 4-bytes?
- I know this appears to be out of spec, but can I in my PKCS#11 implementation allow the user to use CKM_AES_KEY_WRAP_PAD for Wrapping/Unwrapping as well as Encryption/Decryption.