SMB3 encryption performance

[Simo]

On Sun, 2015-02-15 at 11:40 +0100, Volker Lendecke wrote:
> On Sat, Feb 14, 2015 at 05:04:25PM -0500, Simo wrote:
> > The best hardware assisted code afaik is found in OpenSsl (usually the
> > first to get any support) or NSS libraries, all others trail if they
> > have any HW support at all.
> 
> Hasn't there been an issue with the OpenSSL license?

It is considered GPL incompatible [1] and would need an exception (which
we can grant if we want).

> What about the NSS libraries license-wise?

NSS is release under the Mozilla Public License v2.0 which is compatible
with GPLv3 [2]. The NSPR library on which NSS depends should be licensed
the same way, but I couldn't find an explicit COPYING file, just a
LICENSE file with the MPL2 text and no additional notes.

Next
----
TL;DR:
we should use a vetted one and not mix.

Long version:

Besides the licenses, note that OpenSSL and NSS both suck in their own
ways, however it is generally easier to find information around OpenSSL
than it is for NSS. Trying to read the code of either is a trip that
usually ends with nightmares and headaches :-)

Another option is GnuTLS, which should be easier to use, however some
people in the past has raised issues with the crypto/code quality [4].
Since 2008 many years ave passed, and GnuTLS has probably gotten better,
but I have to note gnutls.org does not serve content over HTTPS, only
over HTTP ...

GnuTLS claims support for HW acceleration [4]:
* Support for CPU-assisted cryptography with VIA padlock and AES-NI
instruction sets. 
  * Support for cryptographic accelerator drivers via /dev/crypto. 

And the author works for Red Hat now. So, despite the controversies
around code quality, it is probably good enough these days. I know that
Debian for example uses GnuTLS instead of OpenSSL in all GPL licensed
code, patching upstream code where necessary (They link OpenLDAP with
GnuTLS, not OpenSSL too).


I do not want to endorse any library, I had my issues and satisfactions
with each of them. Ideally we can use any of them letting the user
choose, although building abstractions around these libraries is
expensive. The things we should absolutely avoid though is to use
multiple libraries at the same time, that would be bad.
As for the crypto in the Heimdal source, I would really like to avoid
using it for non-KDC stuff. It causes issues for people that need to use
the MIT code, and for TLS stuff I do not know that it has been vetted
much by any third party or common use, and asymmetric crypto +
certificate validation is much more complex than the usual symmetric
crypto (read: we have no idea how good/safe it is).

Simo.

[1] https://www.gnu.org/licenses/license-list.html#OpenSSL
[2] https://hg.mozilla.org/projects/nss/file/ac277ab60e8f/COPYING
[3]
http://www.huffingtonpost.com/howard-chu/software-design-trustwort_b_4937977.html
[4] http://gnutls.org/

-- 
Simo Sorce