Injunction Against 2600 for DeCSS

Vito writes "Figures. Mitnick's free, but now a federal court has issued a preliminary injunction against the 2600 website, and its webmasters have been threatened with immediate imprisonment, over the distribution of the DeCSS source code. Time to start that data haven." This is just the latest in the DeCSS fiasco, and it certainly won't be the last. The difference between this and the DVD CCA battle is that these are federal court cases, which is why terms like 'immediate imprisonment' are being tossed around.

Comments

This will never get read, but...

[Booker]

Too far down the message chain to be read, I suppose, but some of the defendants in this case were NOT smart about the whole thing, and hurt the cause, I believe. Take, for example "www.dvd-copy.com" which tells you "What you need to trade Moviez online" and "Bastard Greedy Companies - eBOMB their servers!" and "Yes, you can trade DVD movie files over the Internet . . . You can break the encryption on any DVD and allow users to copy the contents of a DVD onto the a [sic] hard drive or alternative media! Notice: The DVD Copy Control Association are cocksuckers!"

This doesn't help. Sounds like the judge never gave the defendants a chance (with comments to the plaintiffs along the lines of "I can give you a runaway train on this one, if you'd like" - see http://jya.com/crypto.htm ) but the quotes above are not the way to go. The whole argument is that CSS is not copy protection, that DeCSS is not intended for privacy, etc, loses credibility due to sites like dvd-copy.com. I actually *support* this type of action against people who are proponents of illegally trading copyrighted material on the DVDs, because it hurts legitimate organizations like LiViD.
----

another idea.

[mcc]

i was posting something last month suggesting we start some kind of blue ribbon campaign-style thing, where everyone put up a little logo image and a mirror of decss.

someone [no idea who] replied by pointing out a simpler alternative: simply use the standard GIF comment blocks to distribute the DeCSS code. Distribute a GIF banner image type thing with the DeCSS code in it and have people put it on pages.
everyone who visits the page breaks the law.. -_-
i'd link to the discussion, but it's long gone now.

Now take a moment to remember Martin Luther King Jr., and what he said about peaceful civil disobedience to facilitate change of an immoral system of law..

-mcc
INTELLECTUAL PROPERTY IS THEFT

ok, i did it.. here it is.

[mcc]

http://drowned.cx/decss/

well.. i don't know if i like how these came out, but here they are. I went ahead and made them for some reason. I don't really like what they say. "This GIF is illegal" maybe isn't the best way to put it. I'm not quite sure. And it may or may not be true depending on your definition of "illegal". (And they maybe oughta have the LZW compression removed via ungif, just so we can all have rhetorical purity. :P)

The idea behind these images (spread public awareness, a la the blue ribbon campaign) only works if it's somehow centralised-- i mean, if images like these wind up in widespread usage, any usage of them should link to some central page that explains what the MPAA is doing and why it's wrong. In which case the "this gif is illegal" should be added to with "click here to find out why". From there it could probably explain what source code is, why it should be considered speech, the purpose of DeCSS, the purpose of CSS, the reason DeCSS does not help piracy (seeing as you can pirate DVDs just as easily without DeCSS just by copying the dvd without decoding or writing a fake video driver before playing it in windows), the reason the MPAA/DVD forum brought this on themselves (by refusal to give any support the unices, the one group most likely to understand how to reverse-engineer), the constitutionality of the Digital Millineum Copyright act with regards to the first amendment and the copyright clause of the constitution, and how the DVD forum in general is basically trying to prevent the spread of information. Y'know, how they are absusing the legal system to try to prevent people from distributing information about how to defeat a copyright protection measure (which sounds to me like it should be covered by freedom of speech and freedom of the press, even if said speech is in the language of C++ and said press is printing on TCP/IP packets instead of paper), or even distributing the location [URLs, links] of that information (which i know is speech, and which there is no basis whatsoever to prevent talking about.) Oh, and maybe some stuff thrown in about monopolies, the sherman antitrust act, and the fact that crushing DeCSS is clearly not to prevent piracy and protect the MPAAs profits and help the artists involved, but simply to preserve the MPAA's power as a political entity/robber baron. And everything else i forgot; what the MPAA/DVD forum is doing is wrong on so many levels you could go on for pages about it. We know all this already, you could do it solely based on compiling slashdot posts, i could write it myself if i weren't so damned tired and i didn't have to go to bed so i can take the SATs tomorrow.

