Actually the program is dynamically encrypted with a new key each time.
Intefering with memory buffers causes the kernel to delete the program, Key is sent over VPN, tampering with the kernel causes
the MD5 hash to be incorrect, and key isn't sent, DRM self scans itself, MD5 hash sums are made on the sources and DRM will
dynamically recompile itself every 32 seconds, checking the sources.
USER key is dynamic, with a different key for every program,
using email to verify said key.
*GASP* for breath :)
May I note this can make sure GPL is followed as well as proprietary rules...
> > [[email protected]]said:
> Two more problems:
>
> 1) In this case the decryption key is an intergral part of the software
> and as such needs to be supplied as per fair use clauses.
>
> 2) Alan's argument stands. It is possible to fake the server and provide
> the key once the user have pinched a working copy. The wrapper can be
> reverse-engineered for communication key magics if need be.
>
> --
> Tomas Szepe <[email protected]>
--
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr
Powered by Outblaze
Hi Dean.
> ...and DRM will dynamically recompile itself every 32 seconds...
...and thus will spend so much time recompiling itself that there
is no time to do anything else (since it will inevitably take 33
seconds to actually perform the compilation).
Personally, I see DRM as the best thing Microsoft could take under
their wings, as it's an almost sure-fire bet that any company that
whole-heartedly embraces it will soon go bust...
Best wishes from Riley.
---
* Nothing as pretty as a smile, nothing as ugly as a frown.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.481 / Virus Database: 277 - Release Date: 13-May-2003
On Thu, May 15, 2003 at 10:44:58AM +0000, Dean McEwan wrote:
> Actually the program is dynamically encrypted with a new key each time.
Yeah, whatever
> Intefering with memory buffers causes the kernel to delete the
> program, Key is sent over VPN, tampering with the kernel causes the
> MD5 hash to be incorrect,
Who sends the now-incorrect MD5? The kernel? But since it's been
tampered with, how do you know it sends the trust now-incorrect MD5 sum,
instead of a copy of the original MD5 sum?
> and key isn't sent, DRM self scans itself,
What for?
If DRM is tampered with, making it scan itself is pretty useless - once
it has been tampered with, it can no longer be trusted to perform the
self scan. In other words, such self-scanning is fundamentally flawed.
Read "The inevitability of failure" - pay special attention to the fact
that they *never* recommend anything like self-scanning, but rather
focus on mechanisms to ensure that whatever it was you wanted to
self-scan could never have been tampered with in the first place (thus
making the self-scanning that can't work anyway, a non-issue).
http://www.nsa.gov/selinux/inevit-abs.html
> MD5 hash sums are made on the sources and DRM will dynamically
> recompile itself every 32 seconds, checking the sources.
... using which compiler ?
... compiled using which compiler ?
Nevermind that - you don't need to answer.
Read "Reflections on trusting trust" by Ken R.
http://cm.bell-labs.com/who/ken/trust.html
Your idea is fundamentally flawed. You can always add more layers of
self-checking-self-checkers, but this does not change the fact that the
idea is fundamentally flawed.
I'm sorry - it's not that I don't like you or anything like that - but
the idea is stupid, just give it up :)
--
................................................................
: [email protected] : And I see the elder races, :
:.........................: putrid forms of man :
: Jakob ?stergaard : See him rise and claim the earth, :
: OZ9ABN : his downfall is at hand. :
:.........................:............{Konkhra}...............: