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

[Stefan Metzmacher]

Am 01.09.2017 um 12:06 schrieb Andrew Bartlett:
> On Fri, 2017-09-01 at 11:48 +0200, Andreas Schneider via samba-
> technical 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:
>>>>
>>>> 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.
> 
> Sure.  I don't know how others feel about a mandatory dependency, but I
> think we should work to get out of the crypto business, even if it
> makes us a little harder to install on some systems.  
> 
> We could go third_party if we have to, but if Linux is well covered we
> should be able to avoid that. 

There's also some work in progress here:
https://git.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master3-smb-crypto

https://git.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=3759eb23b38c
makes use of libnettle.

But is only replaces the low level aes and xor functions.

But what we really need are APIs like this (our current one):

void aes_gcm_128_init(struct aes_gcm_128_context *ctx,
                      const uint8_t K[AES_BLOCK_SIZE],
                      const uint8_t IV[AES_GCM_128_IV_SIZE]);
void aes_gcm_128_updateA(struct aes_gcm_128_context *ctx,
                         const uint8_t *a, size_t a_len);
void aes_gcm_128_updateC(struct aes_gcm_128_context *ctx,
                         const uint8_t *c, size_t c_len);
void aes_gcm_128_crypt(struct aes_gcm_128_context *ctx,
                       uint8_t *m, size_t m_len);
void aes_gcm_128_digest(struct aes_gcm_128_context *ctx,
                        uint8_t T[AES_BLOCK_SIZE]);

Or maybe even better:

void aes_gcm_128_init(struct aes_gcm_128_context *ctx,
                      const uint8_t K[AES_BLOCK_SIZE],
                      const uint8_t IV[AES_GCM_128_IV_SIZE]);
void aes_gcm_128_update(struct aes_gcm_128_context *ctx,
                        const struct iovec *a_iov, size_t a_iov_count,
                        struct iovec *m, size_t m_iov_count,
			bool forward);
void aes_gcm_128_digest(struct aes_gcm_128_context *ctx,
                        uint8_t T[AES_BLOCK_SIZE]);

and give it a chance to be completely optimized by the hardware,
by doing parallel encryption, but still allow it to be passed
in chunks.

https://git.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=1f83cbefd1b
gives the best performance with aes_gcm_128 using openssl as
it does almost everything with hardware instructions.

If I remember correctly aes_block_rshift and aes_block_shift consumed
the most cycles.

If we would rely an a crypto library, we'll have to extent that ourself
first and then live with a third_party copy for quite some time.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20170901/96b39c21/signature.sig>