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 ]