OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Points about AEAD and Counter mode APIs - recap from today

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

- 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]