[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 usedwidely (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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]