Subject: RE: AES and SHA-1 timing

From: "Paul Leach" <[email-masked]>
Date: Wed, 16 Apr 2003 10:38:52 -0700

I hope it is clear that the iteration count in the AES string-to-key
cipher suite can be precomputed by the KDC when the password is changed;
thus, it should not normally have any significant impact on KDC load.
(Unless you have a really high volume of password change operations.)

Finally, the iteration count is just the default -- it can be changed if
a large number of really slow machines are in one's environment, and if
the increased risk of password breakability can be accepted.

---

From: Ken Raeburn <[email-masked]>
Date: Wed, 16 Apr 2003 15:46:12 -0400

> (Unless you have a really high volume of password change operations.)

Or a relatively low-power KDC, which I suspect has been entirely
adequate for many environments, if it's a dedicated machine with
nothing else to do.

>> Probably by the time we are actually able to 
>> turn DES off (at best >4 years?), the timing model that Paul 
>> Leach used to justify his 1 second delay will be completely 
>> obselete, if it isn't already out of date.
>
> The iteration count will have to periodically be tweaked upward to
> account for increasing machine speed.

The values in use might, but the default cannot be changed once
standardized.  The default value chosen based on such a model will
become obsolete, and will fall out of use at sites that want to use
such an approach to password security.  And I suspect the gap between
the high-end and low-end machines will only become wider.  That gap is
what pushes us towards real preauthentication schemes.

>> We see some form 
>> of preauthentication logic as being a much more promising way 
>> to protect weak keys.
>
> I don't fully understand this comment, but the timing model I gave
> assumed passwords that are about as strong as humans can remember.

Like he said... "weak". :-)

Ken