As for the GIFs themselves, the kind of murky colored stuff in the background is actually the DeCSS code itself, with the ASCII interpreted as raw color values. Kinda nifty how the hex values at the end come out as just patterns of lines. On the big one i enlarged it and blurred it over a bit to fit more text, but i wouldn't use that one if i were you cuz the file size is unneccicarily large (like 40k.. i think it's better as small as possible). As promised, both contain the entire source code to DeCSS in their comment fields. If you feel like it (hell, do whatever you want-- they contain GPLed code, so they're GPLed images, so i have no control over what you do with them :) ) you can go ahead and put either on any web page you may have with a little note about how the person viewing the page has just broken the law by storing illegal information about defeating copy protection in their browser caches. But, i still think this needs to be more organized.

Please excuse the poor writing in this post. As i said, i am tired.

making keys analogy not valid

[sbwoodside]

From the MPAA's Jan 14 press release:

"This is a case of theft. The posting of the de-encryption formula is no different from making and then distributing unauthorized keys to a department store. The keys have no real purpose except to circumvent the locks that stand between the thief and the goods he or she targets."

It's not a valid analogy. It would be more appropriate to compare DeCSS to a set of lockpicks. Lockpicks are legal to buy and to use in your own home. The only thing that's illegal is when you use them to break into someone else's house.

Similarly, DeCSS should be legal for distribution and personal use. The only thing that should be illegal about DeCSS is using it to crack DVDs you don't own for personal gain.

Simon

Call the MPAA and give them your thoughts

[SgtPepper]

Main Office Address:

Motion Picture Association of America
(MPAA)
Motion Picture Association (MPA)

15503 Ventura Blvd.
Encino, California 91436
(818) 995-6600

*out*

A copy of my email to 2600

[XenoWolf]

Here's a copy of what I sent to the 2600 guys. What do you guys think? Is my logic correct?
---begin quote---
- From the injunction:

3. Certain terms use in this order are defined as follows:

(a) "DVD" means digital versatile disc.

(b) "CSS" means the Contents Scramble System used to encrypt,

scramble or otherwise protect the contents of certain DVDs from being

copied.

(c) "DeCSS" means any computer program, file or device that may be

used to decrypt or unscramble the contents of DVDs that are protected, or

otherwise to circumvent the protection afforded, by CSS and that permits the

copying of the contents or any portion thereof.


Under the above restraining order, *any* product that can decrypt CSS
and play back its contents is so termed "DeCSS" which means that all
hardware DVD players are "DeCSS" and thus must not be distributed.
Likewise, under this injunction, it seems that Xing, Creative, et.
al. cannot distribute their software DVD players.

For example, my Philips set top DVD player:

1. is a device
2. decrypts CSS encoded DVDs
3. plays them back over a unencrypted output ( the video/audio
connections ), thus allowing me to copy them to any device that
accepts video input e.g. my RCA VCR, my computer via my Pinnacle DC30
capture card, et. al.

and thus , being that it fits the description in 3.(c), is "DeCSS"

Hmmm. Interesting, eh? Contact Circuit City and tell them to cease
and desist selling all DVD players that putput an unencrypted video
feed, otherwise they are violating the restraining order. You might
want to forward this insight on to whoever at the EFF is doing their
defense. This is way too wide and could be overturned quite easily on
the basis that this document includes the licensees of the CSS
decryption method present in DVD players and software.

*Disclaimer*: I am not a lawyer. I never will be. I just thought
through this logically, and saw a large hole.

See Ya
----end quote----

Re:Whacking the mole

[fatboy]

Is this what all the fuss is about??? Sure looks like speech to me ;)


/*
* Copyright (C) 1999 Derek Fawcus
*
* This code may be used under the terms of Version 2 of the GPL,
* read the file COPYING for details.
*
*/

/*
* These routines do some reordering of the supplied data before
* calling engine() to do the main work.
*
* The reordering seems similar to that done by the initial stages of
* the DES algorithm, in that it looks like it's just been done to
* try and make software decoding slower. I'm not sure that it
* actually adds anything to the security.
*
* The nature of the shuffling is that the bits of the supplied
* parameter 'varient' are reorganised (and some inverted), and
* the bytes of the parameter 'challenge' are reorganised.
*
* The reorganisation in each routine is different, and the first
* (CryptKey1) does not bother of play with the 'varient' parameter.
*
* Since this code is only run once per disk change, I've made the
* code table driven in order to improve readability.
*
* Since these routines are so similar to each other, one could even
* abstract them all to one routine supplied a parameter determining
* the nature of the reordering it has to do.
*/

#include "css-auth.h"

typedef unsigned long u32;

static void engine(int varient, byte const *input, struct block *output);

void CryptKey1(int varient, byte const *challenge, struct block *key)
{
static byte perm_challenge[] = {1,3,0,7,5, 2,9,6,4,8};

byte scratch[10];
int i;

for (i = 9; i >= 0; --i)
scratch[i] = challenge[perm_challenge[i]];

engine(varient, scratch, key);
}

/* This shuffles the bits in varient to make perm_varient such that
* 4 -> !3
* 3 -> 4
* varient bits: 2 -> 0 perm_varient bits
* 1 -> 2
* 0 -> !1
*/
void CryptKey2(int varient, byte const *challenge, struct block *key)
{
static byte perm_challenge[] = {6,1,9,3,8, 5,7,4,0,2};

static byte perm_varient[] = {
0x0a, 0x08, 0x0e, 0x0c, 0x0b, 0x09, 0x0f, 0x0d,
0x1a, 0x18, 0x1e, 0x1c, 0x1b, 0x19, 0x1f, 0x1d,
0x02, 0x00, 0x06, 0x04, 0x03, 0x01, 0x07, 0x05,
0x12, 0x10, 0x16, 0x14, 0x13, 0x11, 0x17, 0x15};

byte scratch[10];
int i;

for (i = 9; i >= 0; --i)
scratch[i] = challenge[perm_challenge[i]];

engine(perm_varient[varient], scratch, key);
}

