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] stackoverflow question: CKA_VALUE_LEN attribute and Unwrap key


Bob,

 

AES block size is 16 bytes / 128 bit. But a 192 bit AES key is not a multiple of this. So, it will be zero padded to 256 bit. How do you know after unwrapping if it was a 192 or a 256 bit key?

 

And since you agree that âCKM_RSA_X_509 requires some sort of padding for RSA to work, so the CKA_VALUE_LEN would be requiredâ this violates table 70 in curr mech.

 

If we think that mechanisms without padding are bad we should deprecate them in the standard for wrap/unwrap. If they are allowed the discussion is not theoretical.

 

Daniel

 

From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org> On Behalf Of Robert Relyea
Sent: Montag, 9. November 2020 17:38
To: pkcs11@lists.oasis-open.org
Subject: Re: [pkcs11] stackoverflow question: CKA_VALUE_LEN attribute and Unwrap key

 

On 11/9/20 2:39 AM, Daniel Minder wrote:

All,

à

maybe youÃââve seen this already, if not have a look: https://crypto.stackexchange.com/questions/86011/pkcs11-cka-value-len-attribute-and-unwrap-key

à

The inquirer seems to be right. If an AES key is wrapped with a mechanisms employing zero-padding (which is not only AES-ECB or CBC but also CKM_RSA_X_509 or BLOWFISH-CBC) the unwrapped key might contain zeros.

 

If it's indeterminate, then you need CKA_VALUE_LEN.

AES_ECB and AES_CBC block size are multiples of the key size, so if the key is unpadded, you know the length by the cipher text length (there is no padding). You don't remove the 'zeros'.

CKM_RSA_X_509 requires some sort of padding for RSA to work, so the CKA_VALUE_LEN would be required.

The question is how an implementation should proceed now: try to figure out if the AES key has 128, 192 or 256 bits by removing as many zeros as possible (from the end where padding took place during wrap) and rounding up to 128, 192, 256 bits again? Or requiring CKA_VALUE_LEN?

If the wrap type is unpadded, then the key is unpadded. This issue is mostly for key sizes that aren't integral mulitples of the block size.

This is mostly a theoretical discussion. You should be using padded wrapping mechanisms for keys in protocols or you make your protocol moot.

(NOTE: PKCS 7 padding is deterministic).

à

Requiring CKA_VALUE_LEN would violate footnote 6 in table 70. Maybe this footnote is just wrong here? There is no footnote with the meaning ÃâÅmust only be given if padding does not encode original length informationÃâÃâÂ

à

Regards,

Daniel

à

 



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: Stefan Auerbach (Chairman) CEO, Malte Pollmann CSO, Martin Stamm CFO

This communication is confidential. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. Please inform us immediately and destroy the email.

 




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: Stefan Auerbach (Chairman) CEO, Malte Pollmann CSO, Martin Stamm CFO

This communication is confidential. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. Please inform us immediately and destroy the email.


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