Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Hey, I am writing some code for a machine that I cannot guarantee the security of, some of the stuff in it I'd rather keep away from prying eyes, beyond the usual obfuscation methods and such. I remember (...or I might of made this up) reading about a module that would have almost all of the code encrypted under some algorithm and would be decrypted and executed at runtime. Since then I have been completely unable to find any more about this so I decided I would try and have a go myself, my first thought was simply to encrypt a file then write a second script which would prompt for the key then decrypt the file then I would pipe the resulting code printed to the perl interpreter. Apparently this is a baaaaaad idea as it freezes up the interpreter, I can't exit without killing the process. My second thought was to use a perl filter that would encrypt the code with blowfish then request the key so it could decrypt the code but from what I have read about perlfilters this isn't really what it is designed to do...

I was just wondering if anyone could offer any tips or ideas on how this could be accomplished?

Replies are listed 'Best First'.
Re: Decrypt source before interpreter
by moritz (Cardinal) on Oct 07, 2011 at 07:39 UTC

    You can offer your script as a web service, so that the one who uses it never sees the source code.

    Apart from that, there isn't really much you can do. Perl needs to see the unencrypted source code at some point, and when perl sees it, the user can see it too.

    Anything that involves cryptography is just as insecure as obfuscation, and much wasted work.

Re: Decrypt source before interpreter
by davido (Cardinal) on Oct 07, 2011 at 08:29 UTC

    Learning Perl suggests that this isn't just a Perl problem. Even if you compile an executable binary, someone with sufficient motivation and ingenuity could decompile it. It might not look the same as the source (almost certainly won't). But to someone with the right background, it will be legible and the secrets will no longer be obscured.

    The book also suggests that a restrictive license and staff of lawyers might be a better form of security, in that the plausible threat of facing civil litigation probably serves as a better demotivator than some form of obfuscation.

    Of course I'm just paraphrasing, and probably missing something important in all that. To get it directly from the llama's mouth, refer to the 6th edition of Learning Perl.


    Dave

Re: Decrypt source before interpreter
by zentara (Cardinal) on Oct 07, 2011 at 12:57 UTC
Re: Decrypt source before interpreter
by Anonymous Monk on Oct 07, 2011 at 06:39 UTC
Re: Decrypt source before interpreter
by Anonymous Monk on Oct 08, 2011 at 01:52 UTC
    OP here. I understand generally when you are writing code for distribution trying to hide the source is useless. BUT thats not my aim, I and a small number of other people would use the program to access a blowfish encrypted database. By leaving the code in plain text I a lot can be learnt simply by the calls made to that database and how the program interacts with it which seems to make hiding the actual data within it a lot less useful although not completely so....
      Also I forgot to add this, but im not trying to hide the code from the people who will run it, they know what it does anyway, I'm just trying to stop any prying eyes
        @INC hook!