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 - Slides: PKCS #11 AEAD Functions at 2014-02-28 F2F uploaded

On 3/21/2014 6:52 PM, Wan-Teh Chang wrote:
On Sun, Mar 16, 2014 at 5:41 PM, Michael StJohns <msj@nthpermutation.com> wrote:
With respect to the proposal, I think a single pair of C_NewAssociation and
C_CloseAssociation API calls will work to cover all of encrypt, decrypt, sign
and verify rather than C_NewEncryptAssociation, C_NewSignAssociation etc....
If you think of the C_EncryptMessage and C_SignMessage as macros for
a C_EncryptInit/C_Encrypt which use data from the association, I can't
see any reason why you need a new association function per message type.
The documentation of C_SignEncryptUpdate and C_GetOperationState
suggests that a session may perform two cryptographic operations
simultaneously. Without indicating "Encrypt" vs. "Sign", it is not
clear which cryptographic operation in the session the new association
applies to.

An association doesn't start up any cryptographic operations - it's a container for the key and mechanism data. The EncryptMessage, SignMessage, DecryptMessage, VerifyMessage operations (and the Init/Update/Final equivalents) start up the appropriate cryptographic operations using the data from the NewAssociation call as macro inputs.

We can use the mechanism in the association to infer which
cryptographic operation the association applies to. This solution is
indirect but can be made to work. But there is another issue. When a
new association for AES is created, it is expected that the crypto
token will perform setup common to all subsequent message encryption
operations. Specifically, the round keys should be generated (the Key
Expansion step in FIPS 197). Depending on the implementation, the
round keys for encryption and decryption may be different. So we also
need the Encrypt vs. Decrypt bit, and we can't infer that from the
mechanism alone.

Implementation detail, not an API issue. In any event, the way I'd do this is to do any per-key per-operation-type (Encrypt/Decrypt/Sign/Verify etc) once and cache it as part of the association data and make that part of the mechanism implementation rather than a general API need. I wouldn't do it as part of the association set up though for the reasons you suggest. We still don't need to know encrypt vs decrypt or sign vs verify as part of the NewAssociation call.

Note: If a crypto token generates the round keys when creating a new
association for AES, we can't think of C_EncryptMessage as a macro for
a C_EncryptInit/C_Encrypt which use data from the association. The
repeated generation of the round keys in the C_EncryptInit calls is
exactly what the message-based encryption functions will help us

No - the goal of the message based encryption functions is to eliminate multiple round-trip calls. All else is implementation details and efficiency tweaks. Basically, it's not a great idea to focus on one algorithm to make arguments of this type. At last count there were over a dozen or so key types used for symmetric encryption - I have no idea how many of them (if any others at all) have such an implementation need.

If it hasn't been made clear before, most of my objections to your designs are related to my perception that you're building the API against a very limited set of algorithms and modes and not considering that the API has to be able to accommodate new algorithms and modes over probably a 10 year period.


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