[10300] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: A risk with using MD5 for software package fingerprinting

daemon@ATHENA.MIT.EDU (David Honig)
Mon Jan 28 12:47:19 2002

Message-Id: <3.0.6.32.20020128074846.00839740@mail.orng1.occa.home.com>
Date: Mon, 28 Jan 2002 07:48:46 -0800
To: John Gilmore <gnu@toad.com>, David Honig <dahonig@home.com>
From: David Honig <dahonig@home.com>
Cc: "Arnold G. Reinhold" <reinhold@world.std.com>,
	cryptography@wasabisystems.com, gnu@toad.com
In-Reply-To: <200201281027.CAA12663@toad.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 02:27 AM 1/28/02 -0800, John Gilmore wrote:
I have done enough years of chip testing AND architectural
>validation to know how few of the infinitely many combinations of
>instructions or bus cycles are actually tested to make sure that
>somebody didn't intentionally make *one* combination do something
>interesting.  Even if you trust your processor, didn't the NSA pay the
>Taiwanese designer of your RAM chips to replace particular stored code
>sequences with other interesting ones, one time out of a hundred, when
>fetched?

Nice piece.  When I was writing Verilog for Blowfish and IDEA, we
got interested in how to verify that the chip did what the code described.
Esp. because you hand over your output to other internal groups who transform
it into other forms (e.g., standard cell netlist, then GDSII masks, etc.)

We were thinking about using reverse-engineering services who could
strip, image, and reconstruct a netlist, to confirm that the logic
did what it was supposed to (and in our case, nothing else).  The equivalent
of reverse-compiling from assembler --or microcode!  We never got that far,
though.

dh




 






  







---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com

home help back first fref pref prev next nref lref last post