Dmitry Eremin-Solenikov dbaryshkov@gmail.com writes:
2018-01-04 16:02 GMT+03:00 Niels Möller nisse@lysator.liu.se:
All needed, if I remember the earlier discussion, is to add the appopriate iv update to the
if (left > 0) { .... }
blocks at the end of these functions. This has the advantage that we get support for CFBn for any 0 < n < block size, more or less for free.
Well, it's not for free. This will require an additional CFB parameter (chunk size).
I was thinking that to use CFB8, one could process only a single byte per call. On the theory that anyone using CFB8 either wants to process one byte at a time anyway, or isn't caring much about performance.
I.e., when calling cfb_encrypt(..., block_size, iv, length, dst, src), length < block_size implies chunk_size == length. While length >= block_size implies chunk_size == block_size, except that the final chunk might be shorter (which is non-standard, but in real use, if I understood you correctly).
Then the proper iv update for a short chunk is the only thing missing in the implementation.
What's samba's usecase for CFB8? As far as I understand, CFB8 (or small-symbol CFB in general) makes sense only when one needs to encrypt and transmit each byte before the next cleartext byte becomes available.
Not really. It's just another 'strange' block mode. Compare it to CFB1, where each bit requires new block encipherment (and IV update).
Can anyone explain why samba needs that? Is it required for compatibility with some microsoft protocols? If one doesn't really need to transmit one or a few bytes at time, choosing CFB8 rather than CFB16 implies a 16 time loss in performance, and I see no benefit at all. Why??? I could be missing something, of course.
Regards, /Niels