How about making a list of features we want, and/or a list of scenarios we want to be able to handle? ... executable but non-disassemblable code [is it possible?] ... Have I missed anything?
-- Marc Ringuette (mnr@cs.cmu.edu)
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)
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 :)
participants (2)
-
fnerd@smds.com
-
Timothy Newsham