/* This shuffles the bits in varient to make perm_varient such that
* 4 -> 0
* 3 -> !1
* varient bits: 2 -> !4 perm_varient bits
* 1 -> 2
* 0 -> 3
*/
void CryptBusKey(int varient, byte const *challenge, struct block *key)
{
static byte perm_challenge[] = {4,0,3,5,7, 2,8,6,1,9};
static byte perm_varient[] = {
0x12, 0x1a, 0x16, 0x1e, 0x02, 0x0a, 0x06, 0x0e,
0x10, 0x18, 0x14, 0x1c, 0x00, 0x08, 0x04, 0x0c,
0x13, 0x1b, 0x17, 0x1f, 0x03, 0x0b, 0x07, 0x0f,
0x11, 0x19, 0x15, 0x1d, 0x01, 0x09, 0x05, 0x0d};

byte scratch[10];
int i;

for (i = 9; i >= 0; --i)
scratch[i] = challenge[perm_challenge[i]];

engine(perm_varient[varient], scratch, key);
}

/*
* We use two LFSR's (seeded from some of the input data bytes) to
* generate two streams of pseudo-random bits. These two bit streams
* are then combined by simply adding with carry to generate a final
* sequence of pseudo-random bits which is stored in the buffer that
* 'output' points to the end of - len is the size of this buffer.
*
* The first LFSR is of degree 25, and has a polynomial of:
* x^13 + x^5 + x^4 + x^1 + 1
*
* The second LSFR is of degree 17, and has a (primitive) polynomial of:
* x^15 + x^1 + 1
*
* I don't know if these polynomials are primitive modulo 2, and thus
* represent maximal-period LFSR's.
*
*
* Note that we take the output of each LFSR from the new shifted in
* bit, not the old shifted out bit. Thus for ease of use the LFSR's
* are implemented in bit reversed order.
*
*/
static void generate_bits(byte *output, int len, struct block const *s)
{
u32 lfsr0, lfsr1;
byte carry;

/* In order to ensure that the LFSR works we need to ensure that the
* initial values are non-zero. Thus when we initialise them from
* the seed, we ensure that a bit is set.
*/
lfsr0 = (s->b[0] b[1] b[2] & ~7) b[2] & 7);
lfsr1 = (s->b[3] b[4];

++output;

carry = 0;
do {
int bit;
byte val;

for (bit = 0, val = 0; bit > 24) ^ (lfsr0 >> 21) ^ (lfsr0 >> 20) ^ (lfsr0 >> 12)) & 1;
lfsr0 = (lfsr0 > 16) ^ (lfsr1 >> 2)) & 1;
lfsr1 = (lfsr1 > 1) & 1)

combined = !o_lfsr1 + carry + !o_lfsr0;
carry = BIT1(combined);
val |= BIT0(combined) 0);
}

static byte Secret[];
static byte Varients[];
static byte Table0[];
static byte Table1[];
static byte Table2[];
static byte Table3[];

/*
* This encryption engine implements one of 32 variations
* one the same theme depending upon the choice in the
* varient parameter (0 - 31).
*
* The algorithm itself manipulates a 40 bit input into
* a 40 bit output.
* The parameter 'input' is 80 bits. It consists of
* the 40 bit input value that is to be encrypted followed
* by a 40 bit seed value for the pseudo random number
* generators.
*/
static void engine(int varient, byte const *input, struct block *output)
{
byte cse, term, index;
struct block temp1;
struct block temp2;
byte bits[30];

int i;

/* Feed the secret into the input values such that
* we alter the seed to the LFSR's used above, then
* generate the bits to play with.
*/
for (i = 5; --i >= 0; )
temp1.b[i] = input[5 + i] ^ Secret[i] ^ Table2[i];

generate_bits(&bits[29], sizeof bits, &temp1);

/* This term is used throughout the following to
* select one of 32 different variations on the
* algorithm.
*/
cse = Varients[varient] ^ Table2[varient];

/* Now the actual blocks doing the encryption. Each
* of these works on 40 bits at a time and are quite
* similar.
*/
for (i = 5, term = 0; --i >= 0; term = input[i]) {
index = bits[25 + i] ^ input[i];
index = Table1[index] ^ ~Table2[index] ^ cse;

temp1.b[i] = Table2[index] ^ Table3[index] ^ term;
}
temp1.b[4] ^= temp1.b[0];

for (i = 5, term = 0; --i >= 0; term = temp1.b[i]) {
index = bits[20 + i] ^ temp1.b[i];
index = Table1[index] ^ ~Table2[index] ^ cse;

temp2.b[i] = Table2[index] ^ Table3[index] ^ term;
}
temp2.b[4] ^= temp2.b[0];

for (i = 5, term = 0; --i >= 0; term = temp2.b[i]) {
index = bits[15 + i] ^ temp2.b[i];
index = Table1[index] ^ ~Table2[index] ^ cse;
index = Table2[index] ^ Table3[index] ^ term;

temp1.b[i] = Table0[index] ^ Table2[index];
}
temp1.b[4] ^= temp1.b[0];

for (i = 5, term = 0; --i >= 0; term = temp1.b[i]) {
index = bits[10 + i] ^ temp1.b[i];
index = Table1[index] ^ ~Table2[index] ^ cse;

index = Table2[index] ^ Table3[index] ^ term;

temp2.b[i] = Table0[index] ^ Table2[index];
}
temp2.b[4] ^= temp2.b[0];

for (i = 5, term = 0; --i >= 0; term = temp2.b[i]) {
index = bits[5 + i] ^ temp2.b[i];
index = Table1[index] ^ ~Table2[index] ^ cse;

temp1.b[i] = Table2[index] ^ Table3[index] ^ term;
}
temp1.b[4] ^= temp1.b[0];

for (i = 5, term = 0; --i >= 0; term = temp1.b[i]) {
index = bits[i] ^ temp1.b[i];
index = Table1[index] ^ ~Table2[index] ^ cse;

output->b[i] = Table2[index] ^ Table3[index] ^ term;
}
}

static byte Varients[] = {
0xB7, 0x74, 0x85, 0xD0, 0xCC, 0xDB, 0xCA, 0x73,
0x03, 0xFE, 0x31, 0x03, 0x52, 0xE0, 0xB7, 0x42,
0x63, 0x16, 0xF2, 0x2A, 0x79, 0x52, 0xFF, 0x1B,
0x7A, 0x11, 0xCA, 0x1A, 0x9B, 0x40, 0xAD, 0x01};

static byte Secret[] = {0x55, 0xD6, 0xC4, 0xC5, 0x28};

static byte Table0[] = {
0xB7, 0xF4, 0x82, 0x57, 0xDA, 0x4D, 0xDB, 0xE2,
0x2F, 0x52, 0x1A, 0xA8, 0x68, 0x5A, 0x8A, 0xFF,
0xFB, 0x0E, 0x6D, 0x35, 0xF7, 0x5C, 0x76, 0x12,
0xCE, 0x25, 0x79, 0x29, 0x39, 0x62, 0x08, 0x24,
0xA5, 0x85, 0x7B, 0x56, 0x01, 0x23, 0x68, 0xCF,
0x0A, 0xE2, 0x5A, 0xED, 0x3D, 0x59, 0xB0, 0xA9,
0xB0, 0x2C, 0xF2, 0xB8, 0xEF, 0x32, 0xA9, 0x40,
0x80, 0x71, 0xAF, 0x1E, 0xDE, 0x8F, 0x58, 0x88,
0xB8, 0x3A, 0xD0, 0xFC, 0xC4, 0x1E, 0xB5, 0xA0,
0xBB, 0x3B, 0x0F, 0x01, 0x7E, 0x1F, 0x9F, 0xD9,
0xAA, 0xB8, 0x3D, 0x9D, 0x74, 0x1E, 0x25, 0xDB,
0x37, 0x56, 0x8F, 0x16, 0xBA, 0x49, 0x2B, 0xAC,
0xD0, 0xBD, 0x95, 0x20, 0xBE, 0x7A, 0x28, 0xD0,
0x51, 0x64, 0x63, 0x1C, 0x7F, 0x66, 0x10, 0xBB,
0xC4, 0x56, 0x1A, 0x04, 0x6E, 0x0A, 0xEC, 0x9C,
0xD6, 0xE8, 0x9A, 0x7A, 0xCF, 0x8C, 0xDB, 0xB1,
0xEF, 0x71, 0xDE, 0x31, 0xFF, 0x54, 0x3E, 0x5E,
0x07, 0x69, 0x96, 0xB0, 0xCF, 0xDD, 0x9E, 0x47,
0xC7, 0x96, 0x8F, 0xE4, 0x2B, 0x59, 0xC6, 0xEE,
0xB9, 0x86, 0x9A, 0x64, 0x84, 0x72, 0xE2, 0x5B,
0xA2, 0x96, 0x58, 0x99, 0x50, 0x03, 0xF5, 0x38,
0x4D, 0x02, 0x7D, 0xE7, 0x7D, 0x75, 0xA7, 0xB8,
0x67, 0x87, 0x84, 0x3F, 0x1D, 0x11, 0xE5, 0xFC,
0x1E, 0xD3, 0x83, 0x16, 0xA5, 0x29, 0xF6, 0xC7,
0x15, 0x61, 0x29, 0x1A, 0x43, 0x4F, 0x9B, 0xAF,
0xC5, 0x87, 0x34, 0x6C, 0x0F, 0x3B, 0xA8, 0x1D,
0x45, 0x58, 0x25, 0xDC, 0xA8, 0xA3, 0x3B, 0xD1,
0x79, 0x1B, 0x48, 0xF2, 0xE9, 0x93, 0x1F, 0xFC,
0xDB, 0x2A, 0x90, 0xA9, 0x8A, 0x3D, 0x39, 0x18,
0xA3, 0x8E, 0x58, 0x6C, 0xE0, 0x12, 0xBB, 0x25,
0xCD, 0x71, 0x22, 0xA2, 0x64, 0xC6, 0xE7, 0xFB,
0xAD, 0x94, 0x77, 0x04, 0x9A, 0x39, 0xCF, 0x7C};

static byte Table1[] = {
0x8C, 0x47, 0xB0, 0xE1, 0xEB, 0xFC, 0xEB, 0x56,
0x10, 0xE5, 0x2C, 0x1A, 0x5D, 0xEF, 0xBE, 0x4F,
0x08, 0x75, 0x97, 0x4B, 0x0E, 0x25, 0x8E, 0x6E,
0x39, 0x5A, 0x87, 0x53, 0xC4, 0x1F, 0xF4, 0x5C,
0x4E, 0xE6, 0x99, 0x30, 0xE0, 0x42, 0x88, 0xAB,
0xE5, 0x85, 0xBC, 0x8F, 0xD8, 0x3C, 0x54, 0xC9,
0x53, 0x47, 0x18, 0xD6, 0x06, 0x5B, 0x41, 0x2C,
0x67, 0x1E, 0x41, 0x74, 0x33, 0xE2, 0xB4, 0xE0,
0x23, 0x29, 0x42, 0xEA, 0x55, 0x0F, 0x25, 0xB4,
0x24, 0x2C, 0x99, 0x13, 0xEB, 0x0A, 0x0B, 0xC9,
0xF9, 0x63, 0x67, 0x43, 0x2D, 0xC7, 0x7D, 0x07,
0x60, 0x89, 0xD1, 0xCC, 0xE7, 0x94, 0x77, 0x74,
0x9B, 0x7E, 0xD7, 0xE6, 0xFF, 0xBB, 0x68, 0x14,
0x1E, 0xA3, 0x25, 0xDE, 0x3A, 0xA3, 0x54, 0x7B,
0x87, 0x9D, 0x50, 0xCA, 0x27, 0xC3, 0xA4, 0x50,
0x91, 0x27, 0xD4, 0xB0, 0x82, 0x41, 0x97, 0x79,
0x94, 0x82, 0xAC, 0xC7, 0x8E, 0xA5, 0x4E, 0xAA,
0x78, 0x9E, 0xE0, 0x42, 0xBA, 0x28, 0xEA, 0xB7,
0x74, 0xAD, 0x35, 0xDA, 0x92, 0x60, 0x7E, 0xD2,
0x0E, 0xB9, 0x24, 0x5E, 0x39, 0x4F, 0x5E, 0x63,
0x09, 0xB5, 0xFA, 0xBF, 0xF1, 0x22, 0x55, 0x1C,
0xE2, 0x25, 0xDB, 0xC5, 0xD8, 0x50, 0x03, 0x98,
0xC4, 0xAC, 0x2E, 0x11, 0xB4, 0x38, 0x4D, 0xD0,
0xB9, 0xFC, 0x2D, 0x3C, 0x08, 0x04, 0x5A, 0xEF,
0xCE, 0x32, 0xFB, 0x4C, 0x92, 0x1E, 0x4B, 0xFB,
0x1A, 0xD0, 0xE2, 0x3E, 0xDA, 0x6E, 0x7C, 0x4D,
0x56, 0xC3, 0x3F, 0x42, 0xB1, 0x3A, 0x23, 0x4D,
0x6E, 0x84, 0x56, 0x68, 0xF4, 0x0E, 0x03, 0x64,
0xD0, 0xA9, 0x92, 0x2F, 0x8B, 0xBC, 0x39, 0x9C,
0xAC, 0x09, 0x5E, 0xEE, 0xE5, 0x97, 0xBF, 0xA5,
0xCE, 0xFA, 0x28, 0x2C, 0x6D, 0x4F, 0xEF, 0x77,
0xAA, 0x1B, 0x79, 0x8E, 0x97, 0xB4, 0xC3, 0xF4};

static byte Table2[] = {
0xB7, 0x75, 0x81, 0xD5, 0xDC, 0xCA, 0xDE, 0x66,
0x23, 0xDF, 0x15, 0x26, 0x62, 0xD1, 0x83, 0x77,
0xE3, 0x97, 0x76, 0xAF, 0xE9, 0xC3, 0x6B, 0x8E,
0xDA, 0xB0, 0x6E, 0xBF, 0x2B, 0xF1, 0x19, 0xB4,
0x95, 0x34, 0x48, 0xE4, 0x37, 0x94, 0x5D, 0x7B,
0x36, 0x5F, 0x65, 0x53, 0x07, 0xE2, 0x89, 0x11,
0x98, 0x85, 0xD9, 0x12, 0xC1, 0x9D, 0x84, 0xEC,
0xA4, 0xD4, 0x88, 0xB8, 0xFC, 0x2C, 0x79, 0x28,
0xD8, 0xDB, 0xB3, 0x1E, 0xA2, 0xF9, 0xD0, 0x44,
0xD7, 0xD6, 0x60, 0xEF, 0x14, 0xF4, 0xF6, 0x31,
0xD2, 0x41, 0x46, 0x67, 0x0A, 0xE1, 0x58, 0x27,
0x43, 0xA3, 0xF8, 0xE0, 0xC8, 0xBA, 0x5A, 0x5C,
0x80, 0x6C, 0xC6, 0xF2, 0xE8, 0xAD, 0x7D, 0x04,
0x0D, 0xB9, 0x3C, 0xC2, 0x25, 0xBD, 0x49, 0x63,
0x8C, 0x9F, 0x51, 0xCE, 0x20, 0xC5, 0xA1, 0x50,
0x92, 0x2D, 0xDD, 0xBC, 0x8D, 0x4F, 0x9A, 0x71,
0x2F, 0x30, 0x1D, 0x73, 0x39, 0x13, 0xFB, 0x1A,
0xCB, 0x24, 0x59, 0xFE, 0x05, 0x96, 0x57, 0x0F,
0x1F, 0xCF, 0x54, 0xBE, 0xF5, 0x06, 0x1B, 0xB2,
0x6D, 0xD3, 0x4D, 0x32, 0x56, 0x21, 0x33, 0x0B,
0x52, 0xE7, 0xAB, 0xEB, 0xA6, 0x74, 0x00, 0x4C,
0xB1, 0x7F, 0x82, 0x99, 0x87, 0x0E, 0x5E, 0xC0,
0x8F, 0xEE, 0x6F, 0x55, 0xF3, 0x7E, 0x08, 0x90,
0xFA, 0xB6, 0x64, 0x70, 0x47, 0x4A, 0x17, 0xA7,
0xB5, 0x40, 0x8A, 0x38, 0xE5, 0x68, 0x3E, 0x8B,
0x69, 0xAA, 0x9B, 0x42, 0xA5, 0x10, 0x01, 0x35,
0xFD, 0x61, 0x9E, 0xE6, 0x16, 0x9C, 0x86, 0xED,
0xCD, 0x2E, 0xFF, 0xC4, 0x5B, 0xA0, 0xAE, 0xCC,
0x4B, 0x3B, 0x03, 0xBB, 0x1C, 0x2A, 0xAC, 0x0C,
0x3F, 0x93, 0xC7, 0x72, 0x7A, 0x09, 0x22, 0x3D,
0x45, 0x78, 0xA9, 0xA8, 0xEA, 0xC9, 0x6A, 0xF7,
0x29, 0x91, 0xF0, 0x02, 0x18, 0x3A, 0x4E, 0x7C};

static byte Table3[] = {
0x73, 0x51, 0x95, 0xE1, 0x12, 0xE4, 0xC0, 0x58,
0xEE, 0xF2, 0x08, 0x1B, 0xA9, 0xFA, 0x98, 0x4C,
0xA7, 0x33, 0xE2, 0x1B, 0xA7, 0x6D, 0xF5, 0x30,
0x97, 0x1D, 0xF3, 0x02, 0x60, 0x5A, 0x82, 0x0F,
0x91, 0xD0, 0x9C, 0x10, 0x39, 0x7A, 0x83, 0x85,
0x3B, 0xB2, 0xB8, 0xAE, 0x0C, 0x09, 0x52, 0xEA,
0x1C, 0xE1, 0x8D, 0x66, 0x4F, 0xF3, 0xDA, 0x92,
0x29, 0xB9, 0xD5, 0xC5, 0x77, 0x47, 0x22, 0x53,
0x14, 0xF7, 0xAF, 0x22, 0x64, 0xDF, 0xC6, 0x72,
0x12, 0xF3, 0x75, 0xDA, 0xD7, 0xD7, 0xE5, 0x02,
0x9E, 0xED, 0xDA, 0xDB, 0x4C, 0x47, 0xCE, 0x91,
0x06, 0x06, 0x6D, 0x55, 0x8B, 0x19, 0xC9, 0xEF,
0x8C, 0x80, 0x1A, 0x0E, 0xEE, 0x4B, 0xAB, 0xF2,
0x08, 0x5C, 0xE9, 0x37, 0x26, 0x5E, 0x9A, 0x90,
0x00, 0xF3, 0x0D, 0xB2, 0xA6, 0xA3, 0xF7, 0x26,
0x17, 0x48, 0x88, 0xC9, 0x0E, 0x2C, 0xC9, 0x02,
0xE7, 0x18, 0x05, 0x4B, 0xF3, 0x39, 0xE1, 0x20,
0x02, 0x0D, 0x40, 0xC7, 0xCA, 0xB9, 0x48, 0x30,
0x57, 0x67, 0xCC, 0x06, 0xBF, 0xAC, 0x81, 0x08,
0x24, 0x7A, 0xD4, 0x8B, 0x19, 0x8E, 0xAC, 0xB4,
0x5A, 0x0F, 0x73, 0x13, 0xAC, 0x9E, 0xDA, 0xB6,
0xB8, 0x96, 0x5B, 0x60, 0x88, 0xE1, 0x81, 0x3F,
0x07, 0x86, 0x37, 0x2D, 0x79, 0x14, 0x52, 0xEA,
0x73, 0xDF, 0x3D, 0x09, 0xC8, 0x25, 0x48, 0xD8,
0x75, 0x60, 0x9A, 0x08, 0x27, 0x4A, 0x2C, 0xB9,
0xA8, 0x8B, 0x8A, 0x73, 0x62, 0x37, 0x16, 0x02,
0xBD, 0xC1, 0x0E, 0x56, 0x54, 0x3E, 0x14, 0x5F,
0x8C, 0x8F, 0x6E, 0x75, 0x1C, 0x07, 0x39, 0x7B,
0x4B, 0xDB, 0xD3, 0x4B, 0x1E, 0xC8, 0x7E, 0xFE,
0x3E, 0x72, 0x16, 0x83, 0x7D, 0xEE, 0xF5, 0xCA,
0xC5, 0x18, 0xF9, 0xD8, 0x68, 0xAB, 0x38, 0x85,
0xA8, 0xF0, 0xA1, 0x73, 0x9F, 0x5D, 0x19, 0x0B,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x33, 0x72, 0x39, 0x25, 0x67, 0x26, 0x6D, 0x71,
0x36, 0x77, 0x3C, 0x20, 0x62, 0x23, 0x68, 0x74,
0xC3, 0x82, 0xC9, 0x15, 0x57, 0x16, 0x5D, 0x81};

Re:You people just don't get it.

[daw]

> These folks have the law on their side. Like it
> or not the DeCSS software publishes a trade
> secret, the CSS encryption algorithm. This is
> illegal. Plain and simple. ... it's just plain
> against the law to publish someone else's trade
> secret without their express permission.

You, sir, are completely wrong. The argument you have just made is the one that has so far FAILED in federal court in California. The argument today in New York had nothing at all to do with trade secrets -- it was a copyright action. And it's not always or even usually illegal to publish a trade secret -- in fact, if you try to keep something a trade secret rather than secure proper patent or copyright protection for it, then it's essentially your responsibility, not the law's, to keep it a secret. If the secret escapes by legitimate means -- such as reverse engineering in Norway, a country where this is explicitly legal -- then it's your problem and you should have done a better job keeping your secret. This is the whole reason we have patents -- to convince people to disclose details of their ideas IN EXCHANGE FOR legal protection of them. If you instead want to keep it a secret, good luck, because the law affords you very limited protection.

You can read much more about how trade secrets apply to this case in the filings from the California case available at http://www.eff.org. But in the meantime you can rest quietly assured that you have absolutely no grasp of the facts or the law.

Cripes, they're serious.

[Lemmy Caution]

One reason why the DVD coalition and the MPAA are so panicked - and why they are bringing their massive financial and personal resources (i.e., good old boy's network) to bear on this case - is that the DVD makers had assured the content producers that there would be no risk of piracy or unauthorized copying, that they had created a 'hack proof' technology and that the studios had no reason to fear moving their content over to DVD.

Presto: the protection is compromised, and the DVD coalition is vulnerable to their (erstwhile) partner's legal fury. The content owners could sue the DVD makers right into their pockets for failure to come through on the protection of their content if the DVD coalition doesn't nip this in the bud..

Now, you and me know that there's no way that they can nip this thing in the bud, that they should not have tried to sell disk encryption as part of the DVD package to the content people, but that's moot as far as they are concerned. In the long run, they are screwed, and they just want to take "us" down with them.

Online tyrrany calls for real world activism

[MAXOMENOS]

2600 is calling for demonstrations against the MPAA, and I for one agree. We need to educate ordinary people on the fact that their right to free speech is in serious jeopardy thanks to the greed and stupidity of an organization (the MPAA) that fell for the DVD-security snake oil and can't admit that it's been had.

• If you're not a member of EFF or the ACLU, join now.
• If you are a member, or want to be more active, contact your local 2600 cell or Linux User's Group and help to organize a demonstration.
• If you have a DVD player, and you're too sick to even look at it, consider donating it to a local Geeks with Guns outing, in exchange for plenty of photos. Post them on a website, and mail them to DVD CAA and the members of the MPAA (listed on the 2600 announcement of the injunction).
• Consider buying a DeCSS source shirt; or if you're really radical, consider becoming a DOE (one of the 500+ anonyous people mentioned in the first injunction hearing).
• Boycott movies and videos until the MPAA drops the lawsuit!
• Most importantly: SPREAD THE WORD to other geeks and non-geeks. This is too important for us to keep silent!

This and the Etoy lawsuit are probably the most significant fights to hit our commmunity since the Clipper Chip fiasco. The lines are drawn, ladies and gentlemen; we need to fight with everything we've got to prevent Internet from becoming nothing but a huge, suburban shopping mall. Get involved in an historical fight and have something that you'll be proud to tell your kids and grandkids about, twenty years from now.

TOYWAR!!

I'd like to see the MPAA...

[lordsutch]

I can hardly wait for the MPAA to try to go after a legitimate site (sorry, I don't think 2600 counts) or company. For example, VA Linux Systems hosts DiBona.com, which posts a copy of the DeCSS code, yet oddly enough VA hasn't been a defendant yet. Who cares about VA taking over SGI? I'd rather see them sue the pants off the MPAA; maybe they'd give up Disney to settle ;-).

While they're at it, I'd like to see them sue Sima, who market this neat little gadget that defeats Macrovision I and II (save cash by getting it from these guys). It also cleans up the picture my DVD player puts out (tip: use the S-Video inputs whether or not you use S-Video for output; this stops you from using the bypass switch if you use the composite out, but that's a small sacrifice). Let's all watch the MPAA get laughed straight out of court when they go after people who have nothing to do with the WaReZ culture...

(I'd also like them to sue someone who's running for Congress and who's posted several links that apparently violate the DMCA. Bring it on, MPAA; I could use the free publicity...)

Re:You people just don't get it.

[Black Parrot]

> These folks have the law on their side.

It could hardly be more obvious that "the jury is still out" on that one. One judge issued a restraining order, another refused.

Then, if it turns out that that these folks actually do have the law on their side, there is the highly relevant issue of whether the law is constitutional.

Finally, there is the not-so-subtle distinction of having the law on your side and having right on your side. (Opinions will vary: I'm still out on that one, but at least I'm aware that the issue exists.) And for those who do think that right favors 2600 rather than the RIAA, there is always the fallback position of "nonviolent resistance". Thus you may well see people posting the link and going to jail for it, if they believe strongly enough in their own notion of right. It certainly wouldn't be the first time in history that this is happened, and a lot of social good has come from such sacrifices in the past.

And of course... there's the orthogonal issue of how much sway a US judge's ruling holds in other countries. (None, I would hope!) I suspect that what we are seeing is a tiny facet of a decades- or centuries-long trend of the USA turning itself into a technological backwater because the system is set up so that neither innovations nor freedoms can be allowed to stand in the path of corporate profits.

--
It's October 6th. Where's W2K? Over the horizon again, eh?

Re:You people just don't get it.

[SheldonYoung]

From http://execpc.com/~mhallign/intern.html

There are three essential elements to prove the existence of a trade secret: (1) it must be commercially
valuable information, (2) not in the public domain, and (3) the subject of reasonable efforts to maintain
its secrecy. Further, liability for trade secret misappropriation, to be effective, must extend not only to
the actual misappropriator but also to all other persons who know or should know that they are the
recipients of such information obtained by unauthorized acquisition, disclosure or use (third-party
liability). Finally, there must be effective remedies including injunctive relief, damages, and ex parte
seizure orders to prevent infringement and to preserve evidence.

I contest there have not been reasonable efforts taken to maintain it's secrecy according to #3 above. Reasonable efforts would have consisted of using any of the widely available strong encryption algorithms.

What they did would be equivalent to Pepsi including their ingredients list in the can, then telling you not to look. Just SAYING not to do it doesn't mean reasonable measure have been taken.

If any thing, the should be suing Xing.

You can maybe even argue that it's not even commercially valuable information according to #1. Producers of standalone players and DVD publishers still need to license the technology. They have not "lost" anything.

Sounds like time for

[porkchop_d_clown]

Sounds like time for a chain letter.

Any body want to get it started?

Hi! Please send this source code to your ten closest friends. If you do, The Justice Department will search your computer for free!

Better yet - what about an Outlook Express virus that propagates the source code???

(I can't believe I actually just suggested that. Must be the drugs. I had surgery the other week & I'm still in recovery.)

--

Greetings New User! Be sure to replace this text with a

It was never copy protection

[SEAL]

Repeat after me: it was never copy protection.

It was playback protection.

DVDs must be decrypted to VIEW them. Therefore, only "sanctioned" players - ones that the MPAA had released a decryption key to - could play them. The encryption provides NO protection against copying, with or without DeCSS.

I know this is pretty much common knowledge around here, but more of the mainstream media is starting to read this site. So they should hear it again.

SEAL

Now's a good time...

[Mark F. Komarinski]

to join the EFF. I just did. Time to put those RHAT, CORL, and LNUX profits to good use.