Re^25: Perl 6 ... dead? (no, just convalescing)

That means the decryption algorithm is standardized and known. (If it is not, the VM is subject to the same decompilation issues as the bytecode was in your other scenarios.) That defeats the entire purpose and makes decrypting the "natively" encrypted bytecode trivial.

There is no scheme ever that works — by definition. The only way to prevent reverse engineering is having control of the hardware.

Makeshifts last the longest.

Comment on Re^25: Perl 6 ... dead? (no, just convalescing)

Replies are listed 'Best First'.
Re^26: Perl 6 ... dead? (no, just convalescing) by jryan (Vicar) on Sep 03, 2004 at 22:47 UTC
You're saying that RSA - encrypted JVM bytecode would be trivial to decrypt?	[reply]
Re^27: Perl 6 ... dead? (no, just convalescing) by Aristotle (Chancellor) on Sep 03, 2004 at 22:52 UTC
That's exactly equivalent to the DVD Content Scambling System. It hinges on the security of the decryption key, which is delivered to every user, hidden inside the VM. Remember what happened to CSS? Makeshifts last the longest.	[reply]
Re^28: Perl 6 ... dead? (no, just convalescing) by jryan (Vicar) on Sep 03, 2004 at 22:56 UTC
I didn't suggest that the key be hidden inside the VM. I suggested that it be entered by the users, every time the encrypted program was run; hence the "it would be a huge pain in the ass to users" part. :)	[reply]
Re^29: Perl 6 ... dead? (no, just convalescing) by Aristotle (Chancellor) on Sep 03, 2004 at 23:09 UTC
Re^30: Perl 6 ... dead? (no, just convalescing) by jryan (Vicar) on Sep 03, 2004 at 23:22 UTC
Some notes below your chosen depth have not been shown here


Problems? Is your data what you think it is?
	PerlMonks