[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Weak keys

>>>>> "Theodore" == Theodore Y Ts'o <tytso@MIT.EDU> writes:

 Theodore> Date: Thu, 16 Apr 1998 15:32:21 -0700 From: "Derrell
 Theodore> D. Piper" <ddp@network-alchemy.com>

 >> It also doesn't sound like it will interoperate if new weak keys
 >> are discovered and one side is updated to recognize those weak
 >> keys (since the two sides will extract different substrings from
 >> the keying material).  After all, the listing of weak keys is
 >> subject to growth as more is learned about the systems in
 >> question.

 Derrell> The side that's been updated could just initiate a new
 Derrell> rekey, assuming that the other side wouldn't be smart
 Derrell> enough to do so.

 Theodore> This works.  I would also point out that an algorithm like
 Theodore> DES has received enough attention from the cryptographic
 Theodore> comminity that it is unlikely that new weak keys will be
 Theodore> found.  There may be new attacks which might make us decide
 Theodore> not to use the algorithm at all, but weak keys tend to be
 Theodore> relatively early in the life cycle --- ideally before the
 Theodore> algorithm is published, if there has been sufficient
 Theodore> prepublication review.

 Theodore> If we're using relatively new ciphers that aren't proven,
 Theodore> then that's much more of an issue.  Currently in IKE there
 Theodore> is no mention of needing to do anything with weak keys for
 Theodore> anything other than DES.  Given that (1) it's not clear to
 Theodore> me that it is wise to use a relatively new algorithm, and
 Theodore> (2) weak keys are rare enough that it's not clear it's
 Theodore> worth it to worry about such cases anyway.

True, but there are cases where I wouldn't use the qualifier "aren't
proven".  For example, the 3DES document specifically mentions
checking for its weak keys (those where k1==k2 or k2==k3).  Also, in
the case of DES I might want to disallow the "potentially weak" keys
Scheier lists, not just the weak and semi-weak keys.

Then there are IDEA and Blowfish, both of which are known to have weak
keys -- yet these are mature enough that they are used.  I observe
that in the case of IDEA, the earlier description of which keys are
weak has been superseded.

 Theodore> (It turns out that with DES in particular, worrying about
 Theodore> weak keys is not particularly useful, since an attacker
 Theodore> wouldn't be able to tell if a weak key was used.  All a
 Theodore> weak key means for DES is that there is some other DES key
 Theodore> which which if used to encrypt the ciphertext, will yield
 Theodore> the plaintext.  Even assuming the attacker knew that a weak
 Theodore> DES key were used, I can't see how the attacker would be
 Theodore> able to exploit this fact, especially in the context of IKE
 Theodore> phase 1.)

Well, there certainly is some argument that any kind of weak key
checking is not all that useful since the probabilities are so low.
The counterargument is that it's easy, so why not do it?  And of
course there's a specific requirement to do it for the listed set of
DES weak keys in IKE phase 1.

So what I get from all this is:
1. Handle the specified list of DES keys (and no others) in phase 1 as 
stated, i.e., skip bits.
2. Handle all other weak keys in all other cases by rekeying.

	paul
Follow-Ups: References: