[PATCH] Use Intel AES instruction set if it exists.

[Jeremy Allison]

On Fri, Sep 01, 2017 at 11:48:22AM +0200, Andreas Schneider wrote:
> On Friday, 1 September 2017 11:30:04 CEST Andrew Bartlett wrote:
> > On Fri, 2017-09-01 at 08:49 +0200, Andreas Schneider via samba-
> > 
> > technical wrote:
> > > I've discussed this already with Metze when I implemented support for MS
> > > Catalog Files last year. We are currently using GnuTLS for various things
> > > inside of Samba (backupkey, TLS).
> > > 
> > > GnuTLS uses the nettle crypto library [1] which has a very nice and clean
> > > API. It has support for AES NI and also other improvements. It also
> > > supports some other crypto functions we use and it is easy to get code
> > > upstream.
> > > 
> > > I would really prefer to use a crypto library for this stuff instead of
> > > rolling out our own crypto. It also makes it harder for people who
> > > maintain
> > > packages in distributions, because then Samba is implementing crypto and
> > > we
> > > have a harder time to get it certified or FIPS compliant.
> > > 
> > > So please before pushing this, look at libnettle! We have a file:
> > > 
> > > lib/crypto/REQUIREMENTS
> > > 
> > > which has a summary what we need and crypto libraries provide!
> > > 
> > > 
> > > 
> > > Please see that as a NAK till you looked into libnettle and can convince
> > > me
> > > that doing our own crypto is better. We aren't cryptographers and we
> > > should
> > > not maintain a crypto library.
> > 
> > Andreas, 
> > 
> > I said much the same to Jeremy when he mentioned this to me long ago in
> > our occasional phone calls.
> > 
> > As such, I strong agree, and would like to move us further towards
> > using GnuTLS for as much of our crypto as possible.  I understand the
> > argument about 'working patches trump', but still don't want to be
> > maintaining more crypto code.
> 
> I think for SMB it is is better to use nettle directly. GnuTLS does memory 
> allocations where nettle doesn't need them. gnutls_hash_init() for example.

Andreas and Andrew, this is an *OUT OF THE BOX* 2x performance improvement
when using signing and sealing, which is becoming an increasingly important
workload.

I understand wanting to use clean API's, and am willing to work
towards that. I have no problems working towards using libnettle.

But we are already using our own crypto, and this moves us to
a third_party library directly sourced from the Linux kernel,
so I disagree that this is 'maintaining our own crypto'. In
fact it's allowing the possibity of moving of the crypto *out*
of our code and into third_party.

As it doesn't change any of our API's this is an easy drop in
replacement.

Don't let the perfect be the enemy of working code that brings
great benefits RIGHT NOW !

Andreas, if you're NAKing this I'd like to see your commitment
to moving us to libnettle, and your timeframe for creating this
code please.

Jeremy.