Points about AEAD and Counter mode APIs - recap from today

[Michael StJohns <msj@nthpermutation.com>]

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

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
    - Better to use separate args for AAD and integrity tag
    - 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


Mike