Re: [pkcs11] stackoverflow question: CKA_VALUE_LEN attribute and Unwrap key

[Robert Relyea <rrelyea@REDHAT.COM>]

On 11/9/20 11:38 AM, Daniel Minder wrote:

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?

    In that case you need the CKA_VALUE_LEN. If you wrap it unpadded,
    you kinda have to include the key length somewhere else (AES isn't
    the only keys that would have this issue, we had this when you des
    wrapped a key that could be 40 bits, or 56 bits, or 64 bits).

Â

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.

    The requirement is based on the wrapping mechanism. If you wrap the
    key with CKM_RSA_PKCS or CKM_AES_CBC_PAD then you wouldn't need the
    CKA_VALUE_LEN. It's only the unpadded mechanism you need it with.

Â

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.

I think we can talk about it that. It's at least a good idea to mark the as "not best practice":) at least.

(Maybe the one exception of AES_KEY_WRAP, which was designed to wrap AES keys without 'padding' (the whole half-block thing makes a wrapped 192 bit key 192 bits long;). Still you wouldn't want to wrap some other key that required padding with CKM_AES_KEY_WRAP.

bob

bob

Â

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.