Subject: RE: AES and SHA-1 timing

From: "Paul Leach" <[email-masked]>
Date: Wed, 16 Apr 2003 12:54:23 -0700

>
> -----Original Message-----
> From: Ken Raeburn [mailto:[email-masked]]
> Sent: Wednesday, April 16, 2003 12:46 PM
> To: Paul Leach
> Cc: [email-masked]
>
> "Paul Leach" <[email-masked]> writes:
> > 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.)
>
> 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.

I don't understand this statement. As I said, the KDC does NOT need to
compute the string to key function on every AS-REQ. It can compute it at
password change time and store it.

> >
> > 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 values in use definitely need to be.

A (very small) new standard could periodically be issued with the new
default.

Or, we could put in a table of defaults for the next few years... :-)
At the very least, there should be a RECOMMENDATION that the values in use
get increased every year.

Paul

---

From: Ken Raeburn <[email-masked]>
Date: Wed, 16 Apr 2003 18:03:04 -0400

> password change time and store it.

Sorry, I was thinking about the password-change process -- individual
password-change operations may become unacceptably slow on KDCs
running on such machines.  But you're right -- for a KDC not
processing a lot of password change requests (in a small realm, or an
MIT-style slave KDC), the CPU time consumed by string-to-key is not a
big issue.

> The values in use definitely need to be.

*If* we don't go with required strong preauth schemes instead.

> A (very small) new standard could periodically be issued with the new

It would need to specify a new enctype number.  Otherwise, we
invalidate existing compliant implementations every time we do it.

> get increased every year.

I'd be fine with this, as long as it's mentioned in conjunction with
the use of the count as a means to dissuade offline attacks.  If a
site is requiring a strong preauth system that reveals nothing
encrypted in the user's key, the recommendation doesn't really apply.

Ken