improving kadmind change-password performance

[Roland C. Dowdeswell]

On Tue, Nov 13, 2012 at 05:16:51PM -0500, Tom Yu wrote:
>

> Booker Bense <bbense at gmail.com> writes:
> 
> > 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.
> 
> A certain part of the test suite that creates a large number of
> principals (with known passwords) became measurably slower after a
> change to make supported_enctypes include AES.  I did not keep the
> data around anywhere that I can recall though.

It is also relevant to note that this is by design.  The string to
key function employed by AES (PKCS#5 PBKDF2[1]) is specified in such
a way to frustrate dictionary attacks on more modern hardware than
the older string2key functions and the key to frustrating dictionary
attacks is to ensure that it is more computationally difficult (and
memory intensive in the case of scrypt[2]) to perform the operation.
PKCS#5 PBKDF2 has an iteration count that may [hopefully] be
increased as computational power increases and therefore over the
course of time this will continue to dominate the setting of passwds
thus limiting the speed of creating principals or changing passwds.

[1]	https://tools.ietf.org/html/rfc2898

[2]	http://www.tarsnap.com/scrypt.html

--
    Roland Dowdeswell                      http://Imrryr.ORG/~elric/