confusion in ank.

[Ken Raeburn]

On Apr 23, 2007, at 13:07, Daniel Kahn Gillmor wrote:
> i agree that it's worthwhile to support expiration policy for
> randomly-generated keys.  One could even argue for iteratively
> applying password-quality policies to randomy-generated keys from a
> pragmatic approach:
>
> In the unlikely event the randomly-generated key happens to be
> guessable by common tools (dictionary attacks, limited character
> classes, etc), it's probably worth generating a new random key.  While
> this reduces the overall space of possible random keys, it does keep
> the random keys out of the (admittedly tiny) space regularly probed by
> the most common brute force attackers.

Because of how salt strings are factored into the key generation  
process (except in the case of RC4), a dictionary attack based on  
passwords is going to have to incorporate specific salt strings --  
which in normal cases means incorporating the principal name in the  
attack.  Which means an attacker would presumably know when they're  
attacking a service key that's likely to have been randomly  
generated, versus a user's password-derived key.  (And Microsoft's  
server passwords should be long enough and random enough to evade  
dictionary attacks.)

(Insert plug for my "randomize salt on password change" idea here,  
which would prohibit even building the dictionary of keys without  
talking to the KDC first to get the salt string.)

I think an attacker continuing to use a dictionary in that case would  
be wasting cycles compared with simply trying 00...000, 00...001,  
etc.  Should we also eliminate all the keys that are likely to be hit  
early in a simple sequential brute-force probe?  That sort of thing  
simply changes where the clueful attacker starts his attack, and  
that's the attacker I'd be more concerned about.

The salt-less RC4 cryptosystem kind of puts a crimp in this, in that  
you could use a dictionary of generated keys to try decrypting a  
bunch of messages, without paying attention to whether the messages  
were encrypted in a user's key or a randomized service key.  Except,  
the distinction between uses of the initiator's key and the  
acceptor's key and a session key is generally pretty easy to make;  
only when a service is initiating authentication (getting tickets so  
it can authenticate to another service) would I expect randomized  
principal keys to come under dictionary attack.  Even so, it's not a  
case I'm going to lose any sleep over; 2**128 is a pretty big  
number.  If we were generating password strings randomly, then maybe,  
but not while we're randomly generating the bits of the key themselves.

Ken