1994-01-27 - Re: clipper pin-compatible chip/plug&play

Header Data

From: rarachel@prism.poly.edu (Arsen Ray Arachelian)
To: koontzd@lrcs.loral.com (David Koontz)
Message Hash: 34b8f66e9b12d7ac610c2eaf816874c46389a464e68a4e7fded3f78466cd3dbd
Message ID: <9401271926.AA18080@prism.poly.edu>
Reply To: <9401261919.AA22973@io.lrcs.loral.com>
UTC Datetime: 1994-01-27 19:37:42 UTC
Raw Date: Thu, 27 Jan 94 11:37:42 PST

Raw message

From: rarachel@prism.poly.edu (Arsen Ray Arachelian)
Date: Thu, 27 Jan 94 11:37:42 PST
To: koontzd@lrcs.loral.com (David Koontz)
Subject: Re: clipper pin-compatible chip/plug&play
In-Reply-To: <9401261919.AA22973@io.lrcs.loral.com>
Message-ID: <9401271926.AA18080@prism.poly.edu>
MIME-Version: 1.0
Content-Type: text


Actually, even if the clipper chip is limited to 10 bytes plus a 3 byte
checksum of sort, even if it's 10 bits it doesn't matter.

What you'd plug in the socket could have it's own CPU, and key
database, or even a plug in keypad of sorts to type in whatever key
you want.  You don't necessarily have to use the clipper requested
key.  A key of all 1's or 0's would be great, infact, it would be better
than great, it would be an indicator that the key is elsewhere, etc.

This plug in chip could have extra pins which don't plug into the
clipper chip socket, but rather go to another board layer which would
keep a database of encrypted keys and some way to access those keys with
a passphrase.

(I'm typing this in from work where all I have is some rather $#itty
term software, so please forgive my typos, etc.)




Thread