Remove more crypto (sha256, sha512, hmac-sha256) (was: Re: [PATCH] Remove lib/crypto/crc32.[ch])

[Andrew Bartlett]

On Wed, 2018-10-10 at 10:47 +0200, Andreas Schneider wrote:
> On Wednesday, 10 October 2018 10:33:14 CEST Andrew Bartlett wrote:
> > On Wed, 2018-10-10 at 10:09 +0200, Andreas Schneider via samba-
> > 
> > technical wrote:
> > > On Tuesday, 9 October 2018 21:08:44 CEST Volker Lendecke via
> > > samba-technical> 
> > > wrote:
> > > > Hi!
> > > > 
> > > > Metze tells me that we have libz always available, and that contains a
> > > > crc32 implementation. Use that. I've written a small test comparing
> > > > the result of both implementations, and it was the same.
> > > > 
> > > > Review appreciated!
> > > 
> > > Thanks for the cleanup that helps me in my crypto efforts :-)
> > 
> > Thinking about how we could remove other files from lib/crypto could we
> > move our use of
> > 
> > - HMAC-SHA256
> >  - SMB2 < 2.24 SMB signing
> >  - SMB2 Key derivation
> > 
> >  # GNUTLS (>= 3.0.0)
> >  # NETTLE
> > 
> > SHA256
> >  - Security Descriptor hash for vfs_acl_xattr
> >  - oLschema2ldif
> > 
> >  # GNUTLS (>= 3.0.0)
> >  # NETTLE
> > 
> > SHA512
> >  - SMB2 Pre-auth integrity verification
> >  - BackupKey ClientWrap
> > 
> >  # GNUTLS (>= 3.0.0)
> >  # NETTLE
> > 
> > 
> > over to GnuTLS and require that?
> > 
> > https://www.gnutls.org/manual/html_node/Hash-and-MAC-functions.html
> > 
> > This would seem to avoid the issues of needing accelerated AES at one
> > end and the 'banned by FIPS but needed' at the other.
> 
> That's my plan and I've started to look into this, but there are still some 
> blocking things.
> 
> The question is do we one to move all of the crypto to gnutls or just parts 
> for now. 

How about we start with the ones I listed?  A small step, but a big
change in that the file server will require the dependency.  It has the
advantage of being fairly easy to back out again if required.

> My plan was to either use gnutls or our own crypto implementation if 
> the gnutls verison is not recent enough. GnuTLS misses some features but they 
> will be implemented soon. You can find the information about that in the 
> following milestone for GnuTLS.
> 
> https://gitlab.com/gnutls/gnutls/milestones/14
> 
> AES-CMAC has been added to libnettle (based on the Samba implementation) for 
> example. nettle is used by gnutls.
> 
> I could start to require gnutls and start migrating the hashing functions. 
> This would mean we directly use the gnutls functions.

I think that is the best if we can.  

> For other crypto we would need to have an abstraction which either uses 
> Samba's crypto or GnuTLS.

That seems to be what is required for AES to keep the acceleration on a
broad set of hosts.

The hard part about depending on external libs is that we need to be
able to use such old versions.  For example, it looks like we will need
to support gnutls 3.3 for RHEL7.  But we should go exactly as far as we
can before we have to stop, and then go further as conditions improve. 

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