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

[Michael Ledford]

On Thu, Feb 19, 2015 at 4:19 PM, Andrew Bartlett <abartlet at samba.org> wrote:
> 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

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

I have added to the relevant Nettle lines indicating where AES-NI is supported.

See the newly attached patch.

Cheers,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-lib-crypto-Document-nettle-supported-crypto.patch
Type: application/octet-stream
Size: 2159 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20150223/212994cf/attachment.obj>