Re: [pkcs11] Points about AEAD and Counter mode APIs - recap from today

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

Hi Michael,

Thank you for your comments.

On Wed, Feb 5, 2014 at 2:55 PM, Michael StJohns <msj@nthpermutation.com> wrote:
> 1) Two issues:
>    - per-message IV generation for Counter-based mechanisms
>     - Support for AEAD input of AAD and input/output of integrity tag.
>
> 2) IV Generation
>     - not specific to AEAD
>     - Applies especially to counter mode based mechanisms (CCM, GCM, CTR)
>         as IV duplication is deadly.
>     - but there's a general requirement for "unpredictable" generation of
> IVs for
>       most mechanisms (e.g. could use for CBC and other modes that use IVs)
>     - CCM and GCM have *example* IV generation mechanisms that are used
>        widely (e.g. CCM appendix A), but the specifications do no restrict
> to those
>        mechanisms.
>         -- E.g. need approach that doesn't lock encryption mechanism to IV
>             generation mechanism. (Decomposition of functions).

This is supported by the new proposal I posted today
(pkcs11-encryption-v2-api.txt).

I defined a new AES-GCM mechanism:

#define CKM_AES_GCM_V2 0x00000700

that uses a new mechanism parameters structure:

typedef struct CK_GCM_PARAMS_V2 {
  CK_ULONG ulNonceLen;
  CK_ULONG ulTagLen;
  CK_MECHANISM_PTR pNonceMech;  /* For encryption:
                                 * - If NULL, the entire nonce is provided by
                                 *   the caller.
                                 * - If not NULL, specifies how the nonce is
                                 *   generated partially or fully by the crypto
                                 *   module.
                                 *
                                 * For decryption: must be NULL and the entire
                                 * nonce is provided by the caller. */
} CK_GCM_PARAMS_V2;

The pNonceMech field specifies the IV generation mechanism. So you can
use CKM_AES_GCM_V2 (an encryption algorithm) with any suitable IV
generation mechanism. I specified two IV generation mechanisms that
may be used with CKM_AES_GCM_V2:

#define CKM_GCM_NONCE_DETERMINISTIC   0x00000750
#define CKM_GCM_NONCE_RBG_BASED       0x00000751

and they each have their own mechanism parameters structures.

>     - IV generation state, unlike cryptographic message state, is persistent
> across
>         a "communication"
>     - Current C_Encrypt/Update/Final APIs designed for per-message
> cryptographic state
>        and NOT persistent inter-message state throughout a communication.
>     - Need new C_NewAssociation, C_CloseAssociation functions to wrap key,
> encryption
>       mechanism and IV generator object/mechanism (object because of
> persistence issues)

I know you suggested this before. This is the only suggestion of yours
that we didn't implement. We continue to associate the key, encryption
mechanism, and IV generator object (if created by a parameter of the
encryption mechanism such as the pNonceMech field of CK_GCM_PARAMS_V2)
with the session implicitly. The IV generator object (if created by
the encryption mechanism) persists across messages, until the new
C_EncryptV2Final function is called.

>     - Use new C_EncryptMessage or C_Encrypt/Update/Final/Message construct
> with
>       passed in association handle (vs current passed in session handle).
> Can be macro
>       for existing functions.

The new proposal has the new C_EncryptMessage or
C_Encrypt/Update/Final/Message functions. They are poorly named:
C_EncryptV2 for single-part mode and the { C_EncryptV2Begin,
C_EncryptV2Update, C_EncryptV2End } functions for multi-part mode. The
only difference that they use the implicit association in the session
rather than an explicit association handle.

> 3) AEAD
>     - Could use marshalled cryptostream  (which includes AAD and integrity
> tag) (e.g. mcgrews API),
>         - but not necessarily future proof.
>         - can require memory-memory copies (expensive and an issue for
> things like scatter/gather processing)
>         - depends on documents specific to TLS

(Although the only use case in my presentation is TLS, I also studied
how AES-GCM is used in IPsec: http://tools.ietf.org/html/rfc5282.)

This is all correct. I am going for simplicity of the API. The current
proposal allows us to use the same functions for AEAD and non-AEAD
mechanisms. Alternatively, we can add AEAD-specific functions that
have an integrity tag output argument, but one can also imagine that
the output of an AEAD algorithm may not have a cleanly separable
integrity tag.

Note: In the conference call today I asked if there is a protocol that
marshalls AES-GCM ciphertext in a different way from what David McGrew
specified. I just found one: http://tools.ietf.org/html/rfc5083. So a
memory-memory copy of a <= 16-byte integrity tag would be necessary
for AES-GCM for S/MIME. That seems acceptable.

>     - Better to use separate args for AAD and integrity tag

Although integrity tag is not a separate argument, AAD is a separate
argument in my proposal.

>     - Although NIST FIPS requires that decrypted data not be released unless
> integrity
>         tag verifies (CCM and GCM), this SHOULD NOT BE A RESTRICTION OF THE
> API as
>         other future AEAD functions may not have this restriction.
>         -- Provide Init/Update/Final to handle large messages, or even
> messages that
>            underlying implementation can't handle (e.g. size of internal
> buffer)
>         -- enforce release of decrypted data as a mechanism specific or mode
> (FIPS) specific
>            requirement

The new proposal supports this. Each mechanism independently specifies
whether it allows multi-part mode.

In summary, I believe that among your suggestions, only two are not
implemented by the new proposal:
- Introduce the notion of an association handle, as opposed to relying
on the single implicit association in a session.
- Use a separate output argument for integrity tag for AEAD.

Wan-Teh Chang