On Thu, 2018-01-04 at 14:02 +0100, Niels Möller wrote:
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) { .... }
Do you think we need this generality? The CFB mode is a legacy mode, and the only existing uses in software are cfb8 or cfb with block size. NIST SP800-38a defines CFB1, CFB8 and CFB128, so even such a generalized mode wouldn't cope with CFB1 (and it shouldn't as CFB1 looks like something defined for compatibility with old hw).
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.
It's for the netlogon protocol as far as I understand. They use CFB8 to encrypt arbitrary data, as if it was with a stream cipher. I can only speculate why CFB8 was chosen, but I guess it was selected as a way to convert a block cipher to a stream and avoid thinking about padding.
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?
Right.
For the AES-CMAC, there doesn't seem to be a generic MAC interface in nettle, but even if it was, it is a straightforward MAC with setkey(), update() and digest().
AES-SIV-CMAC is an AEAD cipher so I guess an interface like ccm_encrypt_message() and ccm_decrypt_message() would be sufficient.
XTS looks like something along CBC api-wise. It will require the storage of two cipher states, but nothing special.
regards, Nikos