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: Re: [pkcs11] Preliminary draft proposal of PKCS #11 AEAD API


-------- Original Message --------
Subject: Re: [pkcs11] Preliminary draft proposal of PKCS #11 AEAD API
Date: Thu, 02 Jan 2014 14:04:20 -0500
From: Michael StJohns <msj@nthpermutation.com>
To: pkcs11@lists.oasis-open.org

Sorry for the delay on commenting on this - I just found it sitting in my junk mail folder.

I'm going to top post for a bit - this first part is about general models.

The current generic encrypt/decrypt functions bound their lifetimes on a complete cryptographic message.  For things like CFB8 the complete message goes from the beginning of the conversation to the end.  (The init function is called when the conversation begins, an update is called for each group of characters (or for a single character in some cases, and the final function is called when the conversation ends).   So the model here is Init -> [Update]* -> Final

For typical network packet encryption using something like CBC, the cryptographic message is co-incident with the network PDU.  So the Init/Update/Final cycle begins and ends with the processing of a single PDU.   Each PDU is encrypted under a key common to the connection or association wrapping the message, but each PDU has a distinct and separate IV used in the Init call. And each IV is generated deterministically (e.g. the message sequence number, a counter based value) or randomly.  The recipient also needs a copy of the IV and that's provided either explicitly (e.g. in the PDU), or derived by convention (e.g. from the sequence number).  The model here is [Init -> ( [Update]* -> Final) | Encrypt ]*   e.g. many independent calls to the Init/Update/Final or Init/Encrypt cycles.

Lately, for counter based stream-XOR encryption (not specifically AEADs - they're an intersection) there's a desire to provide an IV generator inside the crypto boundary.  That's due to the fact that if you repeat the IV for an XOR based mode, you duplicate the cipher stream and using the same cipher stream for multiple messages is A BAD THING as we all know.

 The IV generator would be initialized at the beginning of the conversation (e.g. when a TLS session opens, when an IPSEC association is negotiated) and the IV generator would be consulted to get a per-message IV.

WanTeh's proposal does that, but at some confusion between the two above models.

Basically, to use this API you call EncryptInit at the beginning of the conversation (at TLS session open), and you call Encrypt for each message within the conversation.  At the end of the session you call EncryptFinal to close the conversation.  So the model here is Init -> [Encrypt]* -> Final.  

In that model the [Encrypt] above is actually equivalent to the combination of two base functions C_EncryptInit -> C_Encrypt where a new IV is provided for each C_EncryptInit call.   This is a bit confusing as now Final can follow Encrypt.

So my issues with the proposal:

Naming conventions - the IV generator issue isn't specific to AEAD algorithms, and not even specific to counter based algorithms and it would be nice if we could make a fix work for both. (e.g. don't use AEAD in the name)

Naming conventions - The conventions aren't clear enough to differentiate between the per-message state model of the current API and the new per-association state model described here.  (e.g. use instead InitEncryptAssociation, ProcessMessage, ClearEncryptAssociation)

State overloading - a session can have at most one encryption function and at most one integrity function running at the same time.  That means there will need to be separate sessions for inbound (decrypt) and outbound (encrypt) traffic and that may be confusing.  [Since the init/final goes across multiple messages, then the inbound and outbound states for a connection will have to be active simultaneously and they currently can't be in the same session.  This could be changed, but seems to be a pretty big and unnecessary architectural change. ]  (e.g. don't use a session object for the association state - use a different object that contains the session, the IV generator and the mechanism to be used - low level code just does a C_EncryptInit call using that data for each call to C_EncryptMessage)

Conflating security requirements with api requirements - The comment about not wanting to support multi-part encryption/decryption for a single message due to the requirement to not let decrypted traffic loose before verification is understood, but for example doesn't apply to a non-AEAD mechanism like CTR which has exactly the same IV generation requirements as CCM and GCM.  (E.g. define the API, but let the mechanisms restrict the use of multi-part - e.g. BeginMessage,UpdateMessage,EndMessage, ProcessMessage).


On 12/19/2013 8:57 PM, Wan-Teh Chang wrote:

The attached file is a preliminary draft of proposed PKCS #11 AEAD
functions, based on my meeting with Bob Relyea this Monday.

It adds six new functions for performing authenticated encryption and
* C_AEADEncryptInit
* C_AEADEncrypt
* C_AEADEncryptFinal
* C_AEADDecryptInit
* C_AEADDecrypt
* C_AEADDecryptFinal

Between the Init and Final calls, C_AEADEncrypt or C_AEADDecrypt can
be called repeatedly to encrypt or decrypt multiple messages using the
same key.

Only single-part operations are supported. Bob Relyea and I are
opposed to authenticated decryption functions that output
unauthenticated plaintext. Multi-part authenticated decryption
functions need to output unauthenticated plaintext unless the crypto
module buffers it internally.

I specified the CKM_AEAD_AES_GCM mechanism and its parameters as an
example. I also specified two mechanisms for a crypto module to
generate the GCM nonces during authenticated encryption, a la NIST
SP-800-38D Sec. 8.2.

Wan-Teh Chang

To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:

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