pkcs11 — archive

[Robert Relyea]

On 05/01/2013 12:45 PM, Michael StJohns wrote: On 5/1/2013 2:13 PM, Robert Relyea wrote: On 04/30/2013 05:58 PM, Michael StJohns wrote: In repeated calls. This removed the worry about what the meaning of the output for the second C_DecryptUpdate() was (no new AAD, use the same AAD?) and how the internal IV changes. I don't quite understand this. The IV gets set when you do the init. You update the counter for each block and form a new counter block - but that's pretty straight forward. You encrypt that block to get the value you XOR with the cipher text - that's per block processing, and that state happens internal to the module. The idea here is that each C_EncryptUpdate()/DecryptUpdate() call maps to a complete AEAD block. The issue is there is a single Init call, so you can't supply a new IV and AAD without tweaking things. The advantage of this is if you have a stream of AEAD blocks using the same key, certain key schedule and GCM key precalculations can be cached across Update calls. This could be a win in TLS. On the balance, the new IV/AAD issue is probably a show stopper here. Oh - now I understand. That's not how it works. You have to call C_EncryptInit/C_DecryptInit for each complete AEAD message - generally once per packet. This is not a stream cipher where you get to call the Init once and then update for each portion of the communication. It is confusing because the IV and the per-block counter descriptions get confused for each other. 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. Basically the output of each EncryptUpdate(). I'm thinking we need If you're not in FIPS mode, you can output data (cipher text to plain or vice versa) after every complete block. And you may want to have this option if you don't support buffering of large amounts of data. If you're in FIPS mode you have to buffer the output of cipher text to plain (but not vice versa) until you verify the tag for the message. You can do this with C_DecryptInit/C_Decrypt or with C_DecryptInit/C_DecryptUpdate*/C_DecryptFinal. As I said above, this is a message cipher not a stream cipher so you have to re-initialize processing for each message. It's just the way it works. I corresponded with Russ. He suggested that we should support a double jumbogram - and I assume he means ethernet jumbograms. So that's about 18-20K of required buffering. ----- CCM --- We did not implement CCM. It would have the same issues. Longer term we may want a new function for IETF AEAD type functions ( see rfc 5166). In general, this is more about how much data can be/needs to be buffered inside the PKCS11 module than almost anything else. I think the restriction imposed by NIST for this is extreme, especially since the same key can be used with AES-ECB and a set of fabricated counter blocks to do the decryption, even if the CBC-MAC fails. ------ CTR --- There were no issues with CTR, the spec is pretty straighforward. ------ CTS --- Just for my ref - this is CBC with Cipher Text Stealing. Your other message on XTS is XEX based cipher text stealing This is CVS with Cipher Text Stealing. A few things. First: though it wasn't clear, the only thing that makes sense for the spec is that each C_EncryptUpate call returns CTS data. If you initially pass in less than or equal to a full block, then you get no output. If you pass in a single block at a time, you will always be one block behind. You have to be past (not at) a block boundary to get output. No, because the spec specifically says that no data is returned on final. Each C_EncryptUpdate call is a complete CTS 'block'. That is each call has be be at least on block long and the encrypted output is the same as the encrypted input. The 'stealing' happens on each Update call. That means that each C_EncryptUpdate/C_DecryptUpdate call must have a length > blocksize length. The spec does say that, but in a way that many interpret to mean only C_Encrypt/C_Decrypt (which conflicts with the explicit statement aht C_Finalize doesn't return anything). You mean C_EncryptFinal? The statement that there is no final part is actually wrong. You can't calculate the last partial partial block unless you know that you're at the end of the data. If you were processing an exact multiple of the block size the output is going to be the last block. Yes, The spec is correct for what it intended to specify. When I actually implemented this, I actually started implementing what you said, but then I read the input/output spec with the no data on final comment. It became clear CTS was supposed to happen on each update call. This is how CTS is actually used in real life (kerberos sends multiple CTS packets on the same stream with the same key). 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). 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. 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. 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(). 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(). Attachment: smime.p7s Description: S/MIME Cryptographic Signature