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 ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos