Re: [pkcs11] Groups - Slides: PKCS #11 AEAD Functions at 2014-02-28 F2F uploaded

[Wan-Teh Chang <wtc@google.com>]

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.

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.

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
avoid.

Wan-Teh