From: Timothy Newsham <newsham@wiliki.eng.hawaii.edu>
Date: Wed, 24 Feb 93 00:21:07 PST
To: fnerd@smds.com (FutureNerd Steve Witham)
Subject: Re: Crypto goals
In-Reply-To: <9302231806.AB16915@smds.com>
Message-ID: <9302240821.AA27032@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


> 
> Encrypted computing.  This is even harder than non-disassemblable code.
> The idea is that you couldn't even tell what happened to the data if you
> watched it compute, tried again with slightly different inputs, etc.
> I've heard that some restricted sort of encrypted computing is possible
> with an exponential time cost!
> 
> The main application I have in mind is a mix that would be trustworthy
> even if it was run by your worst enemies with the best computers in the
> world.
> 
> This seems impossible but I don't have proof.
> 
> -fnerd
> fnerd@smds.com (FutureNerd Steve Witham)
> 
> 
How can multiple keys be chosen?  The decryption key is needed
to execute the code, it can either be (1) built into the hardware
or (2) loaded in.  In #2, if its loaded in, it can be had before
it is loaded.  In #1,  how do you change keys?  only people who
know how to encrypt for that key can program the thing.  If a
public key scheme was used,  the processor could be built with
a private key inside, and you assemble and then encode in the
public key,  only the processor (and whoever else has the 
private key) can check the code.  Quite a bit of complexity, 
also how do you do encryption in small enough units for the
cpu to use?  How do you decrypt w/ random access any part
of the data?  If you choose too large blocks (ie. cache) how
do you keep enemy programs from grabbig already decrypted data?
obviously some data must go out as plaintext (for I/O)  then
you have to keep track of which data is to always remain crypted
and which needs to go to plaintext..   wow..  what a nightmare.
I think its probably possible...
sorry for the free-form :)