Dmitry Eremin-Solenikov dbaryshkov@gmail.com writes:
Hmm. I've never encountered things like CFB24 in wild. Just CFB1 (1-bit nightmare), CFB8 and CFB64/128 (depending on block size). Moreover it does not seem logical to merge everything into the same cfb_encrypt/cfb_decrypt pair. Such merge would allow one to easily intermix different segment lengths within one stream (and such usage contradicts the standard).
Hmm, I'd have to read up a bit more to have a solid opinion.
What about message sizes which aren't a multiple of the block size? As I understood your code, it would be possible to call cfb_encrypt with an input lenght of, e.g., 19 octets, which would be processed as one CFB128 segment and one CFB24 segment. Which is a mix of different segment lengths. That's why it seemed natural to me to generalize to any mix of segment lengths. Am I missing something?
I wonder what the openpgp usecase is. If there's no obvious need for message sizes which are not a multiple of the block size, I'd also be happy to go in the other direction and require full blocks, and hence *only* do CFB128 (or whatever the block size is). We could then extend the functionality later, if/when we have figured out what's useful.
According to the standard, data stream uses one segment length for the whole stream.
I'll have to read more carefully, at my first look, it seemed well defined how to take as input an iv, a keyed cipher, and a segment of arbitrary size (<= block size), and produce an ciphertext of the same size and an updated iv. With all history in the iv, without any other dependency on the sizes of previous segments.
Regards, /Niels