[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/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.
I'm thinking we needNot 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).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
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.
Every single message in this specific mode will have C_EncryptInit and either C_EncryptUpdate* plus C_EncryptFinal *OR* C_Encrypt called on it.
Where do you get that from? I read this (table 44) to say that the input to the mechanism between Init and Final (or the implicit final of C_Encrypt) has to be >= blocksize, not that every call to C_EncryptUpdate needs to be.You need to buffer up to a block at a time internally. There is no requirement that length>blocksize for each call to C_*Update.Actually, there is. The spec universally uses 'C_Encrypt' to mean both 'C_Encrypt' and 'C_EncryptUpdate'. That's been a long term source of confusion we should probably fix.I get that from the intent of the original spec. When the PKCS #11 spec was made initially, we specifically called out that when you Encrypt using DES, you needed to provide full blocks (which applies to both C_Encrypt and individual C_EncryptUpdate calls). I think somone edited the spec to change Encrypt to C_Encrypt, losing the fact that it also applied to C_EncryptUpdate().
If you look under the text for C_Encrypt in any of 2.20 on you find:
For some encryption mechanisms, the input plaintext data has certain length constraints (either because the mechanism can only encrypt relatively short pieces of plaintext, or because the mechanism’s input data must consist of an integral number of blocks). If these constraints are not satisfied, then C_Encrypt will fail with return codeCKR_DATA_LEN_RANGE.
Let me stress: *some* encryption mechanisms. The constraints to block size or per block processing are in the individual mode descriptions, not implicit in C_Encrypt or C_EncryptUpdate. For example, the stream modes like CFB or stream ciphers like RC4 can work a character at a time. And looking at most of the DES modes, the constraint you note above is not present.
I don't actually remember who authored this for 2.30, but I'm not sure you can say that with absolute certainty unless it was you or you have asked them. Regardless, the constraint there is for the total message, it does not constrain less than full block processing. That would need to be stated explicitly.When the author said that C_EncryptFinal() does not return anything, clearly the author was following the 'C_Encrypt size' line applies to each C_EncryptUpdate().
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]