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.
A problem that I'm running into is that the NFS/RPC code needs to call
the crypt functions in chunks as we currently do for other encryption
types. However, I am not seeing a way to inform the crypto code of
the total length to be encrypted such that it can just do regular CBC
until the last two blocks (of the last chunk).
Am I missing something, or is there an example of this sort of thing
that I am missing? Any other suggestions?
Thanks,
K.C.
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
On Jan 16, 2008 4:13 PM, Joy Latten <[email protected]> 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!
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.)
Thanks!
K.C.
On Wed, 2008-01-16 at 15:13 -0600, Joy Latten 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?
>
Oops!! I was thinking of CTR!! My apologies for any confusion. :-)
Joy
On Wed, 2008-01-16 at 16:51 -0500, Kevin Coffman wrote:
> On Jan 16, 2008 4:13 PM, Joy Latten <[email protected]> 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
On Jan 16, 2008 6:24 PM, Joy Latten <[email protected]> wrote:
> On Wed, 2008-01-16 at 16:51 -0500, Kevin Coffman wrote:
> > On Jan 16, 2008 4:13 PM, Joy Latten <[email protected]> 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...
Thanks again,
K.C.
On Wed, 2008-01-16 at 19:10 -0500, Kevin Coffman wrote:
> On Jan 16, 2008 6:24 PM, Joy Latten <[email protected]> wrote:
> > On Wed, 2008-01-16 at 16:51 -0500, Kevin Coffman wrote:
> > > On Jan 16, 2008 4:13 PM, Joy Latten <[email protected]> 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
On Tue, Jan 15, 2008 at 08:28:15PM +0000, Kevin Coffman wrote:
> I need to implement AES with CTS mode for NFSv4 (rfc3962 & rfc4121).
I love new algorithm submissions :)
> 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 think you're going about this the hard way. CTS should be done as
a generic wrapper on top of any existing block mode of operations.
In other words, the final result should look like "cts(cbc(aes))".
That means you don't need to implement anything specific to CBC.
> A problem that I'm running into is that the NFS/RPC code needs to call
> the crypt functions in chunks as we currently do for other encryption
> types. However, I am not seeing a way to inform the crypto code of
> the total length to be encrypted such that it can just do regular CBC
> until the last two blocks (of the last chunk).
If you can put the entire plain text into one SG list then it would
be best. If not then just do as you described and feed whole blocks
to plain CBC until you reach the last two and give them to CTS.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Jan 16, 2008 11:44 PM, Herbert Xu <[email protected]> wrote:
> On Tue, Jan 15, 2008 at 08:28:15PM +0000, Kevin Coffman wrote:
> > I need to implement AES with CTS mode for NFSv4 (rfc3962 & rfc4121).
>
> I love new algorithm submissions :)
>
> > 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 think you're going about this the hard way. CTS should be done as
> a generic wrapper on top of any existing block mode of operations.
> In other words, the final result should look like "cts(cbc(aes))".
>
> That means you don't need to implement anything specific to CBC.
Thanks for the reply.
I'm obviously no expert. I hadn't realized that CTS could be used
with ECB as well. However, if I'm understanding
http://en.wikipedia.org/wiki/Ciphertext_stealing correctly, then
things are done differently for ecb vs. cbc, so a generic wrapper as
you are describing would have to have knowledge of the underlying
block mode?
> > A problem that I'm running into is that the NFS/RPC code needs to call
> > the crypt functions in chunks as we currently do for other encryption
> > types. However, I am not seeing a way to inform the crypto code of
> > the total length to be encrypted such that it can just do regular CBC
> > until the last two blocks (of the last chunk).
>
> If you can put the entire plain text into one SG list then it would
> be best. If not then just do as you described and feed whole blocks
> to plain CBC until you reach the last two and give them to CTS.
I'll attempt a single SG list again. My first attempt failed. Which
brings up a question:
My first attempt tried to create asymmetrical input and output SG
lists because I was avoiding moving and copying data to make them
symmetric. (What I mean by asymmetrical is that the input list may
have had 3 entries of length 40, 16, and 24 bytes, and the output list
consisted of 2 entries of 48 and 32 bytes. As you can see, this also
resulted in SG list entires that were not always an even multiple of
the block size.)
Is it
1) a requirement that the input and output lists be symmetrical (same
number of entries and matching lengths for input and output entries)
and
2) that each entry in the list deals with an even multiple of the block size?
Thanks,
K.C.
Kevin Coffman <[email protected]> wrote:
>
> I'm obviously no expert. I hadn't realized that CTS could be used
> with ECB as well. However, if I'm understanding
> http://en.wikipedia.org/wiki/Ciphertext_stealing correctly, then
> things are done differently for ecb vs. cbc, so a generic wrapper as
> you are describing would have to have knowledge of the underlying
> block mode?
Yes they are different due to the presence of the IV for CBC, however,
you can still implement it as one wrapper. However, that is not what's
important here. The important thing is that you should implement CTS
on top of "cbc(aes)", as opposed to just "aes". That way you can use
hardware acceleration which wouldn't be available if you were using
AES.
So I'm fine if you implement CTS such that it only works with CBC, but
please do it so that it runs on top of the existing CBC code.
> My first attempt tried to create asymmetrical input and output SG
> lists because I was avoiding moving and copying data to make them
> symmetric. (What I mean by asymmetrical is that the input list may
> have had 3 entries of length 40, 16, and 24 bytes, and the output list
> consisted of 2 entries of 48 and 32 bytes. As you can see, this also
> resulted in SG list entires that were not always an even multiple of
> the block size.)
That's OK. You can do whatever is easiest for NFS.
> Is it
> 1) a requirement that the input and output lists be symmetrical (same
> number of entries and matching lengths for input and output entries)
> and
No.
> 2) that each entry in the list deals with an even multiple of the block size?
No.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Jan 18, 2008 12:58 AM, Herbert Xu <[email protected]> wrote:
> Kevin Coffman <[email protected]> wrote:
> >
> > I'm obviously no expert. I hadn't realized that CTS could be used
> > with ECB as well. However, if I'm understanding
> > http://en.wikipedia.org/wiki/Ciphertext_stealing correctly, then
> > things are done differently for ecb vs. cbc, so a generic wrapper as
> > you are describing would have to have knowledge of the underlying
> > block mode?
>
> Yes they are different due to the presence of the IV for CBC, however,
> you can still implement it as one wrapper. However, that is not what's
> important here. The important thing is that you should implement CTS
> on top of "cbc(aes)", as opposed to just "aes". That way you can use
> hardware acceleration which wouldn't be available if you were using
> AES.
>
> So I'm fine if you implement CTS such that it only works with CBC, but
> please do it so that it runs on top of the existing CBC code.
>
> > My first attempt tried to create asymmetrical input and output SG
> > lists because I was avoiding moving and copying data to make them
> > symmetric. (What I mean by asymmetrical is that the input list may
> > have had 3 entries of length 40, 16, and 24 bytes, and the output list
> > consisted of 2 entries of 48 and 32 bytes. As you can see, this also
> > resulted in SG list entires that were not always an even multiple of
> > the block size.)
>
> That's OK. You can do whatever is easiest for NFS.
>
> > Is it
> > 1) a requirement that the input and output lists be symmetrical (same
> > number of entries and matching lengths for input and output entries)
> > and
>
> No.
>
> > 2) that each entry in the list deals with an even multiple of the block size?
>
> No.
>
> Cheers,
>
OK. Thanks very much. I'll see what I can get working.
K.C.