On Wed, 2008-01-16 at 19:10 -0500, Kevin Coffman wrote: > On Jan 16, 2008 6:24 PM, Joy Latten <latten@xxxxxxxxxxxxxx> wrote: > > On Wed, 2008-01-16 at 16:51 -0500, Kevin Coffman wrote: > > > On Jan 16, 2008 4:13 PM, Joy Latten <latten@xxxxxxxxxxxxxx> wrote: > > > > On Tue, 2008-01-15 at 15:28 -0500, Kevin Coffman wrote: > > > > > Hello, > > > > > I need to implement AES with CTS mode for NFSv4 (rfc3962 & rfc4121). > > > > > > > > > > I have implemented CTS starting with a copy of CBC (crypto/cbc.c), > > > > > since CTS is the same as CBC except for the last two blocks. > > > > > > > > > > > > > I am not sure I understand, but couldn't you use the CTS in cryptoapi? > > > > > > > > regards, > > > > Joy > > > > > > Thanks for the reply! It may be me that doesn't understand. I'm > > > currently stuck at 2.6.24-rc3. I do see messages about CTR mode being > > > added -- which I think is different than CTS? > > > > > > If CTS is already available, please give me more details of where to > > > find it and ignore the rest of this rambling! > > > > Geez I really jumbled up my acronyms! You were talking about CTS, not > > CTR. :-) > > > > > To (hopefully) better explain my problem, because of data placement > > > and alignment issues, we currently call crypto_blkcipher_encrypt_iv() > > > multiple times for a single RPC request (i.e. a large data write). > > > This works fine with CBC mode (used by DES and 3DES) since there is no > > > difference in how any of the blocks are treated, as long as the IV is > > > carried forward correctly. > > > > > > When trying to do the same for AES with CTS, each trip into > > > crypto_blkcipher_encrypt_iv() treats the last two blocks of that > > > "chunk" differently. So what I think I need is a way to tell the code > > > up front that I'm going to be calling it several times and not to do > > > the CTS trick until the last "chunk" containing the last two blocks. > > > (That is simplifying it a bit, since the last chunk may not be two > > > blocks long... Also, the last block may not be a complete block.) > > > > > Ah, I understand. > > I am definitely not an expert, so I don't know how acceptable my > > suggestion is, but perhaps arranging CTS such that there is > > a function that only does the CBC part and a function that does the > > "CTS trick". Then your "encrypt" function can appropriately call both > > the CBC part and "CTS trick" part. That way, other routines that want > > to encrypt all in one call can do so. And your NFS code, could call > > the CBC and "CTS trick" parts directly as needed. I haven't fully > > thought this through, so I could be missing something... > > > > regards, > > Joy > > Thanks for your suggestion. We discussed a similar strategy here today. > > For the rpcsecgss code, we need to handle several encryption > algorithms for Kerberos; and currently have generic code to handle > encrypting/decrypting an xdr_buffer. If possible, I'd like to avoid > adding special code there to handle cts(aes) differently. I'd prefer > to hide those details as much as possible within the crypto code. I > do understand that this may not be possible... > Ok, I have another suggestion. :-) You can add parameters to your calls, for example, cts(aes,?). Perhaps you can add a parameter to indicate something... I am shooting at the wind here, but for example, cts(aes,0) would mean do regular cts... and cts(aes,4) could mean do the "tricky" thing after 4 chunks or whatever... just another idea. :-) regards, Joy - To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
