[118069] in Cypherpunks

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

Re: The "ECHELON" Chip

daemon@ATHENA.MIT.EDU (Martin Minow)
Sat Sep 18 23:12:51 1999

Mime-Version: 1.0
Message-Id: <v04210101b409fc0605ca@[63.193.122.223]>
In-Reply-To: <19990918212028.52899.qmail@hotmail.com>
Date: Sat, 18 Sep 1999 19:51:55 -0700
To: "Gary Jeffers" <jeffersgary@hotmail.com>
From: Martin Minow <minow@pobox.com>
Cc: cypherpunks@cyberpass.net, cryptography@c2.net
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Reply-To: Martin Minow <minow@pobox.com>

In a note to Cypherpunks, "Gary Jeffers" <jeffersgary@hotmail.com>
offers some suggestions for adding a back door to future cpu chips
that, to simplify his note, would bypass existing memory protection
and similar schemes.

Here's an even simpler cpu hack:

1. A manufacturer adds a cryptographically strong random number
    generator to its cpu architecture that is judged by the
    cryptographic community as providing truly random numbers.
2. The only public api (on or off the chip) passes the raw
    data stream through a SHA1 whitener for added security.
    (I'm not a cryptographer, but don't understand why, if
    the input is truly random, the output needs additional
    whitening, but it's important because of step 3 below).
3. The manufacturer also adds an unpublished instruction
    orinstruction sequence that changes the random number
    generator from "true randomness" (whatever that is) to
    X = (X * 5) + 233 seeded with the current time of day and
    re-seeded every second. Since the only user-visible output
    has been SHA1 whitened, this substitution will be extremely
    difficult to detect (Especially since the initial vetting
    of the random number generator will be done with cpu's that
    were not hacked.
4. The appropriate Three Letter Agency slips the trojan horse
    instruction into the target's computer and can read encrypted
    files as long as they have a reasonable estimate of the
    time they were encrypted.

The above seems too simple to be realistic, but does explain
why SHA1 was needed to "whiten" a truly random sequence.

Martin Minow
minow@pobox.com
 


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