1996-02-26 - Re: Encryption Chips

Header Data

From: Adam Shostack <adam@lighthouse.homeport.org>
To: PADGETT@hobbes.orl.mmc.com (A. Padgett Peterson P.E. Information Security)
Message Hash: 2141a36f30ab38158267064942ce768eb1445dbb9d52100b4782a7ffc895864d
Message ID: <199602260205.VAA24540@homeport.org>
Reply To: <960225114724.20210a61@hobbes.orl.mmc.com>
UTC Datetime: 1996-02-26 02:32:52 UTC
Raw Date: Mon, 26 Feb 1996 10:32:52 +0800

Raw message

From: Adam Shostack <adam@lighthouse.homeport.org>
Date: Mon, 26 Feb 1996 10:32:52 +0800
To: PADGETT@hobbes.orl.mmc.com (A. Padgett Peterson P.E. Information Security)
Subject: Re: Encryption Chips
In-Reply-To: <960225114724.20210a61@hobbes.orl.mmc.com>
Message-ID: <199602260205.VAA24540@homeport.org>
MIME-Version: 1.0
Content-Type: text


a. huh?
b. I was assuming something similar to the Sun /dev/des, which is
basically invoked as 
int cbc_crypt(key, data, datalen, mode, ivec)
              ^^^

If your chip is doing key generation for you, then testing is tougher.

Adam


A. Padgett Peterson P.E. Information Security wrote:

| >	Faking crypto chips for public algorithims is theoretically
| >more difficult, because its simple to create a DES_verify routine to make
| >sure your DES chip is working right.
| 
| a) chips do not need makeup
| b) t'were me, I would just fix the chip so that instead of 2^56 (DES) keys
|    or whatever, the PRNG was "fixed" so that the total keyspace was only 2^32
|    for instance. Enough to be nearly impossible to check but small enough


-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume






Thread