Subject: Re: WG Last Call: Clarifications and AES - End of Last Call

From: Sam Hartman <[email-masked]>
Date: Thu, 10 Apr 2003 13:42:26 -0400

>>>>> "Paul" == Paul Leach <[email-masked]> writes:

    Paul> I'd be tempted to say we should leave the default at a nice
    Paul> "secure" 0x0b00 and let installations with slow machines
    Paul> either get optimized software or change the setting to be
    Paul> less secure but faster.

I think Marcus's point is that the speed is unacceptable even for
relatively current hardware.

---

From: [email-masked]
Date: Thu, 10 Apr 2003 20:29:53 -0700

You missed an important qualifier in Marcus' statement -- it is slow on
some machines currently in use (but last generation) 
"at least without specially tuned assembler SHA1 implementations." 

And its always possible for the KDC admin to decide that they are willing
to trade perf for security and use a smaller iteration count -- with the
current default, we make them confront this choice, rather than making it
for them. If we default to a smaller iteration count, then we expose the
less-well-informed admin to a security risk that perhaps they shouldn't
and needn't take.

> 
> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]] 
> Sent: Thursday, April 10, 2003 10:42 AM
> To: Paul Leach
> Cc: Ken Raeburn; Douglas E. Engert; Kerberos WG; Russell 
> Housley; Steven M. Bellovin
> 
> I think Marcus's point is that the speed is unacceptable even 
> for relatively current hardware.
> 
> 
>

---

From: Sam Hartman <[email-masked]>
Date: Fri, 11 Apr 2003 14:17:21 -0400

>>>>> "Paul" == Paul Leach <[email-masked]> writes:

    Paul> And its always possible for the KDC admin to decide that
    Paul> they are willing to trade perf for security and use a
    Paul> smaller iteration count -- with the current default, we make
    Paul> them confront this choice, rather than making it for
    Paul> them. If we default to a smaller iteration count, then we
    Paul> expose the less-well-informed admin to a security risk that
    Paul> perhaps they shouldn't and needn't take.

I'm reasonably confident that if we deploy code with the current
default, our customers will choose 3des rather than AES because the
performance with AES is unacceptable to them.

I think this is true even if we optimize our SHA1 implementation.

We could establish an implementation default that we always used
rather than using the default in the spec.  That's extra complexity
for us--we're hoping to ship an initial version that does not permit
tuning the s2kparams on the server side.  But I would rather argue to
change the default because I believe it is not deployable in enough
environments to be a reasonable default.  I agree it should be an
option.

Why do you believe the current value is the correct default?

---

From: "Paul Leach" <[email-masked]>
Date: Tue, 15 Apr 2003 15:08:21 -0700

> Sent: Friday, April 11, 2003 11:17 AM
> To: Paul Leach

It was based on the following very rough calculation:

There are approx 2**25 seconds in a year. Imagine I had 512 1 ghz PCs. A
company requires that passwords get changed every 45 days -- that's 2**22
seconds. If "complex password rules" could force passwords to have an
entropy of 2**32, and each crack attempt took one second on those
machines, it would take 90 days to exhaustively search the password space,
and 45 days on average to crack the password.

A reasonable password cracking dictionary might have 2**21 entries;
complexity rules forcing mixed case, digits and punctuation could
plausibly add 2**11 combinations for each dictionary word, resulting in
2**32 possibilities.

The choice of 1 ghz is because that seems to be about where the
price/performance sweet spot is today. The choice of 512 machines as the
target is subjective -- I just felt that (say) 100 was too low when
reasonably fast machines can be had for $300: $30k to crack passwords
seemed like too many people could afford it, and ten machines is cleary
too low.

Similary, the guesstimate on password entropy is just that. But 32 bits of
entropy in passwords that humans remember seems like it is stretching
things already.

So, although there are lots of things one could fudge, the choice of 1
second as the target to check one candidate password on a moderate speed
machine (by todays standards) seemed about right.

I could be convinced to make the target be 1/2 second.

Paul