OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [pkcs11] Groups - GMAC corrections and enhancements uploaded

Hey Daniel,


Apparently the PKCS#11 v2.30 spec described the GCM IV as being 1 – 2^56, I’m wondering if a similar problem with the 2^(8L) in CCM which resulted in it being 1 – 256.


Still doesn’t explain to be why it’s 2^56 and not 2^64 – 1, but makes it seem at least in a reasonable range.




From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Gascon David
Sent: April-26-17 10:45 AM
To: Daniel.Minder@utimaco.com; pkcs11@lists.oasis-open.org
Subject: RE: [pkcs11] Groups - GMAC corrections and enhancements uploaded


Hey Daniel,


It’s a good question as to why we would restrict the IV length here, that would pre-date my involvement with the standard.  Does anyone else know why that was originally chosen?


As for the ulTagBits I think it’s reasonable for us to be more flexible than NIST, and it would be up to the implementer seeking a FIPS certification to ensure they are restricting tag lengths properly.


It does sound like the CCM section has an editorial problem, 2^(8L) makes sense.  I can address that in the next revision.


When it comes to internally generated IVs I know Bob R’s specification for CK_GCM_AEAD_PARAMS will allow the user to specify internally generated IVs, maybe it makes sense to tighten up the description for CK_GCM_PARAMS and never allow a NULL/0 length IV.


Good catch on the duplicate sections, I’ll correct that in the next revision.


Thank you,



From: Daniel Minder [mailto:Daniel.Minder@utimaco.com]
Sent: April-25-17 1:22 PM
To: Gascon David <david.gascon@gemalto.com>; pkcs11@lists.oasis-open.org
Subject: RE: [pkcs11] Groups - GMAC corrections and enhancements uploaded




While I support the changes in the AES-GMAC section, Im wondering about the other and I have spotted some more problems.


There was an inconsistence between CK_GCM_PARAMS and CK_GMAC_PARAMS in the ulIvLen that you have corrected. But why are we so restrictive now and allow only 16 bytes IV max? NIST SP800-38D allows 2^64-1 bytes max for an IV. Ok, it also says it is recommended that implementations restrict support to the length of 96 bits, to promote interoperability, efficiency, and simplicity of design. But why are we so much stricter than NIST here?


At other places, the PKCS#11 standard is less strict than NIST: ulTagBits "can be any value between 0 and 128". According to NIST (ulTagBits is called t here), "t may be any one of the following five values: 128, 120, 112, 104, or 96. For certain applications, t may be 64 or 32".


For CK_CCM_PARAMS, there are also some differences to NIST SP800-38C:

-  The data length's length L is in the range 2 <= L <= 8

- 0 <= ulDataLen < 2^(8L). This is an editorial issue: the ^(..) got probably lost, becoming 28L.

- If L is corrected as above, ulNonceLen <= 15-L is correct again. NIST says more explicitly: 7 <= ulNonceLen <= 13


The description of AES-GCM (section 1.2) is inconsistent to it parameter description (section 1.2.2). The latter specifies that ulIvLen must be at least 1 while the former allows an ulIvLen of 0. With current encryption/decryption function, there is no possibility to return an internally generated IV. (I recognize that some vendors have added this possibility, but this is outside of the standard and should not be supported by CKM_AES_GCM). For decryption, pIV==NULL or ulIvLen==0 does not make sense at all since it cannot be generated internally here.


Section 1.2.3 is actually the same as 1.2 and 1.2.4 the same as 1.2.1. Thus 1.2.3 and 1.2.4 can be removed.


I also suggest to decrease the level of the current header for section 1.2, making it section 1.1.2.





From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of David Gascon
Sent: Freitag, 21. April 2017 17:10
To: pkcs11@lists.oasis-open.org
Subject: [pkcs11] Groups - GMAC corrections and enhancements uploaded


Document Name: GMAC corrections and enhancements

This document contains corrections for GCM/GMAC:
- Changed ulIvLen from 1- 256 bytes to 1 - 16
- Changed references in the GMAC section of HMAC to GMAC
- Added CK_GMAC_PARAMS to allow users to specify IV and tag length
- Moved GMAC section to below GCM and CCM encryption sections
Download Latest Revision
Public Download Link

Submitter: Mr. David Gascon
Folder: Documents
Date submitted: 2017-04-21 08:09:23



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: Malte Pollmann (Chairman) CEO, Dr. Frank J. Nellissen CFO

This communication is confidential. We only send and receive email on the basis of the terms set out at https://www.utimaco.com/en/e-mail-disclaimer/

This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]