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

Re: key processing for manual and dynamic SA

>>>>> "tytso" == tytso  <tytso@mit.edu> writes:

 tytso> Date: Fri, 24 Jul 1998 12:25:32 -0400 From: Paul Koning
 tytso> <pkoning@xedia.com>

 paul> The only sensible approach I can see for dealing with the
 paul> parity bit is to ignore it.  If the DES implementation
 paul> requires valid parity (I've never seen one that does) then the
 paul> software can invisibly supply the correct parity from the user
 paul> supplied key.

 tytso> I'd be careful before making that assumption.  There was very
 tytso> notable case (involving telnet and Kerberos V4), where a
 tytso> non-crypto person at Berkeley designed the original session
 tytso> key negotiation for doing telnet encryption. ...

 tytso> The problem has since been fixed (and it involved a fairly
 tytso> nasty hack in the telnet client to force the session key
 tytso> negotiation such that the key would have the correct parity)....

My comment wasn't so much an assumption as rather an observation, but
anyway... 

Forcing valid parity outcome of the negotation sounds like a
nightmare.  The obvious approach -- which I assume ISAKMP uses even
though it doesn't seem to be terribly clear -- is that the DES key is
defined to be passed around as 8 bytes in which the low order bit is a 
don't care.  If the implementation internally requires good parity,
then the code feeding that piece of the implementation is responsible
for supplying that good parity, but as far as the protocol is
concerned there is no such thing as parity.

 paul> As for dynamic keying and weak keys, there's an explicit list
 paul> of weak keys to check for and a rule for how to deal with
 paul> that.  There are other keys ("possibly weak" in Scheier) in
 paul> DES that you may or may not want to check for, as well as weak
 paul> keys for other algorithms (IDEA, Blowfish).  Since the spec
 paul> doesn't explicitly require checking for those, you can't use a
 paul> "move one byte and try again" approach.  Instead, if you want
 paul> to refuse such keys, the only method I can see that works is
 paul> to negotiate another key (as if this key had already expired).

 tytso> A number of people have already commented that weak key
 tytso> detection really isn't necessary.  It's important to
 tytso> understand what weak keys mean --- a weak key K is a key for
 tytso> which there exists another key K' where

 tytso> DES_ENCRYPT(K, DES_ENCRYPT(K',M)) == M

 tytso> It is not the case that it is possible, merely by inspection
 tytso> of the ciphertext, to determine that a weak key was used.
 tytso> (This is unlike a class of weak keys in IDEA, which does have
 tytso> this property).  For this reason, there is no real harm done
 tytso> if a weak key happens to get negotiated.  The chance that (a)
 tytso> a weak key is negotiated, and (b) a IPSEC packet is
 tytso> re-encrypted in another key, and (C) the key used to
 tytso> re-encrypt the packet is the weak key's analogue.  The chance
 tytso> of this happen is small enough as to not really be worth
 tytso> bothering about.

So I think what you're saying is that *DES* weak key checking isn't
crucial. 

 tytso> On the flip side, writing code which deals with DES weak keys
 tytso> means writing code which will be very rarely tested, since the
 tytso> chance that a weak key will be negotiated is also very small.
 tytso> So if there's a problem with that code, it's likely that it
 tytso> won't be detected until after it's been shipped.

 tytso> That's the reason why the spec doesn't require checking for
 tytso> weak keys, because it's not clear that it's really a good idea
 tytso> to do so.  Of course, different encryption algorithsm may have
 tytso> weak keys with different properties, such that it would be a
 tytso> good idea to do something to avoid weak keys.  However, for
 tytso> DES, this does not seem to be the case.  (Of course, given the
 tytso> results of Deep Crack, all this discussion about single DES is
 tytso> somewhat moot at this point.  :-)

My understanding is that there is a piece of weak key checking that IS 
required, namely the rule of taking the first 8 bytes that are
non-weak.  That has to be requires or else the two ends won't pick the 
same keying material.

Of course, any weak key checking that simply invokes rekeying is not a 
protocol issue and can be done optionally.

Then there's also the 3DES draft, which says you must check for 
K1==K2 || K2==K3.

	paul
References: