[Python-ideas] [Python-Dev] Proposal : Python Trusted Computing API

[geremy condra]

On Tue, Oct 20, 2009 at 6:56 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Ben Finney wrote:
>> geremy condra <debatem1 at gmail.com> writes:
>>
>>> 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.
>>
>> 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.
>
> 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.

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.

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

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.

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

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