[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: AEAD Strawman
Resending these.
-------- Original Message --------
The attached probably needs some discussion on why I took the approach. Give me a day to write a note to talk about the analysis. Per Bob - this is on the agenda for the Nov 13th meeting. |
This is a private draft to see if I understand what the issues are. My understanding is that you'd like a set of compound operations so that you don't have to keep doing the init/update/final operation. There's also the issue with dealing with IV generation for things like CCM and GCM. I think I got both of those. It may or may not be necessary to include the Begin/Update/End functions - but they're included here for completeness to support multi-part operations. Theory of operation for CCM - 1) Create an IV generator object 2) Create an encryption association using a key, the above generator object and the appropriate CCM mechanism (suitably modified to deal with the IV generator stuff). This is a call to C_CreateEncryptAssociation 3) Call C_EncryptMessage once for each message to be sent. Extract the IV from the call and process it appropriately (e.g. extract the right bits) for inclusion in the protocol message. Extract the integrity tag from the call and place it in the protocol message. 4) At the end, call C_DestroyAssociation to clean it all up. IV Generator Objects: CKO_IV_GENERATOR 1) Generated by C_GenerateKey - can't be directly instantiated 2) Always session objects, always read only, always non-sensitive 3) CKA_IV_GEN_TYPE attribute CK_ULONG 4) CKA_CURRENT_IV attribute CK_BYTE[] 5) CKA_NEXT_IV attribute CK_BYTE[] Needed types: multiple GCM types, the appendix A version of the CCM IV formatter, simple counter type (with optional prefix),LFSR for IPSEC (need ref from Housley), last block of previous message (for CTS). Others? Association State Objects: CKO_ASSOCIATION 1) Created by C_CreateEncryptAssociation or C_CreateDecryptAssociation (see below) 2) Has handles for key, mechanism and IV 2) Always a session object, always read-only, always sensitive, can't be copied or modified. 3) No sub type 4) Attributes for contained objects include the session, key mechanism and iv. Message encryption stuff (plus AEAD) CK_RV C_CreateEncryptAssocation (CK_SESSION_HANDLE hSession, CK_MECHANISM_PTR mech, CK_OBJECT_HANDLE hIvGenerator, CK_OBJECT_HANDLE key, CK_OBJECT_HANDLE_PTR phAssociation); CK_RV C_EncryptMessageBegin (CK_OBJECT_HANDLE hAssociation, CK_BYTE_PTR pIv, CK_ULONG_PTR pulIvLength); CK_RV C_EncryptMessageUpdate (CK_OBJECT_HANDLE hAssociation, CK_BOOLEAN bAADBeforeData, CK_BYTE_PTR pPart, CK_ULONG ulPartLen, CK_BYTE_PTR pEncryptedPart, CK_ULONG_PTR pulEncryptedLength, CK_BYTE_PTR pAAD, CK_ULONG ulAADLen); CK_RV C_EncryptMessageEnd (CK_OBJECT_HANDLE hAssociation, CK_BYTE_PTR pTag, CK_ULONG_PTR pulTagLen); CK_RV C_EncryptMessage (CK_OBJECT_HANDLE hAssociation, CK_BOOLEAN bAADBeforeData, CK_BYTE_PTR pIv, CK_ULONG_PTR pulIvLength, CK_BYTE_PTR pData, CK_ULONG ulDataLen, CK_BYTE_PTR pEncryptedPart, CK_ULONG_PTR pulEncryptedPartLen, CK_BYTE_PTR pAAD, CK_ULONG ulAADLen, CK_BYTE_PTR pIv, CK_ULON_PTR pulTagLen); CK_RV C_DeleteAssociation (CK_OBJECT_HANDLE hAssociation); /// Similar functions for decryption EncryptMessage is exactly equivalent to EncryptMessageBegin/1 or more EncryptMessageUpdate/EncryptMessageEnd. The IV can be provided either by IV generator, in which case pIv in EncryptMessage and EncryptMessageBegin are output parameters, or if no IV generator is provided for the call to C_CreateEncryptAssociation it must be provided as input to those two calls. The "MessageBegin" or the begin message phase of EncryptMessage grabs the next iv from the IV generator, updates the current IV to the next IV IV in the IV generator and generates a next IV, does the equivalent of calling a C_EncryptInit using the mechanism from the association object, the IV from the IV generator from the associaton object, and the key from the association object. The "MessageUpdate" or the equivalent phase of EncryptMessage processes the provided data with the establish encryption content (C_EncryptUdate) - and depending on the setting of the pAADBeforeData either passes the data to the integrity calculation before or after the AAD. The "MessageEnd" or the equivalent phase of EncryptMessage does nothing more than output the integrity tag and release the encryption context. C_DeleteAssociation deletes the underlying IV generator and does any other cleanup necessary to close out the association. (Not sure this is needed - maybe just two calls to C_DeleteObject for the IV generator and the association object.) I'm looking at the above to support both the AEAD and normal composite encrypt and protect stuff. E.g. I want to define a mechanism that allows the use of both an encrypt and MAC function. (E.g. get this to work with AES-CTS plus HMAC for example). Mike
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]