Dmitry Eremin-Solenikov dbaryshkov@gmail.com writes:
- support for shorter segments (then which segment lengths would you like to see?) Would s=b and s=8 bit be enough from your POV?
I may be missing something (I just had a quick look ot the cfb specs the other day), but I think your patch almost supports arbitrary segments. If cfb_encrypt is adjusted to allow a sequence of calls with arbitrary lengths, and have it work like:
1. Process complete blocks just as done in your patch (similar to CBC).
2. If there's a left over, process it by encrypting the IV, xor the message with a prefix of the encrypted block, and then shift the IV according to NIST SP800-38A.
I'm not sure of the case of a message of, say, 2 complete blocks + 3 left-over bytes, is according to any standard. Or a sequence of messages of varying sizes. (If I got it correctly, the standard is about a sequence of segments, all of the same size, with size in the range 1 <= size <= block size).
I think it's ok to have use of short segments require one call to cfb_encrypt per segment; then we don't need to invent any additional interfaces to, e.g, provide an input string of arbitrary length and have it be processed as single-byte segments. Since the main reason to use short segments is when you have to transmit a byte or two without being able to wait for more data to become available.
Test vectors for CFB8 (i.e., a sequence of 8-bit "segments") should give a reasonable testing of the shift logic, but it would be nice with tests of a few additional segment sizes too.
And then docs need to be clear on what's the supported ways to use cfb.
I'd also like to here about any other use cases for cfb, so that we can get the interface right and support what's important. I'm adding Clint Adams, who filed the debian wishlist bug (a few years ago).
Regards, /Niels