Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
Niels what do think about CFB8?
If there applications for it, it makes sense to add it. My main question is, should it be a separate set of functions, or should we make the reasonably straightforward extension to cfb_encrypt and cfb_decrypt so that passing length == 1 implies cfb8? 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.
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.
On that view, I've compiled a list of new modes which seem to be useful in other applications: AES-CMAC: fast MAC used in samba and there is a draft for NTP protocol. There is implementation in samba at [1]. AES-XTS: it is a mode used in disk volume encryption when no authentication is to be present (ntfs and luks can use it). It is implemented in qemu [0] which already has a nettle back-end. AES-SIV-CMAC: An AES AEAD mode which does not fail secrecy/catastrophically when a nonce is repeated. There is a draft for its use under NTP (draft-ietf-ntp-using-nts-for-ntp-10).
Do they fit well with current nettle interfaces?
I take it CMAC is related (but slightly different?) to the CBC-MAC used in CCM mode?
What about OCB (for which RFC 7253 may be the most appropriate spec)? As far as I'm aware, it's one of few AEAD modes which provides a significant performance advantage over doing MAC and encryption separately.
Regards, /Niels