SMB3 encryption performance

[Volker Lendecke]

Hi!

My summary of your mail would be to concentrate on gnutls if we're
about to code hw crypto. Ack?

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
> 

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de