[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: Subject: Issues in specification of AES-XTS mechanism (2.8.11 AES-XTS)
For our PKCS 11 TC call this week --comment from the v2.40 public review. Regards, Bob -----Original Message----- From: pkcs11-comment@lists.oasis-open.org [mailto:pkcs11-comment@lists.oasis-open.org] On Behalf Of Marko Nippula Sent: Freitag, 30. Mai 2014 22:37 To: pkcs11-comment@lists.oasis-open.org Subject: [pkcs11-comment] Subject: Issues in specification of AES-XTS mechanism (2.8.11 AES-XTS) Hi, Thank you for providing PKCS#11 v2.40 (draft 2) for public review. This new version of the standard contains many new cryptographic algorithms, which have become important since the last published PKCS #11 standard, and would be very nice to have those available in PKCS #11 implementations via standardized mechanisms. One of these is AES-XTS. However, there are several issues on specification of mechanism for AES-XTS. First of all, NIST SP 800-38E calls the mode and cipher XTS-AES, rather than AES-XTS. Maybe PKCS #11 specification should also use XTS-AES. The section 2.8.11 AES-XTS says these conflicting things: * "It does not have a parameter." * "Its single parameter is a Data Unit Sequence Number 8 bytes long." XTS mode needs a parameter. So please, remove "It does not have a parameter." Furthermore, the XTS mode actually accepts 128-bit "tweak" value, therefore 8 bytes Data Unit Sequence Number is not able to cover all possible uses of XTS algorithm. I recommend the mechanism interface to have a capability to specify the full 128-bit (i.e. 16-byte) value instead, or in-addition to, 8 bytes long Data Unit Sequence Number. The Section 2.8.11 also states: "Supported key lengths are 256 bits and 512 bits. Keys are internally split into half-length sub-keys of 128 and 256 bits respectively." The XTS mode uses such keys. This, however, conflicts with keys stored by key objects of type CKK_AES (16 bytes, 24 bytes, or 32 bytes). To satisfy these XTS-AES requirements for key, which differ e.g. from AES used in some basic block cipher mode of operation, these alternatives should be considered: A) XTS-AES can have a secret key type of its own, such as CKK_XTS_AES or CKK_AES_XTS. B) Use two CKK_AES PKCS #11 keys for the halves of the key. C_EncryptInit only allows passing one key to the operation, therefore the other key could be provided e.g. as a part of parameter. The XTS (XEX-based Tweaked CodeBook mode with CipherText Stealing) mode is based on ciphertext stealing. Ciphertext stealing allows any size at least one ciphertext block. Thus, Input length should be the same than 2.14.2 AES CTS: Any, >= block size (16 bytes), instead of Any. Greets, Marko Nippula Senior Software Architect www.insidesecure.com -- This publicly archived list offers a means to provide input to the OASIS PKCS 11 TC. In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting. Subscribe: pkcs11-comment-subscribe@lists.oasis-open.org Unsubscribe: pkcs11-comment-unsubscribe@lists.oasis-open.org List help: pkcs11-comment-help@lists.oasis-open.org List archive: http://lists.oasis-open.org/archives/pkcs11-comment/ Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf List Guidelines: http://www.oasis-open.org/maillists/guidelines.php Committee: http://www.oasis-open.org/committees/pkcs11 Join OASIS: http://www.oasis-open.org/join/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]