password-change performance using AES-NI ?

[Danny Thomas]

A sort of follow-on from
http://mailman.mit.edu/pipermail/kerberos/2012-November/018546.html

One of the stated goals with 1.12 due in December is
"AES-NI support for built-in crypto back end"

Does anyone have a rough idea of how much improvement this might
bring. I'm hoping it will be substantial because string-to-key
involves 4,096 iterations. Which is different to comparisons in
http://www.tomshardware.com/reviews/clarkdale-aes-ni-encryption,2538.html

You can get access to AES-NI now by switching the crypto
back-end from the default 'builtin' to 'openssl'.

Are there downsides from switching crypto back-end ?
Any benefits from openssl other than AES-NI support ?


cheers,
Danny

AFAICT from a quick glance over the past 6 months of cvs-krb5,
I didn't see any commit apparently for AES-NI.

RHEL6.4 comes with 'OpenSSL 1.0.0-fips 29 Mar 2010'
openssl engine -c -tt
(aesni) Intel AES-NI engine
[AES-128-ECB, AES-128-CBC, AES-128-CFB, AES-128-OFB, AES-192-ECB,
AES-192-CBC, AES-192-CFB, AES-192-OFB, AES-256-ECB, AES-256-CBC,
AES-256-CFB, AES-256-OFB]
[ available ]
(dynamic) Dynamic engine loading support
[ unavailable ]

[Greg Hudson]

On 05/11/2013 08:08 PM, Danny Thomas wrote:
> Does anyone have a rough idea of how much improvement this might
> bring. I'm hoping it will be substantial because string-to-key
> involves 4,096 iterations.

PBKDF2 uses many iterations of a hash algorithm (SHA-1, in the case of
Kerberos AES enctypes), not a block cipher. Using AES-NI will not have
a perceptible impact on string-to-key performance.

> AFAICT from a quick glance over the past 6 months of cvs-krb5,
> I didn't see any commit apparently for AES-NI.

I haven't pushed the code yet. At the moment, it's at:

https://github.com/greghudson/krb5/tree/aesni

[Danny Thomas]

On 12/05/2013, at 3:08 PM, Greg Hudson wrote:

> PBKDF2 uses many iterations of a hash algorithm (SHA-1, in the case of
> Kerberos AES enctypes), not a block cipher. Using AES-NI will not have
> a perceptible impact on string-to-key performance.

I should have looked at rfc3962 to get back up to speed.

I believe OpenSSL is supposed to have one of the best open-source
implementations of SHA1, at least when SSSE3 is available (possibly
better when AVX available), so we might check the relative performance
of builtin vs openssl crypto back-ends.

Is there any downside in switching to openssl back-end ?

Might also ask on the openssl mailing ist whether there's active work
on GPU-accelerated engines. There is engine-cuda but I'm not sure
it is maintained/production-ready.

Various people have looked at GPUs for encryption/hashing, e.g. search
for "PBKDF2 CUDA" or "PBKDF2 OpenCL"


Danny