On Tue, Nov 13, 2012 at 3:50 PM, Booker Bense <[email protected]> wrote: > On Sun, Nov 11, 2012 at 8:50 PM, Greg Hudson <[email protected]> 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). Nico -- ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
