[RFC] Using system libraries for crypto in samba

Simo simo at samba.org
Tue Jun 2 10:26:44 MDT 2015

On Tue, 2015-06-02 at 12:00 +0200, Stefan (metze) Metzmacher wrote:
> Hi Simo,
> > during SambaXP we had some discussion about moving away from custom
> > crypto code and toward using system provided crypto libraries instead.
> > 
> > Aside from the burden of maintaining your own crypto one of the
> > advantages of system libraries is auditing (against things like side
> > channel attacks) and hardware acceleration (libraries like OpenSSL and
> > GNUTLS/Nettle have AES-NI support for example).
> > 
> > So I started looking in what it would take to provide a small shim layer
> > in samba to access either library so that the choice is a compile time
> > option.
> > 
> > The top commit in this [1] branch has a Work In Progress implementation
> > of such an interface (fully functional and with tests for OpenSSL).
> > 
> > I have looked at both OpenSSL and GNUTLS to devise an interface that
> > could abstract both, then actually implemented it for OpenSSL (which I
> > knew would be the most challenging due to the much less cleaner
> > interfaces) to see what could actually be done.
> > CCM support in OpenSSL has some annoying restrictions (for example it
> > can do only one-shot encryption/decryption, chunking is not supported),
> Is this documented? Where do you see this limitation in the source?

Very poorly documented as usual, but the code examples here:
http://wiki.openssl.org/index.php/EVP_Authenticated_Encryption_and_Decryption mention it.

I also, of course, tested it. If you look at the tests in my commit you
will see that I do not do the chunked testes for CCM, if you remove the
safeguard and try to do it you'll get a test failure.

I haven't looked at the code to see why openssl has this limitation.

> > and I am not sure what will be required in GNUTLS as apparently CCM
> > landed less than 6 months ago, and I do not have support for it even in
> > F22 yet.
> > 
> > Beyond the CCM oddities, one other thing that stands out is that current
> > samba code uses in place encryption while these libraries always assume
> > separate (but still statically-allocated buffers).
> Where do you see that?
> e.g. nettle's gcm_crypt() and openssl's CRYPTO_gcm128_encrypt()
> seem to support dst == src.

Well the interface asks for distinct buffers, I haven't checked if it is
safe to use the same buffer for both input and output, and (as usual)
OpenSSL documentation is poor and does not give any guarantee that this
is an explicitly supported feature, so I did not want to rely on
something that may work "by accident". If we can find some guarantee
that this is an officially supported case we can then simply pass the
same buffers to the proposed interface from the code that sues it and it
will work.

> > At least for GCM I do not think this would be a huge problem, but I'd
> > like your opinions before I put any other effort into this.
> I'd really to avoid malloc calls (even if they're hidden),
> e.g. openssl's CRYPTO_gcm128_new() calls OPENSSL_malloc().
> Do you know if this is used via the EVP abstraction?
> Or is CRYPTO_gcm128_init used with a given structure?

I think we can do some more work to keep the actual crypto ctx in the
session structure so that we need to malloc only once (at first use) and
then for following uses we only call EVP_CipherInit_ex(), I haven't
looked into optimizing at that level yet.

> I think we should also provide interfaces which could do chunked
> updates of authentication data and payload including inplace
> en/decryption everything else is a pain for the callers.

To do chunking for those we'd have to keep (and malloc) an internal
buffer, it wouldn't be very efficient.
Is there any actual case where AAD is going to be chunked ? It doesn't
look likely, but I haven't looked carefully at all uses yet.

> As the ccm and gcm code is written in C anyway I'm wondering if
> we could just use the raw aes functions from the external crypto
> library and use our own ccm and gcm code (at least as fallback).

We could, but then we loose any work around side channel attacks that
are dependent on the proper use of the primitives for example. In
general we should try to stick to the recommended interface if at all
possible. For CCM, at least in the short term, we may have to anyway, so
I can look into it if required.


More information about the samba-technical mailing list