Ray, Ray->In your essay, you overlook the use of pseudo-code interpreters
and cryptographic code mangling.
No I don't. In fact, I specifically mention the latter. Ray->It is not possible to make software
unconditionally tamper proof, but it is possible to make it hard [...]
Ray->If crackers had to alter just 10% of an
application to get it to work unprotected, I think that would be a sufficient deterrent to most of them.
I agree! I even said this in the final paragraph: Scott->The attack might not be cheap! But people will do it if the
reward exceeds the cost.
Some of the things you mention would make a program very expensive to `crack'. However, as we both said: just expensive, not impossible. It certainly might be expensive enough to stop the particular class of attacks you have in mind. Your notes about remote trusted systems (e.g., Telescript) are accurate. The difference they introduce into the scenario is that execution is no longer under control of the attacker, and in fact the attacker can have a piece of software that `runs', but may only run after being unlocked on the trusted system, with the private key of the trusted system. I specifically mentioned and excluded this class of problems from my argument. However, you also say: Ray->Here, the problem is that the code is never "decrypted" in
the first place.
Ray->Imagine the task of having to create a plaintext which will generate
a certain MD5 hash.
No. The code is decrypted. It does get to the CPU. The CPU does execute instructions belonging to the `actual functionality' of the software. Comparing this to finding a text with a given hash is not accurate. (Maybe it is accurate if the attacker tries to get between the interpreter and the byte-codes; but not if the attacker just stands behind the CPU.) Either the CPU gets to see the final instructions or it doesn't. If it never sees them it is because the program doesn't or won't run in the first place. I exempted this situation from my argument. The attacker must have at least one working copy of the software. If the CPU _does_ see the instructions, then the secret is out, no matter how difficult it is to capture it ... it's still only difficult, not impossible. My argment is about communication, not about programming. Like the old joke: A: "Would you sleep with me for a million dollars?" B: "...uh, sure. Yeah, I'll sleep with you for a million bucks." A: "Would you sleep with me for twenty dollars?" B: "What do you think I am?!" A: "I know what you are! Now we're just haggling for a price." The quality and effectiveness of `protection code' (under the conditions I gave) can never amount to anything more than `haggling for a price'. I think you already understand and agree with this. The price might actually be as much as $1,000,000.00; which could be sufficient deterrent. To that end, the tamper-proofing will have succeeded. Your p-code (maybe `protected-code') proposal could be a viable product. Don't stop. After all, none of DES, IDEA, and RSA, are unconditionally secure, and they serve us well. Cheers, Scott Collins | "Invention, my dear friends, is 93% perspiration, | 6% electricity, 4% evaporation, and 2% butter- collins@acm.org | scotch ripple." -- Willy Wonka ..................|.................................................. Apple Computer, Inc. 5 Infinite Loop, MS 305-2D Cupertino, CA 95014 408.862.0540 fax:974.6094 R254(IL5-2N) collins@newton.apple.com ..................................................................... 408.257.1746 1024:669687 catalyst@netcom.com