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

[Stefan Metzmacher]

Hi,

>> 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.

This is important in order to avoid useless talloc and memcpy calls,
which are partly required because of the limited APIs provided
by existing crypto libraries.

> 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.

By having better APIs the overhead would be even less if we could
avoid talloc and memcpy.

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

aes_block_xor() was also very high on the list...

> 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/20170904/8ee15d3f/signature.sig>