improving kadmind change-password performance

Nico Williams nico at
Tue Nov 13 18:45:51 EST 2012

On Tue, Nov 13, 2012 at 3:50 PM, Booker Bense <bbense at> wrote:
> On Sun, Nov 11, 2012 at 8:50 PM, Greg Hudson <ghudson at> wrote:
>> For password changes, kadmind has to run the string-to-key algorithm on
>> the new password for each enctype in supported_enctypes (which defaults
>> to AES-256, AES-128, DES3, and RC4).  The string-to-key algorithm for
>> the AES enctypes is deliberately slow in order to make dictionary
>> attacks harder.  I believe this operation is swamping any other
>> performance bottlenecks.
> I would want to see the profile data before I made any recommendation.
> " premature optimization is the root of all evil "
> In my experience even when you know the code base extremely well, you can
> often
> be quite wrong about where the time is actually spent.

FWIW, Heimdal has a perf test, and it shows that password
authentication crawls by comparison to keytab authentication.  Given
this I completely agree with Greg's diagnosis.  A quick test would be
to measure how many randkey operations/second kadmind supports (when
no other activity is going on, of course).


More information about the Kerberos mailing list