2017-10-03 23:04 GMT+03:00 Niels Möller <[email protected]>: > Dmitry Eremin-Solenikov <[email protected]> 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. -- With best wishes Dmitry _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
