1994-04-03 - Code Obfuscation

Header Data

From: garet.jax@nitelog.com (Garet Jax)
To: cypherpunks@toad.com
Message Hash: 402a7f34f973d7b34aa5ae974c521c5c0f6b8d21f0f2441febb596c5baa8c343
Message ID: <cb.85012.10.0CD048DC@nitelog.com>
Reply To: N/A
UTC Datetime: 1994-04-03 14:45:39 UTC
Raw Date: Sun, 3 Apr 94 07:45:39 PDT

Raw message

From: garet.jax@nitelog.com (Garet Jax)
Date: Sun, 3 Apr 94 07:45:39 PDT
To: cypherpunks@toad.com
Subject: Code Obfuscation
Message-ID: <cb.85012.10.0CD048DC@nitelog.com>
MIME-Version: 1.0
Content-Type: text/plain



>Timothy C. May adds:

>Hal Finney writes:

>> The other issue, which I know less about, is the possibility of cryptograph-
>> ically strong obfuscated code.  Mike Duvos first mentioned this.  You could
>> have an algorithm running on your own computer and have it be impossible to
>> determine what it is doing, or (presumably) to effectively alter the
>internals
>> of the algorithm.
>.....stuff detiled..

>> discussing here (self-decrypting code and such tricks), but rather some
>> mathematically strong transformation has been done on the structure of the
>> code to hide it in a cryptographically strong way.
>>

>Brad Cox, of Objective-C notoriety, and now at George Mason
>University, has also been interested in this area of "complexifying"
>code so that reverse engineering is difficult or impossible.

Okay if you want to obfuscate your code on a much more secure level
albeit with some execution penalty, build public key encryption
into the CPU.  One would simply compile the program and encrypt it
using the public key of the chipset (680xx, 80x86, &c), then the
CPU would decrypt and execute the code on the fly using its private
key.






Thread