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

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

On Sun, Mar 23, 2014 at 7:08 PM, Michael StJohns <msj@nthpermutation.com> wrote:
>
> 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. [...]
> the goal of the message based encryption functions is to eliminate
> multiple round-trip calls.  All else is implementation details and
> efficiency tweaks.

Thanks for the clarification. Now I fully understand your goals. I
adopted the terms you used such as "association" and "message-based
encryption" in the hope that function naming won't distract us from
substantive issues. I now realize this can backfire if I misuse a
term.

I have an additional goal for the message-based encryption functions:
the first function in message-based encryption should be able to
perform any setup that is common to the encryption of multiple
messages. In this model, the first function does more than creating a
container for the key and mechanism data.

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

Thank you for your feedback. When designing the functions, I aim for
simplicity, security, and consistency with current PKCS #11 style. I
believe the current proposal is flexible enough to accommodate new
algorithms and modes of operations.

Wan-Teh Chang