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

[Michael StJohns <msj@nthpermutation.com>]

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

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.




> Wan-Teh