On Thu, Jan 4, 2018 at 2:57 AM, Dmitry Eremin-Solenikov dbaryshkov@gmail.com wrote:
2018-01-03 12:44 GMT+03:00 Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com:
On Sat, Oct 7, 2017 at 8:55 PM, Dmitry Eremin-Solenikov dbaryshkov@gmail.com wrote:
Add CFB mode support. CFB uses segment size = block size.
Changes since V2:
- Dropped CFB8, isn't widely used.
I'm getting late into this discussion, but it seems that samba (which uses nettle and gnutls), could benefit from an 8-bit CFB mode as well. They are already implementing it on top of nettle, and it is being used on the newer samba versions:
https://git.samba.org/?p=samba.git;a=blob;f=lib/crypto/REQUIREMENTS;h=351c2b...
Hmm, interesting. It looks like they miss CFB8 and CMAC. However from the first glance I could not understand, do they reference nettle/ GNUTLS as code reference, or are they using them as crypto backends? Skimming over WAF scripts did not give me the answer.
They are used as backends, though they also re-implement quite few stuff. My understanding is that they would like to get rid of their crypto implementations, and rely on nettle and gnutls for that.
I can (re-)post CFB8 if that will be helpful to Samba (or other parties). CMAC also sounds like and interesting topic.
Niels what do think about CFB8?
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).
regards, Nikos
[0]. https://github.com/qemu/qemu/blob/507e4ddc3abf67391bcbc9624fd60b969c159b78/c... [1]. https://github.com/samba-team/samba/blob/d8a5565ae647352d11d622bd4e73ff45686...
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
On Thu, Jan 4, 2018 at 2:02 PM, Niels Möller nisse@lysator.liu.se wrote:
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.
(I'll need some time to check about the other questions)
I'd stay away from OCB. libgcrypt had to amend their license for that: https://github.com/gpg/libgcrypt/blob/master/LICENSES
regards, Nikos
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
I'd stay away from OCB. libgcrypt had to amend their license for that: https://github.com/gpg/libgcrypt/blob/master/LICENSES
I see. I thought their "open source" patent license might be good enough, but probably not (for one, it doesn't cover proprietary applications using nettle, which collides with LGPL terms, and, possibly less important, it doesn't cover derived works which are hardware rather than software). Latest of the mentioned patents (8321675) seems to be applied for in 2011, so I guess it won't expire for quite some time.
So I agree we can't use it without some possibly painful legal work.
Regards, /Niels
Hello,
2018-01-04 16:02 GMT+03:00 Niels Möller nisse@lysator.liu.se:
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.
Well, it's not for free. This will require an additional CFB parameter (chunk size). Also code will be much more complicate. I'd prefer to have separate cfb8_* functions. They are simple and clean enough.
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).
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
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
nettle-bugs@lists.lysator.liu.se
-
Dmitry Eremin-Solenikov -
Nikos Mavrogiannopoulos -
Nikos Mavrogiannopoulos -
nisse＠lysator.liu.se