2017-10-03 23:04 GMT+03:00 Niels Möller nisse@lysator.liu.se:
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?
No, it is still CFB128, but with last segment being of partial size. SP800-38A supports that kind of operation (segments + partial one).
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.
As far as I understood, OpenPGP uses the segment size = block size case (cfb_encrypt/decrypt in my patch), but with a bit strange startup sequence.