1993-08-02 - Re: SKIPJACK PANEL

Header Data

From: Peter Wayner <pcw@access.digex.net>
To: tk@reagan.ai.mit.edu
Message Hash: f6436f4dc325494784cafe4711bec843493defe49bff5365c7cca1de1dbabf83
Message ID: <199308021903.AA21750@access.digex.net>
Reply To: N/A
UTC Datetime: 1993-08-02 19:03:53 UTC
Raw Date: Mon, 2 Aug 93 12:03:53 PDT

Raw message

From: Peter Wayner <pcw@access.digex.net>
Date: Mon, 2 Aug 93 12:03:53 PDT
To: tk@reagan.ai.mit.edu
Message-ID: <199308021903.AA21750@access.digex.net>
MIME-Version: 1.0
Content-Type: text/plain

Tom Knight is correct that the key generation process is
a good place to hide a weakness. If I remember correctly,
the chip's key is generated directly from it's ID number
by padding it with 160 random bits and encrypting the whole
mess. 80 bits of the result becomes the key. Obviously, if
you can keep a copy of the 160 bits of padding, then you
can regenerate the chip's local key without calling
up the key-escrow fascility. Apparently, an early document
said that each collection of padding would be used for
a batch of 300 chips. So if you can keep a list of these
padding bits, then you're set...

(Disclosure: This data came from the hip, not from documents.)