Protect Python Source

TuxTrax TuxTrax at fortress.tuxnet.net
Sat Nov 2 08:02:10 EST 2002


On 2 Nov 2002 01:40:22 GMT, Bengt Richter Wrote in
Steve Ballmers hair grease:

> On Fri, 01 Nov 2002 08:57:35 GMT, Alex Martelli <aleax at aleax.it> wrote:
> [...]
>>
>>It is conceptually impossible to stop a halfway-competent 'cracker'
>>from disassembling any compiled form of your program if they have
>>any interest at all in it (or even if they don't: they DO do it just
>>for fun even for programs they have no earthly use for), as long as
>>you distribute your program in a fully executable form for general
>>purpose computers.  If the GP computer can get at your program, as
>>it must to be able to execute it, so can the cracker.  In some cases
>>you may be able to achieve a measure of protection if your program
>>can only execute when connected to some Internet site: in that kind
>>of scenario, you may be able to check that connections only come
>>from validly registered sites.  But in general, you should rely on
>>the law to protect your programs against unauthorized use, not on
>>illusory "protection".  "Security through obscurity isn't".
> 
> I am afraid that the "GP computer" will soon have right in the CPU chip
> the microcoded ability to input a byte stream from memory that is
> digitally signed and encrypted with the CPU's public key, and
> decrypt it into an on-chip cache memory that never gets written to
> RAM (or if it does, through an xor prng encryption mask), and execute it.
> 
> I think they're moving the concept of a computer receiving trusted code
> securely over an insecure network to a concept where the CPU chip
> looks at the motherboard as part of the insecure network.
> 
> It's not a big conceptual leap. The details are just a bunch of engineering.
> (However, no doubt this simple conceptual move from computer to CPU chip
> will be loaded with patents on obvious ideas that have been in place in
> bigger contexts for ages).
> 
> I think you can resign yourself to the idea that it will eventually
> become as hard to decrypt a private message to a CPU as it is to do
> the same to a PGP-encrypted email message to you. The message will
> only be opened on-chip, using the chip's private key. It'll execute
> as written or it won't execute at all. Either way only the CPU will see it.
> 
> Obviously you have to build stuff into an OS to make use of this stuff,
> and no doubt it will start with the BIOS below that.
> 
> There will be a lot of opportunities to form exclusive clubs of hardware
> and software vendors. Even if the technology itself is as open and royalty-free
> as PGP, so that Linux/BSD/etc can also use it for bullet-proofing, it could mean
> that the latter will not be able to interoperate except when others choose,
> unless non-exclusion is guaranteed by laws with really big teeth.
> 
> The technology is neutral, but the temptations it affords are not.
> Oh well, I guess it's all part of economic evolution, moving from
> selling atoms to selling bits to selling permission ;-/
> 
> Regards,
> Bengt Richter

I'll take an order of Palladium with a side of tyrrany.

http://www.epic.org/privacy/consumer/microsoft/palladium.html

Cheers,

Mathew

-- 
My Family is Microsoft Free. Running Mandrake Linux 8.0 kernel 2.4.3-20
I use quality open source software alternatives on my PC.

Yes, I am a Penguin cult high priest. Flipper readings upon request.

ROT13 this email address to mail me:
bar jbeq abg guerr - uvtu qrfreg zna, ng lnubb qbg pbz




More information about the Python-list mailing list