2017-10-03 18:32 GMT+03:00 Niels Möller nisse@lysator.liu.se:
Dmitry Eremin-Solenikov dbaryshkov@gmail.com writes:
Add support for CFB and CFB8 modes support. CFB uses segment size = block size, CFB8 uses 8-bit segments.
That wasn't quite what I meant. Assume we have a block size of 16 octets, or 128 bits, for simplicity. I don't think we need separate functions for CFB8 or other segment sizes; instead I think it would be nice if cfb_encrypt worked as follows:
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).
Call with length == 16:
Encrypt one "segment" of 16 octets, aka CFB128.
Call with length == 40:
Encrypt two segments of 16 octets each, and the left over as one segment of 8 octets, aka CFB64.
Call with length == 1:
Encrypt one segment of one octet, aka CFB8
Call with length == 3:
Encrypt one segment of three octets, aka CFB24.
...etc. Calls with different length, with the same context, can be mixed, each call will correspond to ceil(length / 16) segments, where the last segment may be smaller than 16.
According to the standard, data stream uses one segment length for the whole stream.
As far as I understand your code and the spec, I think your cfb_encrypt almost does this, all that's needed is to change the way the iv is updated for the left-over segment, and the NIST spec seemed reasonably clear on how it should be done. Do you think that makes sense?
Regards, /Niels
-- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.