Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical

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

by Aristotle (Chancellor)
on Sep 03, 2004 at 22:36 UTC ( #388435=note: print w/replies, xml ) Need Help??

in reply to Re^24: Perl 6 ... dead? (no, just convalescing)
in thread Perl 6 ... dead?

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?

      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.

        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. :)

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://388435]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (9)
As of 2018-06-21 22:37 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (120 votes). Check out past polls.