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

Weak DES keys



-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Dan" == Dan McDonald <Dan.McDonald@eng.Sun.COM> writes:

    >> Given this, I'd say forget about handling it.

    Dan> Quick question, do you mean key mgmt. failing?  If so, I
    Dan> agree, and you state the perfect reasons why below...

  There are, I think, two places that we use a DES key. In the ISAKMP
SA, and in the ESP key. (Would we care about weak keys if using a DES
based MAC?)

    >> The world isn't just DES, though. The question about what to do
    >> with weak keys in general. Are weak keys in other algorithms
    >> equally improbable?

    Dan> I dunno about other algorithms, but you can't discount that
    Dan> possibility.

  If we are just talking about DES for the ISAKMP SA, then I'd say
don't even check for weak keys.

    Dan> Pardon the small plug, but PF_KEY has, since its inception,
    Dan> and at the insistence of the many, REQUIRED to return errors
    Dan> when an algorithm's key is deemed weak.  This means either
    Dan> SADB_ADD, or SADB_UPDATE will fail miserably when/if a weak
    Dan> key is fed down.

  Plug appropriate. If we return fail, then I'd say that we just
pretend we never did anything and try again. That works, is algorithm
independant, and removes all weak key checks from the key manager.
  
  We are, btw, implementing it, but since at least a couple versions
of our engine is user space based, we are pushing PF_KEY packets
through Unix domain stream sockets, or NT named pipes, or Mac
i-don't-know-but-somebody-does. I haven't read your latest draft to
see if that mode of operation was documented. 

   :!mcr!:            |  Network security programming, currently
   Michael Richardson | on contract with DataFellows F-Secure IPSec
 WWW: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@sandelman.ottawa.on.ca</A>. PGP key available.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQB1AwUBNBmaOaZpLyXYhL+BAQHP+AL/VqYnKgYRSiUnThJjsLe2E1J38rm+at+h
BoL/u2GLyydKzB+0saQ0V50ceEhtqFBTo2xwR4NhzpT5HqE03BT6Ov5fq2/Ov2Ye
h/rBUlogBFWW1Kp84WnUWyU3AnecCAOH
=aYw+
-----END PGP SIGNATURE-----


Follow-Ups: References: