Subject: RE: How about AES support?

From: "John Brezak" <[email-masked]>
Date: Mon, 10 Dec 2001 13:31:24 -0800

> -----Original Message-----
> From: Ken Raeburn [mailto:[email-masked]] 
> Sent: Monday, December 10, 2001 10:23 AM
> To: [email-masked]
> Subject: Re: How about AES support?
> 
> 
> "John Brezak" <[email-masked]> writes:
> > I do not see any problem with adding the iteration count to the 
> > enctype specific "salt" parameters. Not all enctypes use the salt.
> 
> The ugly part is that it's a string generally hashed in.  
> Overloading its meaning, so that it can't be essentially 
> random for a given enctype, may not make some people happy.

We can discuss later this week at the meeting.

> 
> > Also, if we expect salts to be used in any
> > consistent way, then they need to be described in some 
> document with 
> > the enctype descriptions. The pw-salt and etype-info mechanisms are 
> > understood by only a few.
> > 
> > Also the salts are described simple as octet-string. For 
> each enctype 
> > the contents and any applicable character set encoding must be 
> > specified.
> 
> In some places they're octet strings; in section 6 they're 
> UTF-8.  The handling in section 6 of passwords and salts 
> needs to catch up to whatever we do about character sets elsewhere.
> 
> I don't think the character set encoding should be 
> per-enctype.  I think our conceptual interface -- the 
> high-level description in section 6 and what the rest of the 
> Kerberos spec assumes -- should have a single input format 
> independent of enctype, and possibly have conversions happen 
> within the string-to-key functions of specific algorithms.

It really is up to the enctype's string-to-key to define what
salts are used and what they contain.

> 
> > Originally, 1000 was the targetted initial number, although 
> we might 
> > want to drop this down a bit.
> 
> On the same day Marcus sent his timing test results, I was 
> working on a program for timing SHA-1 on my Handspring Visor 
> (33MHz CPU32). Maybe I'm biased, but I think we'd want to 
> support these devices. :-)
> 
> By my very rough estimates, a Palm Pilot (16MHz CPU32) would 
> probably do somewhere in the ballpark of 100 SHA-1 HMAC 
> iterations in a second. I don't think anyone expects these to 
> be the fastest devices, but even on them, waiting 10 seconds 
> for authentication seems like a little much.

On these personal devices, wouldn't you just precompute the key when
the user's password is entered and use that for most cases?

> 
> > > Definitely, and we should be using some of them.
> > 
> > But there is still a need to utilize a protection mechanism (i.e.
> > PKCS#5)
> > when there is not another mechanism to protect the initial as-req 
> > (i.e. DCE RFC-26).
> 
> Probably.  I'm still not convinced that a simple multiplier 
> is good enough, but once we're using PKCS#5, the multiplier 
> is easy enough to add.
> 
> > Should serpent and twofish be dropped from the AES I-D in favor of 
> > just rijndael ?
> 
> I could go either way.  I don't know if anyone really favors 
> either of the others over Rijndael.
> 
> Ken
>

---

From: Ken Raeburn <[email-masked]>
Date: 10 Dec 2001 16:45:02 -0500

> salts are used and what they contain.

But you're talking about constraints imposed by the enctype
specification on what salt strings can be used, which I don't like.
Whether that's acceptable is something we need to decide -- and if so,
what do we need to add to section 6 to provide for it?

> the user's password is entered and use that for most cases?

I would probably enter it only when I needed it, and write my software
to wipe it as soon as I was done with it.  Other people may be happy
with encrypting the key in a scheme that is less CPU-intensive (but
then leads to easier compromise if the device is stolen).

Ken