crypto/cts.c currently implements RFC 3962. It deviates from the basic
CTS algorithm in two ways. The first is that it does not support
encrypting data blocks smaller than the underlying block size. Reading
and writing past the end of buffers will occur if it is attempted.
Second, when the length of data to be encrypted is exactly one block,
it is encrypted with plain CBC.
Normally, when packets are of size less than or equal to the block
size, the algorithm uses the IV as the "previous block" and swaps bits
with that data instead.
What would be the best way to implement these slightly two different
behaviors? The primary difference between the two CTS methods seems to
be what to do when the input size is equal to the block size.
On Mon, Sep 29, 2008 at 6:18 PM, Russ Dill <[email protected]> wrote:
> crypto/cts.c currently implements RFC 3962. It deviates from the basic
> CTS algorithm in two ways. The first is that it does not support
> encrypting data blocks smaller than the underlying block size. Reading
> and writing past the end of buffers will occur if it is attempted.
>
> Second, when the length of data to be encrypted is exactly one block,
> it is encrypted with plain CBC.
>
> Normally, when packets are of size less than or equal to the block
> size, the algorithm uses the IV as the "previous block" and swaps bits
> with that data instead.
>
> What would be the best way to implement these slightly two different
> behaviors? The primary difference between the two CTS methods seems to
> be what to do when the input size is equal to the block size.
I'm not sure of the proper way to handle this. My code depending on
this has not made it upstream yet, so I would not be opposed to
renaming this implementation to cts-rfc3962 (or any other conventional
name). Assuming that noone else is already using this elsewhere.
Hopefully Herbert can give some experienced advice...
K.C.
p.s. I don't have a lot of time to devote to making changes myself right now...
On Mon, Sep 29, 2008 at 6:50 PM, Kevin Coffman <[email protected]> wrote:
> On Mon, Sep 29, 2008 at 6:18 PM, Russ Dill <[email protected]> wrote:
>> crypto/cts.c currently implements RFC 3962. It deviates from the basic
>> CTS algorithm in two ways. The first is that it does not support
>> encrypting data blocks smaller than the underlying block size. Reading
>> and writing past the end of buffers will occur if it is attempted.
>>
>> Second, when the length of data to be encrypted is exactly one block,
>> it is encrypted with plain CBC.
>>
>> Normally, when packets are of size less than or equal to the block
>> size, the algorithm uses the IV as the "previous block" and swaps bits
>> with that data instead.
>>
>> What would be the best way to implement these slightly two different
>> behaviors? The primary difference between the two CTS methods seems to
>> be what to do when the input size is equal to the block size.
>
> I'm not sure of the proper way to handle this. My code depending on
> this has not made it upstream yet, so I would not be opposed to
> renaming this implementation to cts-rfc3962 (or any other conventional
> name). Assuming that noone else is already using this elsewhere.
>
> Hopefully Herbert can give some experienced advice...
>
I worked with this a bit, and since the IV has to be modified, it was
just easier to check for nbytes less than or equal to block size in my
own code and then back up src/dest pointers by iv_size and increase
the size by iv_size. (My IV is prepended to my data). On decryption I
do something similar by adding a buffer for the output of the IV.
Russ Dill <[email protected]> wrote:
>
> I worked with this a bit, and since the IV has to be modified, it was
> just easier to check for nbytes less than or equal to block size in my
> own code and then back up src/dest pointers by iv_size and increase
> the size by iv_size. (My IV is prepended to my data). On decryption I
> do something similar by adding a buffer for the output of the IV.
I suggest that we fix the CTS algorithm (i.e., give it a block size
of 1 instead of whatever it is now, plus make it work properly for
input equal or less than a block), and then implement RFC3962 on
top of it.
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 Tue, Sep 30, 2008 at 7:33 AM, Herbert Xu <[email protected]> wrote:
> Russ Dill <[email protected]> wrote:
>>
>> I worked with this a bit, and since the IV has to be modified, it was
>> just easier to check for nbytes less than or equal to block size in my
>> own code and then back up src/dest pointers by iv_size and increase
>> the size by iv_size. (My IV is prepended to my data). On decryption I
>> do something similar by adding a buffer for the output of the IV.
>
> I suggest that we fix the CTS algorithm (i.e., give it a block size
> of 1 instead of whatever it is now, plus make it work properly for
> input equal or less than a block), and then implement RFC3962 on
> top of it.
>
I'm just not sure how to best fit that into an API. In the case of
number of bytes being greater than the underlying block size,
everything works "normally". But in the case of the number of bytes
being less than or equal to the block size, the IV sent to the remote
end needs to be modified.
On Tue, Sep 30, 2008 at 09:41:04AM -0700, Russ Dill wrote:
>
> I'm just not sure how to best fit that into an API. In the case of
> number of bytes being greater than the underlying block size,
> everything works "normally". But in the case of the number of bytes
> being less than or equal to the block size, the IV sent to the remote
> end needs to be modified.
I see. I think the easiest way right now is to use the givencrypt
interface. The only time you can modify the IV is when you are
able to send the IV to the other side, in which case givencrypt
should be a reasonable interface.
If the user calls you through encrypt then you just fail any
requests <= block_size.
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