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] AEAD - Breakout

I'm going to split this out separately..

On 3/12/2014 3:25 PM, Wan-Teh Chang wrote:
2. I am afraid that you misunderstood how the message authentication
tag T in draft-mcgrew-aead-aes-cbc-hmac-sha2 can be implemented:

     T = MAC(MAC_KEY, A || S || AL),

The octet string AL (the length in bits of the associated data A,
expressed as a big-endian 64-bit unsigned integer) depends on A only.
Therefore, the crypto token can generate AL itself and does not need
the caller to provide AL as an input. So this construct does not
require us to support an associated data suffix.

No, I didn't misunderstand this. I do understand that a specifically defined mechanism could do this.

My issue with this approach is that I think we're doing too many mechanisms that have things that are really specific to a specific protocol or approach. So we get mcgrew's aes/cbc/hmac approach and it could differ from an approach used for IPSEC, or an IOT protocol only whether or not the AL data is included in the integrity tag, or where the length is or whether the A preceeds or follows the S. (cf the difference between the X9.63 and SP800-56A KDF functions which differ only in the placement of

What I really want to do is try to define general composite functions:

E.g. for this an CKM_GENERIC_AEAD mechanism that passes in a mechanism info that specifies the encryption mode and the integrity mode and possibly a key expansion or KDF mode (in the mcgrew case, the derivation is a simple byte extraction from a master key to a mac and encryption key) and maybe a padding function. Mcgrew's draft defines 4 new mechanisms. But what about AES-CTS-HMAC.... or AES-XCBC-HMAC or GOST-..... By the time we're done we may be talking 30-40 new mechanism as this becomes the vogue. And each of those mechanisms requires an implementation change to the HSM to support it.

If we provide a generic way to combine cryptographic functions, the customers can do what they need to do without waiting for the PKCS11 group to get around to adding the new mechanisms, or worse, having 5 vendors have to implement these all as different vendor specific functions.

Instead, let's REALLY try for a generic solution, and that starts with the API. Given that desire, If I can't specify whether the A precedes or follows the S, or both, then I can pretty much say that the API will be broken at some point for some future functions.


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