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

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.