On Thu, 2018-01-04 at 14:02 +0100, Niels Möller wrote: > Nikos Mavrogiannopoulos <[email protected]> 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 _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
