SMB3 encryption performance

[Simo]

On Sun, 2015-02-15 at 17:03 +0100, Volker Lendecke wrote:
> Hi!
> 
> My summary of your mail would be to concentrate on gnutls if we're
> about to code hw crypto. Ack?

If that's what people are comfortable with, and covers all our needs, it
is ok by me.

Simo.

> Volker
> 
> On Sun, Feb 15, 2015 at 10:08:10AM -0500, Simo wrote:
> > 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
> > 
> 


-- 
Simo Sorce