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: Fwd: AEAD Strawman

Resending these.

-------- Original Message --------
Subject: AEAD Strawman
Date: Wed, 30 Oct 2013 16:31:17 -0400
From: Michael StJohns <msj@nthpermutation.com>
To: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org>

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

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

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



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