Fwd: Re: [pkcs11] Preliminary draft proposal of PKCS #11 AEAD API

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

Mike

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

pkcs11 message