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: Re: [pkcs11] New Mechanisms subgroup Part 1 or 4 new in v2.3


On 5/2/2013 2:34 PM, Robert Relyea wrote:
On 05/02/2013 09:16 AM, Michael StJohns wrote:
On 5/1/2013 4:47 PM, Robert Relyea wrote:
On 05/01/2013 12:45 PM, Michael StJohns wrote:

On the other hand, I looked at this because of the per message IV uniqueness requirements and started wondering if perhaps we needed a C_EncryptSessionInit, etc - which wraps around the IV state stuff and manages that and under the covers does the C_EncryptInit/C_Encrypt or C_EncryptUpdate/Final stuff for each message and does the IV formation. The problem there is that while the Appendix A for CCM describes one method of forming the IV from a nonce and format block, it is possible to use other methods. I probably *wouldn't* build C_DecryptSessionInit since you have to process each packet with the IV it contains rather than a strict update of a previous IV.

yeah, I think the best idea here is to propose a C_EncryptWithParams() and C_DecryptWithParams() that can be used to handle full AEAD message packets. So you have:

C_EncryptInit()
C_EncryptWithParams() - one tls packet. (output of C_EncryptWithParams includes the Mac).
C_EncryptWithPrams() - next tls packet.
C_EncryptFinal().

These would be new function added post 2.40 so we don't have to deal with them now.

You're using "block" in a confusing manner. Let's keep that term as the cryptographic division for the block cipher - e.g. 16 bytes for AES. Use message or packet to represent the aggregation of the plaintext and AAD that you're actually processing between init and final (or the implicit final).

Right, I mean that a complete AEAD processing unit.
OK.
Basically the output of each EncryptUpdate().
But that's not a complete AEAD processing unit. It is a part of a single processing unit bounded between Init and Final. So you're still not getting it.

No, I get that you mean to interpret the single processing unit from Init to Final. I am saying it can be interpreted from each update call contains a complete processing unit.

No, it can't - seriously.
C_EncryptUpdate continues a multiple-part encryption operation,
"Continues", not "allows processing of a complete message".


I think the issue of not having a new IV and AAD for each update call probably makes my interpretation undesirable. It's unfortunate because having a single Init and Final means tokens can cache important key scheduling processing from actual AEAD streams, in which the same key is used to process multiple packets, but with different (usually serial) IV's and AAD's.

No. Seriously. No. The issue of having new IV and AAD makes your interpretation wrong. For an AEAD cipher, you pass in at Init the IV, and define which part of the data you're about to process is encrypted and which is just MAC'd. You then either call C_Encrypt or C_EncryptUpdate* and C_EncryptFinal. The *Final operation whether implicit in C_Encrypt or explicit in C_EncryptFinal is responsible for outputting the integrity tag.

In the padded non-AEAD ciphers, you may need to do pad processing for the last block (or more) - C_EncryptFinal tells the module you're done and to output anything else the module hasn't yet output - e.g. padded final block padding, etc.






I'm thinking we need

Actually, it's worse than this. You end up buffering the last full block and the last partial block, because you return only a part of the encryption for the next to last block if the last block is less than full. You don't know whether you have complete blocks until you call the DecryptFinal. That's at least the case for CBC-CS1-Encrypt
Not under the interpretation I had. If you treat the entire C_EncryptUpdate/C_DecryptUpdate as a complete CTS packet, there is no buffering. Your example of 40 bytes, if you want 40 bytes of CTS data you send 40 bytes to a single C_EncryptUpdate. If you break it up you will get a different encoding (smaller fully CTS encrypted blocks).

Your interpretation is wrong.

Each Init/Update*/Final or Init/Encrypt has its own IV and is padded only at the end. This mechanism may not be used in the manner you suggest. In particular, you MUST supply a new IV for each complete chunk of data to be encrypted (message or packet). You *can* (for CBC and CTS) reuse that IV, but its not recommended.
The new 'iv' is well known from the stream itself. Kerberos already does it exactly like I mentioned, and as implied by the current spec. It doesn't 'reuse' the initial IV in anyway It's still a 'stream', just packetized.
No. Not for PKCS11. The IV is an explicit argument provided in the mechanism info passed through C_EncryptInit.

And how would a cryptographic module know where to find and IV in a packet?????

So - No.

Multiple times no.




bob




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