Subject: RE: rijndael test vectors

From: "John Brezak" <[email-masked]>
Date: Tue, 11 Sep 2001 22:22:17 -0700

The intent was to add a cost of about 1 second on the client in the
compuation of the hash using PKCS#5. This is a deterrent for attackers.

Also the initial number is the default. The site can increase the number
of iterations required via policy that would be returned using the
"PA-ETYPE-INFO" mechanism that is used for salt in the other encryption
types. So as CPUs get faster, you can increase the cost to stay ahead of
attackers.

You still need a mechanism to protect the initial AS request/response to
deal with passive attacks.

There is a way to determine that a device like a cell-phone is being
used to authenticate - then the KDC can tailor the hash function to a
specific type of device - prehaps using a key that can only be used from
a verified cell-phone (or device with an authenticated identity). This
means that there can be multiple keys per enctype (all with the same
kvno) - for the PKCS#5 hash, you can have keys with different iteration
counts.

-----Original Message-----
From: Ken Raeburn [mailto:[email-masked]] 
Sent: Monday, September 10, 2001 10:14 AM
To: Marcus Watts
Cc: [email-masked]
Subject: Re: rijndael test vectors

> I'd be disappointed if the iterations went up; the small number was 
> actually one of the things I liked about the current draft.  All 
> iterations does is burn CPU cycles on the client, and there's not 
> enough room between today's slowest clients and server farms 
> accessible to vandals N years from now to make this very effective.
> If the goal

I'm more than a little skeptical of the simple factor-of-N slowdown as a
deterrent to determined attackers; the change from simple hash to HMAC
seems like the big step to me.  If the difference in computing power you
describe isn't a very small multiplier compared to the dictionary size,
I think we've got a problem, and that's not very dependent on the cost
of a single attempt.  This is why we need the extra protection for the
initial ticket exchange that John Brezak and I and others have been
talking about, whether it be SRP, EKE, or whatever.

On the other hand, as long as it doesn't slow down the legitimate
clients too much (including cell phones and PDAs, at 16MHz or less),
raising the bar for the attacker may still be a good thing; even if it's
not high enough for a determined attacker, we may discourage the script
kiddies.

I can certainly see arguments on both sides; what I don't know is if
there's something more the crypto gurus know that I don't...  John's
been talking to some crypto folks at Microsoft; that's where the
suggestion to use PKCS #5 came from in the first place.

> One of the comments I wanted to make is there ought to have been test 
> vectors for a 64 character password, and a 65 character one, and 
> perhaps 128 characters and 129 characters, because those exercise some

> interesting boundary conditions in hmac.

An excellent idea.  I'll add some test cases with that in mind.

Ken

P.S.  Anyone know what the available cpu power is on a typical (not
high-end) cell phone these days?

---

From: "Paul Leach" <[email-masked]>
Date: Wed, 12 Sep 2001 10:17:07 -0700

For a non-shared device like a phone, why not have a per-user or
per-device strong secret that is hashed with the user's password to get
the key used in the preauth? If it's per-user, there would need to be a
way to plumb the device. If it's per-device, then a device id as "salt"
would be needed to select which device key.

> From: John Brezak 
> Sent: Tuesday, September 11, 2001 10:22 PM
> To: Ken Raeburn; Marcus Watts
> Cc: [email-masked]
> Subject: RE: rijndael test vectors
> 
> 
> The intent was to add a cost of about 1 second on the client 
> in the compuation of the hash using PKCS#5. This is a 
> deterrent for attackers.
> 
> Also the initial number is the default. The site can increase 
> the number of iterations required via policy that would be 
> returned using the "PA-ETYPE-INFO" mechanism that is used for 
> salt in the other encryption types. So as CPUs get faster, 
> you can increase the cost to stay ahead of attackers.
> 
> You still need a mechanism to protect the initial AS 
> request/response to deal with passive attacks.
> 
> There is a way to determine that a device like a cell-phone 
> is being used to authenticate - then the KDC can tailor the 
> hash function to a specific type of device - prehaps using a 
> key that can only be used from a verified cell-phone (or 
> device with an authenticated identity). This means that there 
> can be multiple keys per enctype (all with the same
> kvno) - for the PKCS#5 hash, you can have keys with different 
> iteration counts.
> 
> I'm more than a little skeptical of the simple factor-of-N 
> slowdown as a deterrent to determined attackers; the change 
> from simple hash to HMAC seems like the big step to me.  If 
> the difference in computing power you describe isn't a very 
> small multiplier compared to the dictionary size, I think 
> we've got a problem, and that's not very dependent on the 
> cost of a single attempt.  This is why we need the extra 
> protection for the initial ticket exchange that John Brezak 
> and I and others have been talking about, whether it be SRP, 
> EKE, or whatever.
> 
> On the other hand, as long as it doesn't slow down the 
> legitimate clients too much (including cell phones and PDAs, 
> at 16MHz or less), raising the bar for the attacker may still 
> be a good thing; even if it's not high enough for a 
> determined attacker, we may discourage the script kiddies.
> 
> I can certainly see arguments on both sides; what I don't 
> know is if there's something more the crypto gurus know that 
> I don't...  John's been talking to some crypto folks at 
> Microsoft; that's where the suggestion to use PKCS #5 came 
> from in the first place.
>