Subject: RE: How about AES support?

From: "John Brezak" <[email-masked]>
Date: Mon, 10 Dec 2001 09:05:22 -0800

> -----Original Message-----
> From: Ken Raeburn [mailto:[email-masked]] 
> Sent: Sunday, December 09, 2001 4:00 PM
> To: Marcus Watts
> Cc: [email-masked]
> Subject: Re: How about AES support?
> 
> 
> 
> > I believe the open issues are:
> 
> Good summary, though you touched on an issue or two I hadn't 
> been aware of myself....  :-)
> 
> > (1) string to key -- how many iterations, and should it be variable?
> 
> Variable is difficult.  A preauth method could control it, 
> but that wreaks havoc on the crypto abstraction we're 
> proposing in section 6 of kerberos-revisions, where the 
> passphrase and salt string are currently the *only* inputs.

I do not see any problem with adding the iteration count to the enctype
specific "salt" parameters. Not all enctypes use the salt.

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.

> 
> > 	I think that 1 or 2 iterations is fine, and a large number
> > 		is undesirable.
> 
> Adding a small number of iterations of an HMAC, it seems to 
> me, should qualitatively improve the resistance to attacks 
> that reverse some rounds of the hash function by itself.  A 
> large number is probably only useful for increasing the cost 
> of the attacker processing a large number of pass phrases.

Originally, 1000 was the targetted initial number, although we might
want to drop this down a bit.

By providing a "pw-salt"-like mechanism to be able to adjust the
iterations
via policy, it would allow a site to increase this limit.

> 
> > 	Paul Leach suggested there were better ways ways, such as
> > 		using a local strong secret, to protect a weak
> > 		password.
> 
> 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).

> 
> > (2) hash algorithm.  Raeburn's draft recommends a hash twice the
> > 	size of the key.  Doubling the hash size is useful when
> > 	using a digest straight, to avoid the birthday attack.
> > 	Doubling is not necessary, and in some respects undesirable
> > 	when using an hmac.  It may be sufficient to use sha-1 or
> > 	sha256 and to truncate to the block size.
> 
> I'm curious why it's undesirable with an HMAC.
> 
> My main reason for it was the fact that NIST was proposing 
> them to be used in conjunction with AES.
> 
> > (3) there's some other minor tuning that could be done to the key
> > 	derivation function, basically to avoid certain sorts
> > 	of collisions.  (distinguishing between [email-masked] and 
> [email-masked]
> > 	in the salt, passing crypto identifier and output 
> length into hash.
> 
> Easy enough to do, by changing the pass phrase and salt 
> values fed to the PKCS5 function.  How about, just off the 
> top of my head:
> 
> 	pkcs5passwd = length(pw) | pw
> 	pkcs5salt = enctype | length(salt) | salt
> 
> ?
> 
> > 	Pkcs5 itself isn't so smart about pws > hash size.)
> 
> I doubt we'll have many cases of that in the near future, but 
> we shouldn't be doing anything stupid in that regard either.
> 
> > (4) I'd like to see ciphertext stealing.  I haven't seen anyone
> > 	else express an opinion on this, either way.
> 
> Looks interesting, especially considering AES has a larger 
> block size than we've had with DES.  We still get some 
> expansion because of the hash value, but it wouldn't be quite so big.
> 
> I think this'll still fit fine within the simplified-profile 
> from kerberos-revisions section 6.  I'll look into it further.
> 
> > (5) It may be reasonable to drop the 384 & 512 bit variants, and
> > 	concentrate on standardizing the 128 bit variant.
> 
> I'm already planning to drop the middle size.  Doing both 
> small and large is pretty easy, once we're doing one of them 
> in the first place.
> 
> > 	MIT k5 may need an additional number for the "raw" crypto
> > 	family, but it would be best to avoid this.
> 
> For internal uses, we still might, we'll see...  they don't 
> come out of the officially allocated number space though.
> 
> > raeburn actually describes rijndael, serpent & twofish.  Is
> > 	it necessary or desirable to specify all 3 at once?
> 
> Not necessary, no.
> Useful, perhaps, to demonstrate that random block ciphers 
> (that are similar in form to des3-cbc) can be plugged in.

Should serpent and twofish be dropped from the AES I-D in favor of
just rijndael ?

> 
> > that whole telnet mess.
> 
> TLS with Kerberos mechanism?
> 
> > gssapi constants should be defined too.
> 
> IMHO, no.  A new mechanism should be designed that uses 
> KRB-PRIV and KRB-SAFE messages and avoids explicitly 
> specifying the enctype info per message.  If quality of 
> protection needs to be specified, do that as part of the 
> (sub)session key selection.
> 
> > I don't remember seeing anything past what I posted.  
> People may have 
> > been distracted by other events.
> 
> Yeah, the non-crypto bits of kerberos-revisions have been 
> more high-profile lately.  I do still have some work to do on 
> the crypto bits, I've recently discovered....
> 
> Ken
>

---

From: Ken Raeburn <[email-masked]>
Date: 10 Dec 2001 13:22:48 -0500

> 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.

> the contents and any applicable character set encoding must be

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.

> 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.

> 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

I could go either way.  I don't know if anyone really favors either of
the others over Rijndael.

Ken