2017-09-24 15:48 GMT+03:00 Niels Möller <[email protected]>: > What use cases do you have? CFB has been requested earlier (see > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721187), motivated by > openpgp.
My primary usecase is PKCS7/PBES2 encryption with GOST28147 cipher in CFB mode. I will check how to add support for OpenPGP way. > If I've understod things correctly, one traditional usecase of CFB is > for encrypting messages smaller than the block size, one at a time (and > that's how CFB is defined in Handbook of Applied Cryptography). While > your implementation works similarly to the CTR implementation. Yes, I modelled CFB after CTR, as both of them are stream modes of operation. Should we also add CTR interface supporting stream of short messages? > Dmitry Eremin-Solenikov <[email protected]> writes: > >> --- /dev/null >> +++ b/cfb.c >> @@ -0,0 +1,176 @@ > [...] >> + if (length) >> + { >> + TMP_DECL(buffer, uint8_t, NETTLE_MAX_CIPHER_BLOCK_SIZE); >> + TMP_ALLOC(buffer, block_size); >> + >> + f(ctx, block_size, buffer, iv); >> + memxor3(dst, buffer, src, length); >> + memcpy(iv, dst, length); > > Is this intended only for the last block of a message, or more > generally? I don't quite understand the update of the iv; from HoAC it > seems the IV should be shifted, and I think NIST SP800-38A agrees? If > this can be supported without a lot of difficulty, that would be nice. > And we don't have to do it now, if it could be added later, if we can > arrange now that it's possible without redesigning of the itnerface. > >> --- a/nettle.texinfo >> +++ b/nettle.texinfo > [...] > >> +Cipher Feedback mode (@acronym{CFB}) being a close relative to both >> +@acronym{CBC} mode and @acronym{CTR} mode transforms block cipher into a >> +stream cipher. >> + >> +The message is divided into @code{n} blocks @code{M_1},@dots{} >> +@code{M_n}, where @code{M_n} is of size @code{m} which may be smaller >> +than the block size. Except for the last block, all the message blocks >> +must be of size equal to the cipher's block size. > > So a sequence of short messages isn't supported? Yes, as I wrote, this was modelled against CTR. > >> +@deftypefun {void} cbc_encrypt (const void *@var{ctx}, nettle_cipher_func >> *@var{f}, size_t @var{block_size}, uint8_t *@var{iv}, size_t @var{length}, >> uint8_t *@var{dst}, const uint8_t *@var{src}) >> +@deftypefunx {void} cbc_decrypt (const void *@var{ctx}, nettle_cipher_func >> *@var{f}, size_t @var{block_size}, uint8_t *@var{iv}, size_t @var{length}, >> uint8_t *@var{dst}, const uint8_t *@var{src}) >> + >> +Applies the encryption or decryption function @var{f} in @acronym{CBC} >> +mode. The final ciphertext block processed is copied into @var{iv} >> +before returning, so that a large message can be processed by a sequence of >> +calls to @code{cfb_encrypt}. Note that for @acronym{CFB} mode internally >> +uses encryption only function and hence @var{f} should always be the >> +encryption function for the underlying block cipher. > > Some copy-paste errors here, should be cfb, not cbc. Ugh, sorry. > >> --- /dev/null >> +++ b/testsuite/cfb-test.c > [...] >> +void >> +test_main(void) >> +{ >> + /* From NIST spec 800-38a on AES modes. >> + * >> + * F.3 CFB Example Vectors >> + * F.3.13 CFB128-AES128.Encrypt >> + */ > > Seems there are testvectors also for shorter messages, e.g., F.3.7, > CFB8. CFB8 is not for 'shorter messages', but for shorter segments of CFB. I targeted mode where s == b (in terms of 800-38a). So, to sum up, would you like the following to be implemented: - real stream-like API, where one can call encrypt/decrypt multiple times, not necessaryly starting/ending on segment boundary? This should probably together with updated CTR/GCM API, implementing possibility to store interim block state and continue xor'ing from the point we left - support for shorter segments (then which segment lengths would you like to see?) Would s=b and s=8 bit be enough from your POV? -- With best wishes Dmitry _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
