1993-08-02 - Re: SKIPJACK PANEL

Header Data

From: Tom Knight <tk@reagan.ai.mit.edu>
To: cypherpunks@toad.com
Message Hash: 87106a78d9836625f59ac0a5fe8e4ce8815f7cf9dd0057fae0c8c8c5139b9f8c
Message ID: <19930802182633.5.TK@ROCKY.AI.MIT.EDU>
Reply To: <m0oN43f-0009G8C@mindvox.phantom.com>
UTC Datetime: 1993-08-02 18:27:34 UTC
Raw Date: Mon, 2 Aug 93 11:27:34 PDT

Raw message

From: Tom Knight <tk@reagan.ai.mit.edu>
Date: Mon, 2 Aug 93 11:27:34 PDT
To: cypherpunks@toad.com
Subject: Re: SKIPJACK PANEL
In-Reply-To: <m0oN43f-0009G8C@mindvox.phantom.com>
Message-ID: <19930802182633.5.TK@ROCKY.AI.MIT.EDU>
MIME-Version: 1.0
Content-Type: text/plain


    Date: Mon, 2 Aug 1993 13:52 EDT
    From: thug@phantom.com (Murdering Thug)

    To review:  1) The key escrow aspect is a wild goose chase.
		2) The security of the algorithm is also a wild goose chase.
		3) The backdoor must be in the chip hardware itself.

Dr. Thug ignores the most obvious weakness, which is likely in the key
generation process.  By selecting the key from a relatively small
keyspace (say 40 bit equivalent, rather than the 80 bit nominal
keyspace) the cost of exhaustive search can be dramatically lowered to
those who know the basis of key selection, without any outward evidence
of tampering, weakness of the algorithm, weakness of the chip,
vulnerability to external attacks, special hardware to respond to
trapdoor codes, etc.

Examining the chip hardware for correctness will not discover this
attack.  Only providing users with the ability to program their own
keys, together with public disclosure of the Skipjack algorithm and
verification of its implementation can help.

If there are a significant number of weak keys in the Skipjack algorithm
(which is explicitly denied in the panel report) then even this approach
could be dangerous.





Thread