Re: [Python-ideas] [Python-Dev] Proposal : Python Trusted Computing API
On Mon, Oct 19, 2009 at 2:29 AM, Abhiram Kasina <abhiram.casina@gmail.com> wrote:
I personally have grave concerns about this technology, independent of who is advancing it- just reading the links you provide makes it clear that its primary purpose is to restrict the degree of control a user can exercise over their own data, programs, and machine. Is it any wonder that the same people who find DRM abhorrent find the technologies used to advance it equally distasteful?
But personally I think its a good idea from security point of view.
Besides sealed storage and memory curtaining- which I admit have seductive security implications- all of the supposed advantages of a TPM can be replicated using non-interactive zero knowledge proofs. I'd rather we put that capability into the standard library- but I strongly doubt that's going to happen any time soon.
I also suspect that if this were a simple undertaking, there wouldn't be a 'we' in this sentence.
If you were suggesting adding a crypto API to python, I'd be all for it- but you're suggesting adding the ability to have Python software vendors remotely cripple the code on your machine. I just can't get behind that, and while you're sure to hear wildly divergent opinions on this board, I suspect that mine will not be an uncommon sentiment. Geremy Condra
geremy condra <debatem1@gmail.com> writes:
Agreed. Though I don't draw much water here, being a Python user rather than a core developer, I totally agree that technologies to subvert an owner's control over the behaviour of their own machine are anathema to a free culture. Such technologies are to be resisted, and they shall not get a jot of my support in any form if I can help it. -- \ “As the most participatory form of mass speech yet developed, | `\ the Internet deserves the highest protection from governmental | _o__) intrusion.” —U.S. District Court Judge Dalzell | Ben Finney
Ben Finney wrote:
Such techologies are actually fairly pointless, as giving both a secret and a key to that secret to the same party and expecting the secret to stay that way is completely missing the point of how crypto works. You can make it difficult for the user to acquire the secret, but there are just too many attack vectors to keep *everyone* out, and once one person breaks it, the wonders of the internet mean that pretty much everyone else can break it as well. The ease with which even Python bytecode can be monkey-patched at run time to null out the trusted API calls is likely to make such an undertaking in Python even more pointless than usual. Regardless, the answer I gave on python-dev stands: this has nothing to do with Python as a language or the standard library. The OP is free to develop whatever Python extension libraries they like and see if they can attract much outside interest. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
On Tue, Oct 20, 2009 at 6:56 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
It's sometimes called the "third law of cryptography": that there is no cryptographic solution to the problem in which the attacker and intended recipient are the same person. Unfortunately, TPMs get to bend the rules a little bit using the same technique I mentioned above- zero knowledge proofs. Ultimately, it means that it is possible to build repudiation schemes which do not leak keying data even in a system that is 100% observable, although it does so at the expense of significant overhead and a loss of flexibility.
This is one of the reasons I suspect there was a 'we' in the 'we should build an API': it would require vast and neverending support in python core in order to enforce the demands of the TPM.
Unfortunately, as I said above, it does- in order to make it work, the OP would need support from core. I very much hope that support won't develop. Geremy Condra
geremy condra <debatem1@gmail.com> writes:
Agreed. Though I don't draw much water here, being a Python user rather than a core developer, I totally agree that technologies to subvert an owner's control over the behaviour of their own machine are anathema to a free culture. Such technologies are to be resisted, and they shall not get a jot of my support in any form if I can help it. -- \ “As the most participatory form of mass speech yet developed, | `\ the Internet deserves the highest protection from governmental | _o__) intrusion.” —U.S. District Court Judge Dalzell | Ben Finney
Ben Finney wrote:
Such techologies are actually fairly pointless, as giving both a secret and a key to that secret to the same party and expecting the secret to stay that way is completely missing the point of how crypto works. You can make it difficult for the user to acquire the secret, but there are just too many attack vectors to keep *everyone* out, and once one person breaks it, the wonders of the internet mean that pretty much everyone else can break it as well. The ease with which even Python bytecode can be monkey-patched at run time to null out the trusted API calls is likely to make such an undertaking in Python even more pointless than usual. Regardless, the answer I gave on python-dev stands: this has nothing to do with Python as a language or the standard library. The OP is free to develop whatever Python extension libraries they like and see if they can attract much outside interest. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
On Tue, Oct 20, 2009 at 6:56 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
It's sometimes called the "third law of cryptography": that there is no cryptographic solution to the problem in which the attacker and intended recipient are the same person. Unfortunately, TPMs get to bend the rules a little bit using the same technique I mentioned above- zero knowledge proofs. Ultimately, it means that it is possible to build repudiation schemes which do not leak keying data even in a system that is 100% observable, although it does so at the expense of significant overhead and a loss of flexibility.
This is one of the reasons I suspect there was a 'we' in the 'we should build an API': it would require vast and neverending support in python core in order to enforce the demands of the TPM.
Unfortunately, as I said above, it does- in order to make it work, the OP would need support from core. I very much hope that support won't develop. Geremy Condra
participants (4)
-
Ben Finney -
geremy condra -
Mathias Panzenböck -
Nick Coghlan