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

[Jeremy Allison]

On Fri, Sep 01, 2017 at 12:30:08PM +0200, Stefan Metzmacher wrote:
> 
> 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.

Andreas and Andrew - PLEASE READ THE ABOVE..

"we'll have to extent that ourself first and then
live with a third_party copy for quite some time."

On what planet is that not VENDING OUR OWN crypto ?????

So right now I see you NAK'ing working code
that gives immediate performance improvements that
is being used by a vendor because it's vending our
own crypto, in favour of a plan that involves
vending our own crypto.

Please explain your logic here.

Jeremy.