[PATCH] Crypto use in Samba (was: Re: SMB3 encryption performance)

[Andrew Bartlett]

On Thu, 2015-02-19 at 14:32 -0500, Michael Ledford wrote:
> On Tue, Feb 17, 2015 at 7:24 PM, Andrew Bartlett <abartlet at samba.org> wrote:
> >> On Tue, Feb 17, 2015 at 1:48 PM, Andrew Bartlett <abartlet at samba.org> wrote:
> >> > GnuTLS is still looking like the best option on the research so far.  If
> >> > we can find a reliable way to build gnutls in a private prefix, then I
> >> > think that by the time a release with this support is made (later this
> >> > year), a good number of users will be able to take advantage of it one
> >> > way or the other.
> >>
> >> I don't think I quite understood what were saying. Are you suggesting
> >> to find a way to prefix all of GnuTLS' methods so they live in its own
> >> namespace? Or simply building a version of GnuTLS in a way that it's
> >> not actually included in the Samba source tree?
> >
> > I just mean installing it in or under /usr/local/samba (like we do with
> > the install_with_python.sh script) and linking against it with -rpath.
> >
> >> > If I ever get time to finish updating Heimdal, then the next step for me
> >> > in that area is to build only with upstream, getting it out of our tree
> >> > and build system.  I would replacing that with a script to build it
> >> > using it's own build system, privately.
> >> >
> >> > Doing the same (automated private build) with GnuTLS would be a good
> >> > first step to demonstrating that this is a viable option.
> >>
> >> How would you propose that this automated private build occur? It
> >> seems like you have ideas.
> >
> > A script or part of our waf build system would shell out to the
> > existing, unmodified build system of the GnuTLS project, and install it
> > in the right place, ready for us to use.
> >
> > We could, as we do with other libraries under third_party, build using
> > our waf, but I would like to try an alternate approach, as that tends to
> > be a lot of work long-term.
> >
> >> > I think the next step is to see what the interfaces look like when used
> >> > in practice.
> >>
> >> I assume this would be actually integrating GnuTLS into parts of Samba
> >> to see what problems or changes would need to take place, if any, to
> >> accommodate it?
> >
> > All this about how to get access to GnuTLS is pretty academic if the
> > code either doesn't work, isn't accelerated or is too painful to use (as
> > was suggested of libgcrypt).
> >
> > Andrew Bartlett
> >
> > --
> > Andrew Bartlett
> > http://samba.org/~abartlet/
> > Authentication Developer, Samba Team  http://samba.org
> > Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba
> 
> Here is a patch to include Nettle's supported algorithms in the
> REQUIREMENTS document.

Thanks!  Can you also add a marker for AES-NI where supported?

> Is there a reason not to use Nettle provides everything GnuTLS does
> and then some?

>From my perspective, the criteria (there will be no perfect scores) are
probably along the lines of
 - licence (must be GPL compatible, no hidden licence bombs that might
cause trouble)
 - acceleration (the hook to justify change)
 - build-ability (is the API sane to use, or incredibly painful like
NSS's PKCS#11 or was alleged of gcrypt)
 - availability (is it in major linux distributions already) 
 - existing use (we do already need it for other things)

> Cheers,
> Michael
> 
> n.b. - This is my first patch so please let me know if I need to do
> anything differently.

If you could add a Signed-off-by that would be great.

Thanks!

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba