A ruling in the bnetd DMCA case
A ruling in the bnetd DMCA case
Posted Oct 4, 2004 13:08 UTC (Mon) by arafel (subscriber, #18557)In reply to: A ruling in the bnetd DMCA case by dvdeug
Parent article: A ruling in the bnetd DMCA case
Which is actually not that surprising - including code to verify CD keys would be a help for people mass-generating keys...
(Note that this doesn't mean I think the ruling is any less moronic.)
Posted Oct 4, 2004 14:23 UTC (Mon)
by French_Guest (guest, #16946)
[Link] (2 responses)
But with source, the server owner could simply change the code and recompile it to disable such checks... ;-)
Posted Oct 4, 2004 17:58 UTC (Mon)
by flewellyn (subscriber, #5047)
[Link]
Basically, we're seeing companies use the courts to do the job that should go to real cryptographers.
Posted Oct 5, 2004 8:24 UTC (Tue)
by khim (subscriber, #9252)
[Link]
Unfortunatelly you can not create short activation code this way (short here is 12-24 characters i.e. 72-144bits: enough for symmertic encryption, way too small for assymetric).
Posted Oct 4, 2004 17:12 UTC (Mon)
by arafel (subscriber, #18557)
[Link]
And, as you said - with the source code available people would just remove it anyway. So it's kind of moot anyway.
Wrong. Did you ever hear of assymetric encryption (RSA, etc...) ? A CD key could be implemented as a digital document signature, for example.A ruling in the bnetd DMCA case
Yes, but you're assuming that they did anything that sane. Remember the Elcomsoft case? The encryption that Adobe went to court to defend was a piss-poor implementation of the Caesar shift cypher.A ruling in the bnetd DMCA case
A ruling in the bnetd DMCA case
It could be - but did they? :-) If it's just done as a simple checksum, or XOR/checksum etc. then it becomes much much faster to find valid keys. It depends how they did it in the first place.A ruling in the bnetd DMCA case