關於 PKCS11 2.40 規範和 AES_CBC 包裝的問題
PKCS11 cryptoki 版本 2.40 目前機制規範（第 2.8.5 節），對 AES CBC 包裝的聲明如下：
對於包裝，該機制加密被包裝的密鑰的 CKA_VALUE 屬性的值，在尾端填充最多塊大小減去一個空字節，以便生成的長度是塊大小的倍數
問題：
- 如果任何鍵最後有 NULL 字節（或零），解包如何知道添加了多少填充字節？
- 另外，我是密碼學的初學者，所以我不確定任何密鑰是否可以以零結尾。也請澄清一下。
如果任何鍵最後有 NULL 字節（或零），解包如何知道添加了多少填充字節？
PKCS#11 不會取消填充，除非您使用
_PAD. 解密只會留下所有零字節。如果您事先知道大小，或者如果您使用與零填充兼容的方案（例如 PKCS#7 兼容填充）自己填充它，這不是問題。畢竟，如果輸入已經是塊大小的倍數，則 PKCS#11 的零填充操作不會填充。另外，我是密碼學的初學者，所以我不確定任何密鑰是否可以以零結尾。也請澄清一下。
可以，但是如果您解包，則通常預先知道任何已打包密鑰的密鑰大小，因此沒關係。在展開過程中，您必須自己在模板中提供密鑰大小（如果您使用 ECB 或 CBC 而沒有
_PAD選項）。引用PKCS#11 v2.40 的機制頁面中的資訊，第 2.8.5 節 AES-CBC：對於包裝，該機制對被包裝的密鑰的 CKA_VALUE 屬性的值進行加密，並在尾端填充最多塊大小減去一個空字節，以便生成的長度是塊大小的倍數。輸出數據與填充的輸入數據長度相同。它不包裝密鑰類型、密鑰長度或任何其他有關密鑰的資訊；應用程序必須單獨傳達這些資訊。
對於解包，該機制解密包裝的密鑰，並根據模板的 CKA_KEY_TYPE 屬性截斷結果，如果有，並且密鑰類型支持它，則模板的CKA_VALUE_LEN屬性。該機制將結果作為新密鑰的 CKA_VALUE 屬性提供；密鑰類型所需的其他屬性必須在模板中指定。
（強調我的）
私鑰通常使用 ASN.1/DER 編碼，因此如果您包裝它們，您可以使用初始 TLV 值的第一個長度欄位來計算密鑰的大小。然後你 - 或令牌 - 可以刪除虛假的零值字節。
通常我會避免包裝 AES-192 密鑰，它們只是一個麻煩，因為密鑰大小不是塊大小的倍數。
此外，當涉及到（非對稱）私鑰時，我會非常謹慎。許多代幣會很樂意使用 ECB 或零 IV CBC 來加密私鑰，而這實際上可能會洩露有關這些封裝私鑰的資訊。
PKCS#11 是一個舊標準，許多一開始做出的粗心決定很可能會延續到很遠的未來。