SMB3 encryption performance

[Michael Ledford]

On Sun, Feb 15, 2015 at 12:07 PM, Simo <simo at samba.org> wrote:
> 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.

As I was reading documentation on GnuTLS I found it might not be a
viable option.

In Section 8, "Using GnuTLS as a cryptographic library"
<http://www.gnutls.org/manual/gnutls.html#Using-GnuTLS-as-a-cryptographic-library>,
of the manual it states, "GnuTLS is not a low-level cryptographic
library..." Now they do provide an abstracted interface for some
supported algorithms. It goes on to say in Section 8.1, "The supported
algorithms are the algorithms required by the TLS protocol. They are
listed in Table 3.1."

Looking at Table 3.1
<http://www.gnutls.org/manual/gnutls.html#tab_003aciphers> for the
supported ciphers shows that it supports a limited number of
algorithms. In the AES arena it only shows AES CBC and AES GCM.
Unfortunately, AES CCM is not shown as supported and therefore would
eliminate its possible use.

Cheers,
Michael

On Sun, Feb 15, 2015 at 12:07 PM, Simo <simo at samba.org> wrote:
> 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
>