與 PKCS#11 v2.40 CKM_AES_KEY_WRAP_PAD 不一致

PKCS#11 v2.40 Current Mechanism Specification與SP800-38F中定義的 AES Key Wrap Pad規範之間似乎存在一些不一致。

首先，根據 PKCS#11：

這些機制將接受一個可選的機制參數作為初始化向量，如果存在，它必須是一個固定大小的 8 字節數組，如果為 NULL，將使用第 2.2.3.1 節中定義的預設初始值

$$ AES KEYWRAP $$. 該參數的類型為CK_BYTE_PTR，指針指向8字節數組作為初始值。長度應為 0 且指針為 NULL，或者為 8 且指針非 NULL。

但是，根據 SP800-38F，AES-Key Wrap PAD 的 ICV2 值必須是四個字節，以便正確填充密碼常式的輸入（第 6.3 節算法 5）。

其次，PKCS#11 指定 CKM_AES_KEY_WRAP_PAD 僅用於加密/解密，而不用於包裝/解包操作（表 65，在 PKCS#11 目前機制規範的第 2.14 節中）。這似乎與 AES KEY Wrap Pad 算法的目標不一致。

所以我的問題是：

1. 這是一個已知的不一致嗎，Cryptoki 是否發布了有關如何使用 CKM_AES_KEY_WRAP_PAD 算法的任何更新？我在Google上找不到任何東西，但也許我錯過了一些東西。
2. 在我的 PKCS#11 實現中，我的解決方案是否可以通知使用者（通過文件）CKM_AES_KEY_WRAP_PAD 的 IV 將被截斷為 4 字節？
3. 我知道這似乎不符合規範，但我可以在我的 PKCS#11 實現中允許使用者使用 CKM_AES_KEY_WRAP_PAD 進行包裝/解包以及加密/解密。

PKCS#11 技術委員會目前正在研究標準版本 3.0。你可以在這裡找到最新的工作草案：https ://www.oasis-open.org/committees/download.php/64968/pkcs11-curr-v3.0-wd09.docx

事實上，重新設計的“AES Key Wrap”部分（現在是 2.16）解決了你的問題：

• 它允許所有機制與 Encrypt&Decrypt 和 Wrap&Unwrap 一起使用。
• 它闡明了 CKM_AES_KEY_WRAP 和 CKM_AES_KEY_WRAP_PAD 實際上是指 NIST SP800-38F 第 6.2 節（“KW”），實際上需要 8 字節 IV。
• 它引入了新的 CKM_AES_KEY_WRAP_KWP，這是您正在尋找的 NIST SP800-38F 第 6.3 節的算法 KWP。

工作草案的標頭檔可以在這裡找到：https ://github.com/oasis-tcs/pkcs11/tree/master/working/3-00-wd-01

引用自：https://crypto.stackexchange.com/questions/68677