On Mon, Sep 29, 2008 at 6:50 PM, Kevin Coffman <kwc@xxxxxxxxxxxxxx> wrote: > On Mon, Sep 29, 2008 at 6:18 PM, Russ Dill <russ.dill@xxxxxxxxx> 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. -- 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
