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

Re: key processing for manual and dynamic SA

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

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

I'd be careful before making that assumption.  There was very notable
case (involving telnet and Kerberos V4), where a non-crypto person at
Berkeley designed the original session key negotiation for doing telnet
encryption.  They didn't bother making sure the DES key had the correct
key parity, and the DES library they used checked for correct key parity
and returned an error in that case (leaving the key schedule as all
zeros).  The telnet code, both client and server, demonstrated the same
level of cleverness by not checking the return value from the DES key
scheduling function, and continued along their merry way with an all
zero key schedule, with an only 1 in 256 chance that the session key
negotiation would generate a key with the correct parity, and not fall
into this trap!

The problem has since been fixed (and it involved a fairly nasty hack in
the telnet client to force the session key negotiation such that the key
would have the correct parity).  But as far as good implementation
practice is concerned, it's a really *BAD* idea to assume that DES key
parity doesn't matter, and of course you should always check the return
code from your library routines.  :-)

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

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

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

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

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

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

						  - Ted

P.S.  In other news, if people where wondering why I haven't responded
in a while, it's because I've been on vacation in Alaska.  (Denali
National park is definitely well worth visiting.)  I'm actually still on
the road (although back in the lower 48), and will be back in the office
as of Tuesday.

I'm currently catching up on my mail at this point, so it may take me a
while before I'm completely caught up.  In the meantime, in answer to
what must be the #1 asked question on people's minds, right before I
left for vacation two weeks, I got the last of the updated I-D's with
the changes required by Thomas Narten.  I gave the list to Jeff
Schiller, and it's now back in the hands of the IESG.  I'd expect action
at the next IESG teleconference, if nothing happened last Thursday, but
being on the road, I haven't heard back from Jeff about any updated
status for the drafts.  I'm fairly confident that if they haven't been
approved by the IESG yet, they will be in fairly short order.
Follow-Ups: References: