Hello, What do you think of having OCB mode in nettle? I particularly like OCB due to it's simplicity and performance comparing to GCM/CCM, but was always patented. However in [0] there is license1 which states: "Under this license, you are authorized to make, use, and distribute open-source software implementations of OCB. This license terminates for you if you sue someone over their open-source software implementation of OCB claiming that you have a patent covering their implementation."
What do you think? Should the FSF be consulted on that?
regards, Nikos
On 06/20/2014 08:50 AM, Nikos Mavrogiannopoulos wrote:
What do you think of having OCB mode in nettle? I particularly like OCB due to it's simplicity and performance comparing to GCM/CCM,
I'd love to see OCB made available in nettle for these exact reasons.
What do you think? Should the FSF be consulted on that?
It seems reasonable to ask the FSF about it for a bigger-picture analysis, but it looks clear to me that nettle itself won't get into any trouble with Rogaway's patents over OCB.
--dkg
On Fri, Jun 20, 2014 at 6:59 PM, Daniel Kahn Gillmor dkg@fifthhorseman.net wrote:
What do you think of having OCB mode in nettle? I particularly like OCB due to it's simplicity and performance comparing to GCM/CCM,
I'd love to see OCB made available in nettle for these exact reasons.
To revive this discussion, it seems that there is a proposal to add OCB in TLS. https://tools.ietf.org/html/draft-zauner-tls-aes-ocb-00
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
To revive this discussion, it seems that there is a proposal to add OCB in TLS. https://tools.ietf.org/html/draft-zauner-tls-aes-ocb-00
I guess we need to get into release mode soon (I'll send another message to try to sort out loose ends), but it might be possible to to ocb. I've had a quick look at RFC7253. According to wikipedia (https://en.wikipedia.org/wiki/OCB_mode), that is "OCB2", is that the relevant version?
Has the ietf discussion clarified the patent issues?
I'm going to mail fsf lawyers about the patent license (http://web.cs.ucdavis.edu/~rogaway/ocb/license1.pdf), I suspect they're not compatible with the LGPL.
Regards, /Niels
On Tue, 2015-01-27 at 19:40 +0100, Niels Möller wrote:
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
To revive this discussion, it seems that there is a proposal to add OCB in TLS. https://tools.ietf.org/html/draft-zauner-tls-aes-ocb-00
I guess we need to get into release mode soon (I'll send another message to try to sort out loose ends), but it might be possible to to ocb. I've had a quick look at RFC7253. According to wikipedia (https://en.wikipedia.org/wiki/OCB_mode), that is "OCB2", is that the relevant version?
Has the ietf discussion clarified the patent issues?
I'm going to mail fsf lawyers about the patent license (http://web.cs.ucdavis.edu/~rogaway/ocb/license1.pdf), I suspect they're not compatible with the LGPL.
It is that one: https://tools.ietf.org/html/rfc7253
Let me know if you get some reply from FSF. In that case I'd recommend against standardizing OCB in the IETF TLS WG.
regards, Nikos
On Tue, 2015-01-27 at 19:58 +0100, Nikos Mavrogiannopoulos wrote:
I guess we need to get into release mode soon (I'll send another message to try to sort out loose ends), but it might be possible to to ocb. I've had a quick look at RFC7253. According to wikipedia (https://en.wikipedia.org/wiki/OCB_mode), that is "OCB2", is that the relevant version?
Has the ietf discussion clarified the patent issues?
I'm going to mail fsf lawyers about the patent license (http://web.cs.ucdavis.edu/~rogaway/ocb/license1.pdf), I suspect they're not compatible with the LGPL.
It is that one: https://tools.ietf.org/html/rfc7253
Let me know if you get some reply from FSF. In that case I'd recommend against standardizing OCB in the IETF TLS WG.
In the case it is not compatible with LGPL.
About the release... Since you added the fat, would it include AESNI +PCLMUL? If yes that would reduce significantly the assembly shipped in gnutls (only the padlock functions would remain).
regards, Nikos
Nikos Mavrogiannopoulos nmav@gnutls.org writes:
About the release... Since you added the fat, would it include AESNI +PCLMUL?
AESNI is in. If you have the time, it would be interesting if you could benchmark it against the gnutls code. The nettle implementation is pretty basic, maybe it could be sped up a bit by unrolling or by caching subkeys in registers.
Haven't looked carefully at pclmul, so I don't know how difficult it is to make use of it.
If yes that would reduce significantly the assembly shipped in gnutls (only the padlock functions would remain).
I guess padlock code could be ported over to Nettle, if it's still relevant.
Ah, and currently Nettle has aesni support only for x86_64, not 32-bit x86.
Regards, /Niels
On Tue, 2015-01-27 at 22:53 +0100, Niels Möller wrote:
Nikos Mavrogiannopoulos nmav@gnutls.org writes:
About the release... Since you added the fat, would it include AESNI +PCLMUL?
AESNI is in. If you have the time, it would be interesting if you could benchmark it against the gnutls code. The nettle implementation is pretty basic, maybe it could be sped up a bit by unrolling or by caching subkeys in registers.
Currently the numbers I get with the current implementation: $ ./gnutls-cli --benchmark-ciphers AES-128-CBC-SHA1 0.41 GB/sec AES-128-CBC-SHA256 0.27 GB/sec AES-128-GCM 3.02 GB/sec
If I use nettle's only $ GNUTLS_CPUID_OVERRIDE=0x1 ./gnutls-cli --benchmark-ciphers AES-128-CBC-SHA1 0.29 GB/sec AES-128-CBC-SHA256 188.68 MB/sec AES-128-GCM 0.29 GB/sec
(I verified that nettle detects aesni)
The GCM part heavily depends on pclmul so it's only listed for completeness. AES-CBC is quite slower though.
I don't know if it helps, but the code I currently use for AESNI is: https://github.com/openssl/openssl/blob/e0fc7961c4fbd27577fb519d9aea2dc78874...
Unrelated but I realized that I also have overrides for non-AESNI systems which use this implementation by Mike Hamburg: https://github.com/openssl/openssl/blob/e0fc7961c4fbd27577fb519d9aea2dc78874...
This takes advantage of SSSE3 and is faster while being constant time as well.
Haven't looked carefully at pclmul, so I don't know how difficult it is to make use of it.
No idea either. I can only provide a link to the existing code I use which is: https://github.com/openssl/openssl/blob/c1669e1c205dc8e695fb0c10a655f434e758... which provides low level functions used to implement GCM in: https://gitorious.org/gnutls/gnutls/source/eabf1f27d255577bad60d302abf46a969...
If yes that would reduce significantly the assembly shipped in gnutls (only the padlock functions would remain).
I guess padlock code could be ported over to Nettle, if it's still relevant.
That would be of course ideal. I can hardly help with that though...
regards, Nikos
Nikos Mavrogiannopoulos nmav@gnutls.org writes:
On Tue, 2015-01-27 at 22:53 +0100, Niels Möller wrote:
Nikos Mavrogiannopoulos nmav@gnutls.org writes:
About the release... Since you added the fat, would it include AESNI +PCLMUL?
AESNI is in. If you have the time, it would be interesting if you could benchmark it against the gnutls code. The nettle implementation is pretty basic, maybe it could be sped up a bit by unrolling or by caching subkeys in registers.
Currently the numbers I get with the current implementation: $ ./gnutls-cli --benchmark-ciphers AES-128-CBC-SHA1 0.41 GB/sec AES-128-CBC-SHA256 0.27 GB/sec AES-128-GCM 3.02 GB/sec
If I use nettle's only $ GNUTLS_CPUID_OVERRIDE=0x1 ./gnutls-cli --benchmark-ciphers AES-128-CBC-SHA1 0.29 GB/sec AES-128-CBC-SHA256 188.68 MB/sec AES-128-GCM 0.29 GB/sec
(I verified that nettle detects aesni)
Ok, so it's a factor 1.4 for the first two. And even with aesni, it seems aes is a lot of work compared to the sha1 or sha256 mac ("-SHA1" means HMAC-SHA1, right?).
Unrelated but I realized that I also have overrides for non-AESNI systems which use this implementation by Mike Hamburg: https://github.com/openssl/openssl/blob/e0fc7961c4fbd27577fb519d9aea2dc78874...
This takes advantage of SSSE3 and is faster while being constant time as well.
Constant time definitely is a good feature. Impressing that it can be done *and* be faster.
Regards, /Niels
nettle-bugs@lists.lysator.liu.se
-
Daniel Kahn Gillmor -
Nikos Mavrogiannopoulos -
Nikos Mavrogiannopoulos -
nisse＠lysator.liu.se