I have an encrypted python module format: .pye
hi all: I want to use python in my product because I like and familiar with python for many years, but I won't let the customer to read and modify my code. So the best way is to encrypt my module .py to .pye. Now python will write compiled byte code .pyc or .pyo when a .py is imported, I have write a patch to add .pye support for encrypted byte code. When a .pye is imported, python will check the environment variable PYTHONENCRYPT, if this environment variable is defined with non-blank value, the value is used to generate AES key and CBC initialize vector which will be used to encrypt .py and decrypt .pye. Now it is work for me, does the python community is interested for it? I believe this feature can be helpful to let the python to be used in bussiness use case. Thanks greatly. Charles Wang May/12, 2012.
On Sat, 12 May 2012 06:27:03 +0800 li wang <charlesw123456@gmail.com> wrote:
And what prevents the customer from doing that themselves in order to read the source?
While the ability to hide code is a recurring request, it really doesn't get a lot of support. The problem is that you have to have the plain text of the code available on the customers machine in order to run it. So everything they need to know to decrypt it has to be on the machine, meaning you're relying on obscuring some part of that information to keep them from decrypting it outside of the execution environment. Security through obscurity is a bad idea, and never really works for very long. The recommended solution is to package your software so that reading the source isn't really a requirement. One alternative is to ship both a Python executable and .pyo files without the .py files. I believe there's even a tool for windows that bundles all of that up into a .exe file. This is really just more obscurity, though. It's not like extracting the .pyo files from the .exe is impossible, and turning .pyo files back into python code is straightforward. The better approach is to refactor the critical code into a web service, and sell the users a client and an account. Or give away the client and just sell the account. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
On May 11, 2012, at 6:27 PM, li wang <charlesw123456@gmail.com> wrote:
I won't let the customer to read and modify my code.
What you describe sounds impossible: how can your customer run your code without an encryption key? If you deliver the key, how can you prevent the customer from reading your code? Preventing modification is feasible with various signed code schemes, but software DRM can never work.
It it impossible in the same way that it is impossible to lock the front door of your house. The Dropbox client for most major OS'es is written in Python and they use a similar technique. They are very happy with it. --Guido On Fri, May 11, 2012 at 3:43 PM, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
-- --Guido van Rossum (python.org/~guido)
Well, a quick Google search found this: http://itooktheredpill.dyndns.org/2012/dropbox-decrypt/ So their encryption is pretty useless. The difference to breaking a door lock is, that breaking a lock requires some effort each time you do it. Breaking the encryption of such code only requires a one time effort by someone interested in cracking such things (provided he/she will then publish his/her findings, which they often do). On 05/12/2012 01:02 AM, Guido van Rossum wrote:
On 12 May 2012 08:27, li wang <charlesw123456@gmail.com> wrote:
As others have noted, this is essentially useless for protecting your code. How do you set that environment variable on your customer's system, without giving them the key they need? You can erect a somewhat higher barrier by using Pyrex or Cython to compile your modules to .pyd/.so. It's still quite possible to extract your logic and/or patch around things, but it's a little harder. The only reasonably secure method (again, as noted by others) is to not have your code on the client machine e.g. using a web service for the critical logic. Tim Delaney
http://chargen.matasano.com/chargen/2009/7/22/if-youre-typing-the-letters-a-... On Sat, May 12, 2012 at 2:11 PM, Tim Delaney <timothy.c.delaney@gmail.com> wrote:
On Fri, May 11, 2012 at 6:27 PM, li wang <charlesw123456@gmail.com> wrote:
Actually it's better to simply ship the .pyc/.pyo files and/or to minify the code to make it unreadable. As everyone pointed out, the encryption you are proposing won't stop anyone from reading your source, it will just make it a little harder. -Brett
On Sat, 12 May 2012 13:13:59 -0400 Brett Cannon <brett@python.org> wrote:
I think it's worth explaining why just shipping the .pyc/.pyo files is "better". If it's not clear by now, a fancy encryption scheme won't protect your sources from someone who really wants to read them. On the other hand, shipping just the .pyc/.pyo files will stop casual browsing. The only real difference here is how much effort it takes to get the source. To carry Guido's analogy further, both lock your front door, one just uses a better lock. Neither will stop a determined burglar. On the other hand, if you ship code with a fancy encryption scheme, you're shipping more moving parts, which means more things to go wrong, which means more support calls. With the particular scheme you proposed, you'll get calls from people who managed to run the code without properly setting the environment variable, or set it to the wrong thing, and those are just the obvious problems. In summary, your encryption scheme will make life just a little harder for everyone when compared to simply not shipping the source. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Mike Meyer wrote:
I think Guido's analogy is bogus and wrongly suggests that encrypting applications just might work if you try hard enough. If we can lock the door and keep strangers from peeking inside, why can't we encrypt apps and stop people from peeking at the code? But the analogy doesn't follow. In the front door example, untrusted people don't have a key and are forced to pick or break the lock to get it. In the encryption example, untrusted people are given the key (as an environment variable), then trusted not to use it to read the source code! (Possibly on the assumption that they don't realise they have the key, or that using it manually is too difficult for them.) Ultimately, on a computer the user controls, with a key they have access to, they can bypass any encryption or security you install. That's why e.g. so many forms of copy protection and digital restrictions software try to take control away from the user, to some greater or lesser degree of success. -- Steven
The analogy is you want to protect the doors with a lock from the guy you gave the key. (source: house, encrypted: the lock, the way to decrypt in order to run: the key)
(as an environment variable), then trusted not to use it to read the source
code!
The problem is that he don't trust the customer.
On Sun, May 13, 2012 at 2:36 AM, Steven D'Aprano <steve@pearwood.info> wrote:
I think Guido's analogy is bogus and wrongly suggests that encrypting applications just might work if you try hard enough.
Eh? I didn't mean that at all. To the contrary I meant that every encryption can be broken but that it may still be a useful deterrent. I wasn't aware of the detail of the OP's proposal that the key was right in the user's environment -- but that actually has an exact analogy in the front door example: hiding the key under the mat. -- --Guido van Rossum (python.org/~guido)
On Sun, May 13, 2012 at 11:30 AM, Guido van Rossum <guido@python.org> wrote:
This sounds like an argument not to include this functionality in stdlib. If hiding the key under the mat becomes standard, a key under the mat will be as inviting as an open front door. Those interested in obscurity should not invite public discussion of clandestine advantages of doormats over garden rocks.
On Sun, 13 May 2012 19:36:52 +1000 Steven D'Aprano <steve@pearwood.info> wrote:
But locking the door *won't* keep strangers from peeking inside. Not if they really want to. It'll keep people from casually opening the door, but it won't stop someone who really wants to see the insides because they can:
Exactly. You can easily get tools to do all these things, as well as others, to get past the lock.
This is pretty much required in any form of DRM. You have to give the end user the keys in order for them to use what you gave them. Trying to prevent them from then doing *other* things is done by obfuscating how you get from the cyphertext to the plaintext. That's it can't work is why the US container companies got laws passed making doing so illegal.
(Possibly on the assumption that they don't realise they have the key, or that using it manually is too difficult for them.)
The difficulty level is immaterial. With the proper training and tools, none of these things (picking locks, breaking down doors, reverse engineering code obfuscation) is difficult. On the other hand, you can raise the difficulty level of any of them by investing more in whatever obstacles you're putting in the way. They both do the same thing. That's why the analogy works. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
On Sat, 12 May 2012 06:27:03 +0800 li wang <charlesw123456@gmail.com> wrote:
And what prevents the customer from doing that themselves in order to read the source?
While the ability to hide code is a recurring request, it really doesn't get a lot of support. The problem is that you have to have the plain text of the code available on the customers machine in order to run it. So everything they need to know to decrypt it has to be on the machine, meaning you're relying on obscuring some part of that information to keep them from decrypting it outside of the execution environment. Security through obscurity is a bad idea, and never really works for very long. The recommended solution is to package your software so that reading the source isn't really a requirement. One alternative is to ship both a Python executable and .pyo files without the .py files. I believe there's even a tool for windows that bundles all of that up into a .exe file. This is really just more obscurity, though. It's not like extracting the .pyo files from the .exe is impossible, and turning .pyo files back into python code is straightforward. The better approach is to refactor the critical code into a web service, and sell the users a client and an account. Or give away the client and just sell the account. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
On May 11, 2012, at 6:27 PM, li wang <charlesw123456@gmail.com> wrote:
I won't let the customer to read and modify my code.
What you describe sounds impossible: how can your customer run your code without an encryption key? If you deliver the key, how can you prevent the customer from reading your code? Preventing modification is feasible with various signed code schemes, but software DRM can never work.
It it impossible in the same way that it is impossible to lock the front door of your house. The Dropbox client for most major OS'es is written in Python and they use a similar technique. They are very happy with it. --Guido On Fri, May 11, 2012 at 3:43 PM, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
-- --Guido van Rossum (python.org/~guido)
Well, a quick Google search found this: http://itooktheredpill.dyndns.org/2012/dropbox-decrypt/ So their encryption is pretty useless. The difference to breaking a door lock is, that breaking a lock requires some effort each time you do it. Breaking the encryption of such code only requires a one time effort by someone interested in cracking such things (provided he/she will then publish his/her findings, which they often do). On 05/12/2012 01:02 AM, Guido van Rossum wrote:
On 12 May 2012 08:27, li wang <charlesw123456@gmail.com> wrote:
As others have noted, this is essentially useless for protecting your code. How do you set that environment variable on your customer's system, without giving them the key they need? You can erect a somewhat higher barrier by using Pyrex or Cython to compile your modules to .pyd/.so. It's still quite possible to extract your logic and/or patch around things, but it's a little harder. The only reasonably secure method (again, as noted by others) is to not have your code on the client machine e.g. using a web service for the critical logic. Tim Delaney
http://chargen.matasano.com/chargen/2009/7/22/if-youre-typing-the-letters-a-... On Sat, May 12, 2012 at 2:11 PM, Tim Delaney <timothy.c.delaney@gmail.com> wrote:
On Fri, May 11, 2012 at 6:27 PM, li wang <charlesw123456@gmail.com> wrote:
Actually it's better to simply ship the .pyc/.pyo files and/or to minify the code to make it unreadable. As everyone pointed out, the encryption you are proposing won't stop anyone from reading your source, it will just make it a little harder. -Brett
On Sat, 12 May 2012 13:13:59 -0400 Brett Cannon <brett@python.org> wrote:
I think it's worth explaining why just shipping the .pyc/.pyo files is "better". If it's not clear by now, a fancy encryption scheme won't protect your sources from someone who really wants to read them. On the other hand, shipping just the .pyc/.pyo files will stop casual browsing. The only real difference here is how much effort it takes to get the source. To carry Guido's analogy further, both lock your front door, one just uses a better lock. Neither will stop a determined burglar. On the other hand, if you ship code with a fancy encryption scheme, you're shipping more moving parts, which means more things to go wrong, which means more support calls. With the particular scheme you proposed, you'll get calls from people who managed to run the code without properly setting the environment variable, or set it to the wrong thing, and those are just the obvious problems. In summary, your encryption scheme will make life just a little harder for everyone when compared to simply not shipping the source. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Mike Meyer wrote:
I think Guido's analogy is bogus and wrongly suggests that encrypting applications just might work if you try hard enough. If we can lock the door and keep strangers from peeking inside, why can't we encrypt apps and stop people from peeking at the code? But the analogy doesn't follow. In the front door example, untrusted people don't have a key and are forced to pick or break the lock to get it. In the encryption example, untrusted people are given the key (as an environment variable), then trusted not to use it to read the source code! (Possibly on the assumption that they don't realise they have the key, or that using it manually is too difficult for them.) Ultimately, on a computer the user controls, with a key they have access to, they can bypass any encryption or security you install. That's why e.g. so many forms of copy protection and digital restrictions software try to take control away from the user, to some greater or lesser degree of success. -- Steven
The analogy is you want to protect the doors with a lock from the guy you gave the key. (source: house, encrypted: the lock, the way to decrypt in order to run: the key)
(as an environment variable), then trusted not to use it to read the source
code!
The problem is that he don't trust the customer.
On Sun, May 13, 2012 at 2:36 AM, Steven D'Aprano <steve@pearwood.info> wrote:
I think Guido's analogy is bogus and wrongly suggests that encrypting applications just might work if you try hard enough.
Eh? I didn't mean that at all. To the contrary I meant that every encryption can be broken but that it may still be a useful deterrent. I wasn't aware of the detail of the OP's proposal that the key was right in the user's environment -- but that actually has an exact analogy in the front door example: hiding the key under the mat. -- --Guido van Rossum (python.org/~guido)
On Sun, May 13, 2012 at 11:30 AM, Guido van Rossum <guido@python.org> wrote:
This sounds like an argument not to include this functionality in stdlib. If hiding the key under the mat becomes standard, a key under the mat will be as inviting as an open front door. Those interested in obscurity should not invite public discussion of clandestine advantages of doormats over garden rocks.
On Sun, 13 May 2012 19:36:52 +1000 Steven D'Aprano <steve@pearwood.info> wrote:
But locking the door *won't* keep strangers from peeking inside. Not if they really want to. It'll keep people from casually opening the door, but it won't stop someone who really wants to see the insides because they can:
Exactly. You can easily get tools to do all these things, as well as others, to get past the lock.
This is pretty much required in any form of DRM. You have to give the end user the keys in order for them to use what you gave them. Trying to prevent them from then doing *other* things is done by obfuscating how you get from the cyphertext to the plaintext. That's it can't work is why the US container companies got laws passed making doing so illegal.
(Possibly on the assumption that they don't realise they have the key, or that using it manually is too difficult for them.)
The difficulty level is immaterial. With the proper training and tools, none of these things (picking locks, breaking down doors, reverse engineering code obfuscation) is difficult. On the other hand, you can raise the difficulty level of any of them by investing more in whatever obstacles you're putting in the way. They both do the same thing. That's why the analogy works. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
participants (10)
-
Alexander Belopolsky -
Brett Cannon -
Gabriel AHTUNE -
Guido van Rossum -
Jakob Bowyer -
li wang -
Mathias Panzenböck -
Mike Meyer -
Steven D'Aprano -
Tim Delaney