RC4 Algorithm revealed.

1064 views
Skip to first unread message

Mark C. Henderson

unread,
Sep 14, 1994, 3:58:45 PM9/14/94
to
-----BEGIN PGP SIGNED MESSAGE-----

Subject: Re: RC4 Algorithm revealed.

In article <357bki$r...@sun1000.ci.pwr.wroc.pl>,
Jarek Lis <l...@ict.pwr.wroc.pl> wrote:
>Well, I'm not sure if RC4 algorithm isn't something well known and
>published for many years.
>
>Second, it's common thought, that hiding algorithm isn't the best way
>to security. Much better way is release algorithm and let people on all
>world work on breaking it. If it become broken, you know it was bad.
>and because many public people work on it, you hope to know that code is
>broken not much later than your enemy.

- From the RSA FAQ that is posted once a month or so.

}8.6 What are RC2 and RC4?
}
}RC2 and RC4 are variable-key-size cipher functions designed by Ron Rivest
}for fast bulk encryption. They are alternatives to DES (see Question
}5.1) and are as fast or faster than DES. They can be more secure than
}DES because of their ability to use long key sizes; they can also be less
}secure than DES if short key sizes are used.
}
}RC2 is a variable-key-size symmetric block cipher and can serve as a drop-in
}replacement for DES, for example in export versions of products otherwise
}using DES. RC2 can be used in the same modes as DES (see Question 5.3),
}including triple encryption. RC2 is approximately twice as fast as DES,
}at least in software. RC4 is a variable-key-size symmetric stream cipher
}and is 10 or more times as fast as DES in software. Both RC2 and RC4 are
}very compact in terms of code size.
}
}An agreement between the Software Publishers Association (SPA) and the U.S.
}government gives RC2 and RC4 special status by means of which the export
}approval process is simpler and quicker than the usual cryptographic export
}process. However, to qualify for quick export approval a product must limit
}the RC2 and RC4 key sizes to 40 bits; 56 bits is allowed for foreign
}subsidiaries and overseas offices of U.S. companies. An additional 40-bit
}string, called a salt, can be used to thwart attackers who try to
}precompute a large look-up table of possible encryptions. The salt is
}appended to the encryption key, and this lengthened key is used to encrypt
}the message; the salt is then sent, unencrypted, with the message. RC2 and
}RC4 have been widely used by developers who want to export their products;
}DES is almost never approved for export. RC2 and RC4 are proprietary
}algorithms of RSA Data Security, Inc.; details have not been published.

I'm reasonably sure that the reason RC4 was/is kept secret is not for
any increased security but so that RSADSI has exclisive rights to the
technology. Disassembly is easy. Cryptanalysis is hard. We can assume
that any adversary will be able to disassemble our applications and
reconstruct source code. Reverse engineering this sort of thing
wouldn't be that hard, it only takes time.

Given the agreement mentioned above, RC4 might be a valuable commodity.

Mark

-----BEGIN PGP SIGNATURE-----
Version: 2.7

iQBVAgUBLndV4mrJdmD9QWqxAQHXdQH/ZMiGHwW0YqyMVvgv6VDSPN0fB89pc1np
9imvQqm1Rrqm7PEvn90eg54SzX/cTFRJOUQXJ1ca6ZqWRisREuSXFA==
=mWgB
-----END PGP SIGNATURE-----
--
Mark Henderson <ma...@wimsey.bc.ca> | Microsoft is not the answer.
VPGP 2.7 key 21F6AF2B6A8A0BE1A12A2A064AD59246| Microsoft is the question.
fingerprints ECE7C3A92C3025C6F9E125F3F5AF92E3| NO is the answer.
crypto archive- ftp://ftp.wimsey.bc.ca/pub/crypto| -- Erik Naggum

David Sterndark

unread,
Sep 14, 1994, 2:35:31 AM9/14/94
to
I am shocked, shocked, I tell you, shocked, to discover
that the cypherpunks have illegaly and criminally revealed
a crucial RSA trade secret and harmed the security of
America by reverse engineering the RC4 algorithm and
publishing it to the world.

On Saturday morning an anonymous cypherpunk wrote:


SUBJECT: RC4 Source Code


I've tested this. It is compatible with the RC4 object module
that comes in the various RSA toolkits.

/* rc4.h */
typedef struct rc4_key
{
unsigned char state[256];
unsigned char x;
unsigned char y;
} rc4_key;
void prepare_key(unsigned char *key_data_ptr,int key_data_len,
rc4_key *key);
void rc4(unsigned char *buffer_ptr,int buffer_len,rc4_key * key);


/*rc4.c */
#include "rc4.h"
static void swap_byte(unsigned char *a, unsigned char *b);
void prepare_key(unsigned char *key_data_ptr, int key_data_len,
rc4_key *key)
{
unsigned char swapByte;
unsigned char index1;
unsigned char index2;
unsigned char* state;
short counter;

state = &key->state[0];
for(counter = 0; counter < 256; counter++)
state[counter] = counter;
key->x = 0;
key->y = 0;
index1 = 0;
index2 = 0;
for(counter = 0; counter < 256; counter++)
{
index2 = (key_data_ptr[index1] + state[counter] +
index2) % 256;
swap_byte(&state[counter], &state[index2]);

index1 = (index1 + 1) % key_data_len;
}
}

void rc4(unsigned char *buffer_ptr, int buffer_len, rc4_key *key)
{
unsigned char x;
unsigned char y;
unsigned char* state;
unsigned char xorIndex;
short counter;

x = key->x;
y = key->y;

state = &key->state[0];
for(counter = 0; counter < buffer_len; counter ++)
{
x = (x + 1) % 256;
y = (state[x] + y) % 256;
swap_byte(&state[x], &state[y]);

xorIndex = (state[x] + state[y]) % 256;

buffer_ptr[counter] ^= state[xorIndex];
}
key->x = x;
key->y = y;
}

static void swap_byte(unsigned char *a, unsigned char *b)
{
unsigned char swapByte;

swapByte = *a;
*a = *b;
*b = swapByte;
}



Another cypherpunk, this one not anonymous, tested the
output from this algorithm against the output from
official RC4 object code


Date: Tue, 13 Sep 94 18:37:56 PDT
From: e...@eit.COM (Eric Rescorla)
Message-Id: <940914013...@eitech.eit.com>
Subject: RC4 compatibility testing
Cc: cyphe...@toad.com

One data point:

I can't say anything about the internals of RC4 versus the
algorithm that Bill Sommerfeld is rightly calling 'Alleged RC4',
since I don't know anything about RC4's internals.

However, I do have a (legitimately acquired) copy of BSAFE2 and
so I'm able to compare the output of this algorithm to the output
of genuine RC4 as found in BSAFE. I chose a set of test vectors
and ran them through both algorithms. The algorithms appear to
give identical results, at least with these key/plaintext pairs.

I note that this is the algorithm _without_ Hal Finney's
proposed modification

(see <1994091306...@jobe.shell.portal.com>).

The vectors I used (together with the ciphertext they produce)
follow at the end of this message.

-Ekr

Disclaimer: This posting does not reflect the opinions of EIT.

--------------------results follow--------------
Test vector 0
Key: 0x01 0x23 0x45 0x67 0x89 0xab 0xcd 0xef
Input: 0x01 0x23 0x45 0x67 0x89 0xab 0xcd 0xef
0 Output: 0x75 0xb7 0x87 0x80 0x99 0xe0 0xc5 0x96

Test vector 1
Key: 0x01 0x23 0x45 0x67 0x89 0xab 0xcd 0xef
Input: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0 Output: 0x74 0x94 0xc2 0xe7 0x10 0x4b 0x08 0x79

Test vector 2
Key: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Input: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0 Output: 0xde 0x18 0x89 0x41 0xa3 0x37 0x5d 0x3a

Test vector 3
Key: 0xef 0x01 0x23 0x45
Input: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0 Output: 0xd6 0xa1 0x41 0xa7 0xec 0x3c 0x38 0xdf 0xbd 0x61

Test vector 4
Key: 0x01 0x23 0x45 0x67 0x89 0xab 0xcd 0xef
Input: 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01
0 Output: 0x75 0x95 0xc3 0xe6 0x11 0x4a 0x09 0x78 0x0c 0x4a 0xd4
0x52 0x33 0x8e 0x1f 0xfd 0x9a 0x1b 0xe9 0x49 0x8f
0x81 0x3d 0x76 0x53 0x34 0x49 0xb6 0x77 0x8d 0xca
0xd8 0xc7 0x8a 0x8d 0x2b 0xa9 0xac 0x66 0x08 0x5d
0x0e 0x53 0xd5 0x9c 0x26 0xc2 0xd1 0xc4 0x90 0xc1
0xeb 0xbe 0x0c 0xe6 0x6d 0x1b 0x6b 0x1b 0x13 0xb6
0xb9 0x19 0xb8 0x47 0xc2 0x5a 0x91 0x44 0x7a 0x95
0xe7 0x5e 0x4e 0xf1 0x67 0x79 0xcd 0xe8 0xbf 0x0a
0x95 0x85 0x0e 0x32 0xaf 0x96 0x89 0x44 0x4f 0xd3
0x77 0x10 0x8f 0x98 0xfd 0xcb 0xd4 0xe7 0x26 0x56
0x75 0x00 0x99 0x0b 0xcc 0x7e 0x0c 0xa3 0xc4 0xaa
0xa3 0x04 0xa3 0x87 0xd2 0x0f 0x3b 0x8f 0xbb 0xcd
0x42 0xa1 0xbd 0x31 0x1d 0x7a 0x43 0x03 0xdd 0xa5
0xab 0x07 0x88 0x96 0xae 0x80 0xc1 0x8b 0x0a 0xf6
0x6d 0xff 0x31 0x96 0x16 0xeb 0x78 0x4e 0x49 0x5a
0xd2 0xce 0x90 0xd7 0xf7 0x72 0xa8 0x17 0x47 0xb6
0x5f 0x62 0x09 0x3b 0x1e 0x0d 0xb9 0xe5 0xba 0x53
0x2f 0xaf 0xec 0x47 0x50 0x83 0x23 0xe6 0x71 0x32
0x7d 0xf9 0x44 0x44 0x32 0xcb 0x73 0x67 0xce 0xc8
0x2f 0x5d 0x44 0xc0 0xd0 0x0b 0x67 0xd6 0x50 0xa0
0x75 0xcd 0x4b 0x70 0xde 0xdd 0x77 0xeb 0x9b 0x10
0x23 0x1b 0x6b 0x5b 0x74 0x13 0x47 0x39 0x6d 0x62
0x89 0x74 0x21 0xd4 0x3d 0xf9 0xb4 0x2e 0x44 0x6e
0x35 0x8e 0x9c 0x11 0xa9 0xb2 0x18 0x4e 0xcb 0xef
0x0c 0xd8 0xe7 0xa8 0x77 0xef 0x96 0x8f 0x13 0x90
0xec 0x9b 0x3d 0x35 0xa5 0x58 0x5c 0xb0 0x09 0x29
0x0e 0x2f 0xcd 0xe7 0xb5 0xec 0x66 0xd9 0x08 0x4b
0xe4 0x40 0x55 0xa6 0x19 0xd9 0xdd 0x7f 0xc3 0x16
0x6f 0x94 0x87 0xf7 0xcb 0x27 0x29 0x12 0x42 0x64
0x45 0x99 0x85 0x14 0xc1 0x5d 0x53 0xa1 0x8c 0x86
0x4c 0xe3 0xa2 0xb7 0x55 0x57 0x93 0x98 0x81 0x26
0x52 0x0e 0xac 0xf2 0xe3 0x06 0x6e 0x23 0x0c 0x91
0xbe 0xe4 0xdd 0x53 0x04 0xf5 0xfd 0x04 0x05 0xb3
0x5b 0xd9 0x9c 0x73 0x13 0x5d 0x3d 0x9b 0xc3 0x35
0xee 0x04 0x9e 0xf6 0x9b 0x38 0x67 0xbf 0x2d 0x7b
0xd1 0xea 0xa5 0x95 0xd8 0xbf 0xc0 0x06 0x6f 0xf8
0xd3 0x15 0x09 0xeb 0x0c 0x6c 0xaa 0x00 0x6c 0x80
0x7a 0x62 0x3e 0xf8 0x4c 0x3d 0x33 0xc1 0x95 0xd2
0x3e 0xe3 0x20 0xc4 0x0d 0xe0 0x55 0x81 0x57 0xc8
0x22 0xd4 0xb8 0xc5 0x69 0xd8 0x49 0xae 0xd5 0x9d
0x4e 0x0f 0xd7 0xf3 0x79 0x58 0x6b 0x4b 0x7f 0xf6
0x84 0xed 0x6a 0x18 0x9f 0x74 0x86 0xd4 0x9b 0x9c
0x4b 0xad 0x9b 0xa2 0x4b 0x96 0xab 0xf9 0x24 0x37
0x2c 0x8a 0x8f 0xff 0xb1 0x0d 0x55 0x35 0x49 0x00
0xa7 0x7a 0x3d 0xb5 0xf2 0x05 0xe1 0xb9 0x9f 0xcd
0x86 0x60 0x86 0x3a 0x15 0x9a 0xd4 0xab 0xe4 0x0f
0xa4 0x89 0x34 0x16 0x3d 0xdd 0xe5 0x42 0xa6 0x58
0x55 0x40 0xfd 0x68 0x3c 0xbf 0xd8 0xc0 0x0f 0x12
0x12 0x9a 0x28 0x4d 0xea 0xcc 0x4c 0xde 0xfe 0x58
0xbe 0x71 0x37 0x54 0x1c 0x04 0x71 0x26 0xc8 0xd4
0x9e 0x27 0x55 0xab 0x18 0x1a 0xb7 0xe9 0x40 0xb0
0xc0


--
---------------------------------------------------------------------
We have the right to defend ourselves and our
property, because of the kind of animals that we James A. Donald
are. True law derives from this right, not from
the arbitrary power of the omnipotent state. jam...@netcom.com

Wolf Tagger

unread,
Sep 14, 1994, 6:07:00 PM9/14/94
to
In article <357bki$r...@sun1000.ci.pwr.wroc.pl> l...@ict.pwr.wroc.pl (Jarek Lis) writes:

>Well, I'm not sure if RC4 algorithm isn't something well known and
>published for many years.

>Second, it's common thought, that hiding algorithm isn't the best way
>to security. Much better way is release algorithm and let people on all
>world work on breaking it. If it become broken, you know it was bad.
>and because many public people work on it, you hope to know that code is
>broken not much later than your enemy.

Speaking of breaking codes, didn't someone manage to decyphre RSA recently?
I read something about it a couple of months ago (I can't remember where)
and was wandering how safe the public key encryption algorithms really were.
True, it took a few hundred experts a couple years to break, but they did
it, and I'm sure that so could the FBI or CIA or whatever if they put a
couple of Crays to it.


--------------- rgty...@chemistry.watstar.uwaterloo.ca ---------------------
_____ ______ Raphael T.
| : \ | \
| : `\______|______\________ Some men "live to fly, fly to
\'_____ \_____\_____ fight, fight to win". Others
\____/-)_,---------,______________>-- prefer to simply send a SAM
\ / up their tailpipe.
| /
|____/__

Jarek Lis

unread,
Sep 14, 1994, 1:24:34 PM9/14/94
to
David Sterndark (ster...@netcom.com) wrote:
: I am shocked, shocked, I tell you, shocked, to discover

: that the cypherpunks have illegaly and criminally revealed
: a crucial RSA trade secret and harmed the security of
: America by reverse engineering the RC4 algorithm and
: publishing it to the world.

James A. Donald

unread,
Sep 14, 1994, 1:15:23 PM9/14/94
to
The RC4 cypher seems to me to vulnerable to a known plain text attack,
and therefore should only be used in protocols where a random session
key is generated for each session.

This of course requires a source of truly random numbers, which is often
inconvenient.

Vesselin Bontchev

unread,
Sep 15, 1994, 8:20:06 AM9/15/94
to
Wolf Tagger (RGTY...@SCIENCE.watstar.uwaterloo.ca) writes:

> Speaking of breaking codes, didn't someone manage to decyphre RSA recently?

No. Only a single, 429-bit key was broken.

> I read something about it a couple of months ago (I can't remember where)
> and was wandering how safe the public key encryption algorithms really were.

Please try to get more accurate knowledge on the subject, before
starting to wander or to spread baseless rumors.

> True, it took a few hundred experts a couple years to break, but they did

It took approximately 600 people (not all of them experts), using 1600
workstations about 8 months (spending many MIPS-years) to crack just a
puny little 429-bit key. Increasing the key length by 10 bits
approximately doubles the price of the resources that have to be
used to crack it, and most people nowadays use 1024-bit keys.

> it, and I'm sure that so could the FBI or CIA or whatever if they put a
> couple of Crays to it.

Well, you are wrong. Not only "a couple of Crays" - even all computers
that have ever been produced in the history of minkind will not be
able to break a 1024-bit key for a reasonable time using the best of
the currently known factoring methods.

Regards,
Vesselin
--
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN
PGP 2.6 public key available on the servers. Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bont...@fbihh.informatik.uni-hamburg.de 22527 Hamburg, Germany

Robert D. Silverman

unread,
Sep 15, 1994, 9:58:40 AM9/15/94
to
In article <359e5m$1...@rzsun02.rrz.uni-hamburg.de> bont...@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes:
:Wolf Tagger (RGTY...@SCIENCE.watstar.uwaterloo.ca) writes:
:

stuff deleted....


:Please try to get more accurate knowledge on the subject, before


:starting to wander or to spread baseless rumors.

Amen!

:> True, it took a few hundred experts a couple years to break, but they did

:It took approximately 600 people (not all of them experts), using 1600
:workstations about 8 months (spending many MIPS-years) to crack just a
:puny little 429-bit key. Increasing the key length by 10 bits
:approximately doubles the price of the resources that have to be

Minor correction. For N near 429 bits, adding about 20 bits [not 10]
doubles the required resources.

--
Bob Silverman
These are my opinions and not MITRE's.
Mitre Corporation, Bedford, MA 01730
"You can lead a horse's ass to knowledge, but you can't make him think"

Nicol C So

unread,
Sep 15, 1994, 11:13:33 AM9/15/94
to
In article <sternCv...@netcom.com> ster...@netcom.com (David Sterndark) writes:
>I am shocked, shocked, I tell you, shocked, to discover
>that the cypherpunks have illegaly and criminally revealed
>a crucial RSA trade secret and harmed the security of
>America by reverse engineering the RC4 algorithm and
>publishing it to the world.

Pardon me if you are just kidding.

First of all, we don't know whether the code is the RC4 algorithm. It is
just something allegedly computes the same function as RC4 does. An
exponentiation algorithm is a different thing from the exponentiation
function. By the same token, an algorithm computing an encryption function
is distinct from the function being computed.

Second, how do you know that the person who published the code has
"illegally and criminally revealed a crucial trade secret of RSA". How
do you know that the person has violated any non-disclosure agreement
with RSA? How do you know that the person reverse engineered the code?
Did it ever occur to you that the person could be just a good cryptanalyst
who had come up with a similar design before? I don't know whether this
is the case, but it is always a possibility.

To say that RC4 is a "crucial RSA trade secret" is the biggest joke. It
takes an average programmer less than 5 minutes to see that the algorithm
in the code is nothing more than a stream cipher using pseudorandom numbers
as the key stream. The variable key-length feature is accomplished by
applying a hash function to the key to obtain an initial state for the
pseudorandom number generator. This scheme has probably be reinvented
a thousand times. The only thing new here is the particular pseudorandom
number generator used.

Mark Chen

unread,
Sep 15, 1994, 1:31:12 PM9/15/94
to
In article <RGTYMOWS.1...@science.watstar.uwaterloo.ca>,

Wolf Tagger <RGTY...@SCIENCE.watstar.uwaterloo.ca> wrote:
>Speaking of breaking codes, didn't someone manage to decyphre RSA recently?
>I read something about it a couple of months ago (I can't remember where)
>and was wandering how safe the public key encryption algorithms really were.
>True, it took a few hundred experts a couple years to break, but they did
>it, and I'm sure that so could the FBI or CIA or whatever if they put a
>couple of Crays to it.

A single RSA modulus (RSA-129) was factored. This does not mean that
RSA was broken.

The team that did it logged something like 5,000 MIPS-years of widely
distributed processing time, though having a bunch of Crays would not
have shortened the process in real time because the algorithm used was
cache- and memory-bound, not compute-bound. So the "FBI or CIA" are
in no better position to do the job than anyone else.

The security of RSA is scalable according to the size of your modulus.
A 1024-bit modulus is not known to be vulnerable to any existing
technology.

- Mark -

BUNNY

unread,
Sep 16, 1994, 4:44:00 AM9/16/94
to
In article <sternCv...@netcom.com>, ster...@netcom.com (David Sterndark) writes...

i'm not sure i get your point.
as i understand it even if someone *knows* the algorithm, there is little
they can do to crack it without alot of hardware and cpu time.

no loss.

Bruce Schneier

unread,
Sep 17, 1994, 9:27:15 AM9/17/94
to
In article <357bki$r...@sun1000.ci.pwr.wroc.pl>,
Jarek Lis <l...@ict.pwr.wroc.pl> wrote:
>David Sterndark (ster...@netcom.com) wrote:
>: I am shocked, shocked, I tell you, shocked, to discover
>: that the cypherpunks have illegaly and criminally revealed
>: a crucial RSA trade secret and harmed the security of
>: America by reverse engineering the RC4 algorithm and
>: publishing it to the world.
>:
>
>Well, I'm not sure if RC4 algorithm isn't something well known and
>published for many years.

It isn't well known, and it has never been previously published. Effectively,
RSA Data Security achieved with RC4 what the NSA is trying to achieve
with Skipjack. Their secret algorithm has become a de facto standard without
any public review and comment.

>Second, it's common thought, that hiding algorithm isn't the best way
>to security. Much better way is release algorithm and let people on all
>world work on breaking it. If it become broken, you know it was bad.
>and because many public people work on it, you hope to know that code is
>broken not much later than your enemy.

Of course, but profits are better served by making an algorithm secret
and forcing consumers to buy it. And if NSA gives you a monopoly by making
it easier to export products with your algorithm and no other, so much
the better.

Bruce

Jonathan Adams

unread,
Sep 18, 1994, 4:39:53 AM9/18/94
to
David Sterndark (ster...@netcom.com) wrote:
: I am shocked, shocked, I tell you, shocked, to discover

: that the cypherpunks have illegaly and criminally revealed
: a crucial RSA trade secret and harmed the security of
: America by reverse engineering the RC4 algorithm and
: publishing it to the world.
:
: On Saturday morning an anonymous cypherpunk wrote:

How do you know it was a cypherpunk? Because it was posted to the
cyperpunks list? *Anyone* can do that.

[snip]

: --

: ---------------------------------------------------------------------
: We have the right to defend ourselves and our
: property, because of the kind of animals that we James A. Donald
: are. True law derives from this right, not from
: the arbitrary power of the omnipotent state. jam...@netcom.com

^^^^^^^^^^^^^^^^^
Gee. Anyone want to hazard a guess as to who *really* posted this? >sigh<

Jonathan Adams

--
jona...@netcom.com
PGP 2.6 key available. Fingerprint: (Jonathan Adams)
40 27 43 E0 5C 20 66 0E EE 8C 10 9F EC 40 78 6A (revoked!)
A5 77 E9 28 88 DD B7 D4 9C 8C F9 D5 D8 3F 45 BE (new! 1024 bit)

Marc Thibault

unread,
Sep 17, 1994, 10:08:13 PM9/17/94
to
RGTY...@SCIENCE.watstar.uwaterloo.ca (Wolf Tagger) writes:

> Speaking of breaking codes, didn't someone manage to decyphre RSA recently?
> I read something about it a couple of months ago (I can't remember where)

Spent the summer at the North Pole, did we? Do a news search
on "RSA-129" to get back into the swing of things. Nobody
"decyphred" RSA. They did, however, factor a small, 129-digit
key using an approach that was more interesting than the
accomplishment.

Cheers,
Marc

---
This is not a secure channel; assume nothing.

Marc Thibault | Information Systems Architect
PGP fingerprint = 6C 54 49 77 DB A7 AE DA 73 EA 30 EE F7 07 90 DA


Message has been deleted

Alan Cox

unread,
Sep 18, 1994, 12:31:51 PM9/18/94
to
In article <sternCv...@netcom.com> ster...@netcom.com (David Sterndark) writes:
>a crucial RSA trade secret and harmed the security of
>America by reverse engineering the RC4 algorithm and
>publishing it to the world.

ROTFL. _IF_ RC4 is secure they have done no harm. If it isn't secure you'll
be sitting on one less timebomb.

Secondly: Deducing an algorithm can be done legally. Its only maths which is
a pure abstract set of thought systems _NOT_ some kind of industrial secret.

Now if the person in question stole RSA's source I hope he gets caught. If
its been done by analysis then I hope he gets an award.

Alan
--
..-----------,,----------------------------,,----------------------------,,
// Alan Cox // iia...@www.linux.org.uk // GW4PTS@GB7SWN.#45.GBR.EU //
``----------'`----------------------------'`----------------------------''

Paul Ferguson

unread,
Sep 18, 1994, 1:07:45 PM9/18/94
to
Grady Ward (gr...@netcom.com) wrote:

> We really don't know whether this trade secret was improperly obtained.
> Note the exception of 'reverse engineering' in California law:

> 3426.1. As used in this title, unless the context requires
> otherwise:


Forgive my poor memory, but wasn't there a court ruling with regards
to 'reverse-engineering' fairly recently that involved a couple of
major electronic games makers (SEGA)? If I recall correctly, the
court ruled in favor of the 'reverse-engineers'... No?

Cheers,

- paul

David Sternlight

unread,
Sep 18, 1994, 6:58:56 PM9/18/94
to
In article <gradyCw...@netcom.com>, Grady Ward <gr...@netcom.com> wrote:
>
>We really don't know whether this trade secret was improperly obtained.
>Note the exception of 'reverse engineering' in California law:
>
>3426.1. As used in this title, unless the context requires
>otherwise:
> (a) "Improper means" includes theft, bribery,
>misrepresentation, breach or inducement of a breach of a duty to
>maintain secrecy, or espionage through electronic or other
>means. Reverse engineering or independent derivation alone
>shall not be considered improper means.

Thanks for posting the text of the code. It seems pretty conclusive that
there was a violation. Since RSADSI asserts that every copy is covered by a
"no reverse engineering" agreement, either theft or breach of a duty to
maintain secrecy must have been involved, and thus improper means must have
been used.

This means that:
(b) "Misappropriation" means:

(1) Acquisition of a trade secret of another by a person who
knows or has reason to know that the trade secret was acquired
by improper means; or
(2) Disclosure or use of a trade secret of another without
express or implied consent by a person who:
(A) Used improper means to acquire knowledge of the trade
secret; or
(B) At the time of disclosure or use, knew or had reason to
know that his or her knowledge of the trade secret was:
(i) Derived from or through a person who had utilized
improper means to acquire it;

means that under b1, b2, and b2bi, ANYONE republishing the trade secret is
guilty of misappropriation if they meet the conditions of b2bi.

At least as of the time RSADSI published their notice, everyone who read it
(and everyone who reads this message) has reason to know that the trade
secret was acquired by improper means, I would think. What's more, depending
on the language associated with the original mailing list publication, and
the newsgroup publication, said language itself might have contained enough
information to give reason to know the trade secret was acquired by improper
means.

Be VERY careful, folks.

David


--
People who post newsgroup flames
Must have flammable gas for brains.
Burma Shave.

Perry E. Metzger

unread,
Sep 18, 1994, 7:37:44 PM9/18/94
to

In article <CwC39...@info.swan.ac.uk> iia...@iifeak.swan.ac.uk (Alan Cox) writes:

>In article <sternCv...@netcom.com> ster...@netcom.com (David Sterndark) writes:
>>a crucial RSA trade secret and harmed the security of
>>America by reverse engineering the RC4 algorithm and
>>publishing it to the world.

>ROTFL. _IF_ RC4 is secure they have done no harm. If it isn't secure you'll
>be sitting on one less timebomb.

I believe you have misunderstood. "Sterndark" is a figment of a
forgers imagination -- the posting is obviously intended to be a
satirical depiction of David Sternlight.

--
Perry Metzger pe...@imsi.com
--

D. J. Bernstein

unread,
Sep 18, 1994, 7:51:42 PM9/18/94
to
Take it to talk.politics.crypto, Sternlight.

In article <strnlghtC...@netcom.com> strn...@netcom.com (David Sternlight) writes:
> Since RSADSI asserts that every copy is covered by a
> "no reverse engineering" agreement,

An absurd assertion.

You can walk over to a computer store and buy a copy of some RC4-using
software off the shelf.

Does the cashier say, ``To purchase this product, sir, you'll have to
agree not to reverse engineer it.''? Of course not. You pay cash; the
store gives you a box containing the disks. That's a contract of sale.

You then own that copy of the software. You can reverse-engineer it.

This is, presumably, what the RC4 discoverer actually did.

---Dan

Bill Dugan

unread,
Sep 18, 1994, 8:07:31 PM9/18/94
to
In article <35hs51$5...@news.sprintlink.net>,

Paul Ferguson <pa...@hawksbill.sprintmrn.com> wrote:
>
>Forgive my poor memory, but wasn't there a court ruling with regards
>to 'reverse-engineering' fairly recently that involved a couple of
>major electronic games makers (SEGA)? If I recall correctly, the
>court ruled in favor of the 'reverse-engineers'... No?

Please forgive my poor memory also, but it indicates that you are correct.
Acclaim, a major videogame cartridge manufacturer, reverse-engineered the
code in the ROMs of the Sega Genesis videogame console. The ROM code looked
at the code in the first few bytes of the cartridge ROM. I am not sure
whether any code in the cartridge ROM is executed at this point, but among
other things the Genesis looks for the word SEGA in the cartridge ROM. If
this is not present, the system will lock up.

The point is, Acclaim reverse-engineered the Genesis ROM code so they could
manufacture their own Sega Genesis-compatible cartridges and not have to
pay Sega to manufacture the cartridges, go through Sega's licensing
procedures, and so on.

Sega sued Acclaim in federal (I believe) court in the US and won. The judge
was snowed, basically. If I remember correctly, Sega said that Acclaim
violated *copyright* law because when disassembling the Genesis ROM code,
Acclaim's engineers made a printout of the disassembled code. Sega's
lawyers also stated that reverse-engineering would still have been possible
without a violation of copyright law, because Acclaim's reverse-engineering
team could have used "clean-room procedures" and "peeled" off layers of
Genesis ROM chips to deduce a way of creating Genesis-compatible cartridges.
Thus, Acclaim's action didn't fall under any fair use category, and was
a violation of copyright law.

Acclaim appealed and the appeals court threw out the lower court's verdict,
saying it was preposterous. I do not believe that this case has yet reached
the U.S. Supreme Court, but then what do I know.

Note that if a judge believed that copyright law was violated by printing
out a disassembly of the ROMs, another judge could likely be convinced that
copyright law is violated when you copy *memory* from disk to RAM, say.

The main point is that, for now, in the United States, it's OK to disassemble
code to reverse-engineer it. But the pathetic state of computer-savviness
amongst US judges would make this a gamble for anyone who wanted to create
a commercial product based (to any degree) on reverse-engineered code.
A ruling could occur tomorrow that reverses all the above.

Disclaimer: I work for a company that makes Sega Genesis games and thus
I suppose I work for a competitor of all the above companies. Plus, my
memory is incomplete and my notes aren't in front of me. Let the reader
beware. :( My views are not those of my employer, etc. etc.

bdu...@gnu.ai.mit.edu

Eli Brandt

unread,
Sep 18, 1994, 8:42:38 PM9/18/94
to
In article <strnlghtC...@netcom.com>,

David Sternlight <strn...@netcom.com> wrote:
>In article <gradyCw...@netcom.com>, Grady Ward <gr...@netcom.com> wrote:
>> (a) "Improper means" includes theft, bribery,
>>misrepresentation, breach or inducement of a breach of a duty to
>>maintain secrecy, or espionage through electronic or other
>>means. Reverse engineering or independent derivation alone
>>shall not be considered improper means.
>
>Thanks for posting the text of the code. It seems pretty conclusive that
>there was a violation.

Say what? We have no reason at all to think that the RC4 source was
obtained through theft, espionage, etc. Most likely somebody bought a
product that used RC4, and spent a weekend disassembling it. Your
argument appears to turn on this disassembly being a "breach of a duty
to maintain secrecy", on the strength of the product's probable
shrink-wrap agreement. But it has been pointed out that shrink-wrap
prohibitions of reverse engineering have not held up in court.

Would you care to support your assertion that "it seems pretty
conclusive that there was a violation", or would you prefer to repeat
it instead?

>Be VERY careful, folks.

Your concern for our welfare touches the heart.

Eli ebr...@hmc.edu


Thomas Grant Edwards

unread,
Sep 18, 1994, 9:39:35 PM9/18/94
to
In article <CwA01...@chinet.chinet.com>,
Bruce Schneier <schn...@chinet.chinet.com> wrote:

>Of course, but profits are better served by making an algorithm secret
>and forcing consumers to buy it.

Yeah, then you post a copy of the source code and encourage people to
buy the next more expensive algorithm...

...or the US government wants to hurt RSADSI by publishing the source...
keep all those cool cryptosystems unprofitable and therefore unimplemented
by civillians...

The possibilities abound!

Message has been deleted

William Unruh

unread,
Sep 19, 1994, 1:30:10 AM9/19/94
to
strn...@netcom.com (David Sternlight) writes:
>At least as of the time RSADSI published their notice, everyone who read it
>(and everyone who reads this message) has reason to know that the trade
>secret was acquired by improper means, I would think. What's more, depending
No we don't know!. Reverse engineering is expresely excluded from
"improper means". Nor is there any reason for us to believe that all
copies of all programs containing it were obtained with a "no reverse
engineering " license, nor that the "no reverese engineering" clause was
part of any license signed by all individuals nor that any such license
was a valid license, etc. We do not know how the source was obtained,
nor has any statement by you or RSA told us how the source was obtained,
Bidzos has said that it was a trade secret. That is not enough to tell
us that it was obtained by improper means, nor have we any way of
knowing whether or not it was.

--
Bill Unruh
un...@physics.ubc.ca

Paul Rubin

unread,
Sep 19, 1994, 3:55:04 AM9/19/94
to
In article <strnlghtC...@netcom.com>,
David Sternlight <strn...@netcom.com> wrote:
>In article <gradyCw...@netcom.com>, Grady Ward <gr...@netcom.com> wrote:
>>
>>We really don't know whether this trade secret was improperly obtained.
>>Note the exception of 'reverse engineering' in California law:
>>
>>3426.1. As used in this title, unless the context requires
>>otherwise:
>> (a) "Improper means" includes theft, bribery,
>>misrepresentation, breach or inducement of a breach of a duty to
>>maintain secrecy, or espionage through electronic or other
>>means. Reverse engineering or independent derivation alone
>>shall not be considered improper means.
>
>Thanks for posting the text of the code. It seems pretty conclusive that
>there was a violation. Since RSADSI asserts that every copy is covered by a
>"no reverse engineering" agreement, either theft or breach of a duty to
>maintain secrecy must have been involved, and thus improper means must have
>been used.

This is a logical fallacy. It assumes that anything RSADSI asserts
is automatically true.

Barry Margolin

unread,
Sep 19, 1994, 12:47:26 PM9/19/94
to
In article <35iko3...@life.ai.mit.edu> bdu...@gnu.ai.mit.edu (Bill Dugan) writes:
>Note that if a judge believed that copyright law was violated by printing
>out a disassembly of the ROMs, another judge could likely be convinced that
>copyright law is violated when you copy *memory* from disk to RAM, say.

Not really. The latter is considered fair use, as the copyright laws were
amended for software to allow for the types of copying that are required in
order to use the software in the normal way. Disassembling is not the
normal way to use software, so it's not necessarily fair use.
--

Barry Margolin
BBN Internet Services Corp.
bar...@near.net

Arthur Rubin

unread,
Sep 19, 1994, 1:27:55 PM9/19/94
to
In <strnlghtC...@netcom.com> strn...@netcom.com (David Sternlight) writes:

>In article <gradyCw...@netcom.com>, Grady Ward <gr...@netcom.com> wrote:
>>
>>We really don't know whether this trade secret was improperly obtained.
>>Note the exception of 'reverse engineering' in California law:
>>
>>3426.1. As used in this title, unless the context requires
>>otherwise:
>> (a) "Improper means" includes theft, bribery,
>>misrepresentation, breach or inducement of a breach of a duty to
>>maintain secrecy, or espionage through electronic or other
>>means. Reverse engineering or independent derivation alone
>>shall not be considered improper means.

>Thanks for posting the text of the code. It seems pretty conclusive that
>there was a violation. Since RSADSI asserts that every copy is covered by a
>"no reverse engineering" agreement, either theft or breach of a duty to
>maintain secrecy must have been involved, and thus improper means must have
>been used.

RSADSI asserts a lot of things. Some of them are correct. Also, why
should California law apply, anyway, unless the reverse engineering was
done in California.

--
Arthur L. Rubin: a_r...@dsg4.dse.beckman.com (work) Beckman Instruments/Brea
216-...@mcimail.com 7070...@compuserve.com aru...@pro-sol.cts.com (personal)
My opinions are my own, and do not represent those of my employer.
This space intentionally left blank.

Ken Shirriff

unread,
Sep 19, 1994, 9:11:29 PM9/19/94
to
If you use two long (256 bytes or slightly less) keys with a certain stream
cipher, and these keys differ only in the last byte (or so), then the
output streams from these two keys will usually not diverge for many bytes,
in some cases more than 100.

This means that if you have two plaintexts encrypted with similar keys that
you may be able to decode the first parts of the ciphertexts. By
exclusive-oring the ciphertexts together, the generated streams will cancel
out and you're left with the exclusive-or of the plaintexts.) If you know
one of the plaintexts, then recovering the beginning of the other becomes
trivial.

Ken Shirriff shir...@cs.Berkeley.EDU

Tim Farley

unread,
Sep 20, 1994, 12:09:47 AM9/20/94
to
Hey, Grady, here's something to consider:

If you were RSA, and you got wind that someone was about to
complete a clean-room reverse engineer RC4 and publish the
results in a journal or something, how could you respond? If you
were reasonably sure that a true clean room was involved, then
there is really no legal response. Of course you could tie the
person up in courts for years, but it is unlikely you could have
any real effect.

However, if you could "taint" the results of the clean room
efforts, you could make everyone steer clear of it without ever
having to file a court motion. How could you taint a clean room?
By dirtying it.

By publicly releasing the actual source to RC4, RSA could have
deliberately sunk any possible future clean room efforts to
disassemble the code. How could anyone prove that they hadn't
seen this code, and thereby prove they had a clean room?

Personally, I'm not the conspiracy-theory type, but it does make
one wonder.

--Tim Farley

Roland Buresund

unread,
Sep 20, 1994, 6:09:28 AM9/20/94
to
Arthur Rubin (a_r...@dsg4.dse.beckman.com) wrote:

: In <strnlghtC...@netcom.com> strn...@netcom.com (David Sternlight) writes:

: >In article <gradyCw...@netcom.com>, Grady Ward <gr...@netcom.com> wrote:
: >>
: >>We really don't know whether this trade secret was improperly obtained.
: >>Note the exception of 'reverse engineering' in California law:
: >>
: >>3426.1. As used in this title, unless the context requires
: >>otherwise:
: >> (a) "Improper means" includes theft, bribery,
: >>misrepresentation, breach or inducement of a breach of a duty to
: >>maintain secrecy, or espionage through electronic or other
: >>means. Reverse engineering or independent derivation alone
: >>shall not be considered improper means.

: >Thanks for posting the text of the code. It seems pretty conclusive that
: >there was a violation. Since RSADSI asserts that every copy is covered by a
: >"no reverse engineering" agreement, either theft or breach of a duty to
: >maintain secrecy must have been involved, and thus improper means must have
: >been used.

: RSADSI asserts a lot of things. Some of them are correct. Also, why
: should California law apply, anyway, unless the reverse engineering was
: done in California.

I'm sorry, but I couldn't resist that bait ;-)

The reason Californian Law should apply is because David believes that
law to be applicable everywhere. This is in the same spirit as the reasoning
that the US will invade most of Europe because US and European Law doesn't
agree on the patentability of Software Algorithms.... :-)

I would love to see California invade the rest of the US to get some
"illegal and criminal" programmer extradicted to Los Angeles.

As I said, I just couldn't resist it. I wont take any more bandwidth from this
discussion.


Roland B.
--
+------------------+----------------------+----------------------+
| Roland Buresund |Tel.: +46 8 638 51 07 |Box 232 |
| Enea Data |Fax.: +46 8 638 50 50 |Nytorpsv. 5B |
| Security Dept. |E-mail: ro...@enea.se |S-183 23 TÄBY, SWEDEN |
+------------------+----------------------+----------------------+

Paul Ferguson

unread,
Sep 20, 1994, 7:47:58 AM9/20/94
to
Roland Buresund (roxy@gordon) wrote:

> The reason Californian Law should apply is because David believes that
> law to be applicable everywhere. This is in the same spirit as the reasoning
> that the US will invade most of Europe because US and European Law doesn't
> agree on the patentability of Software Algorithms.... :-)

> I would love to see California invade the rest of the US to get some
> "illegal and criminal" programmer extradicted to Los Angeles.


Don't laugh just yet.

Until (if) the AA BBS case ruling gets overturned, anything is possible.
(A bit of pessimism here.)

This case is clearly an example of how disparate geographical and local
law (community standards, in this case) can affect some poor schmuck
on the opposite side of the United States.

This is a disturbing trend and could possibly have lasting impact if
not overturned.

A reminder.

Cheers,


_______________________________________________________________________________
Paul Ferguson
US Sprint
Managed Network Engineering tel: 703.904.2437
Herndon, Virginia USA internet: pa...@hawk.sprintmrn.com

Paul Ferguson

unread,
Sep 20, 1994, 10:23:07 PM9/20/94
to
Glen Roberts (g...@ripco.com) wrote:

> Let's get real... if the algorithm is embodied in the object code...
> sooner or later, someone will read the object code... I guess if you
> were trained at it, you could disassemble it in your head.

Let's be 'for real,' folks.

Nothing is sacred. There are many, many experienced enough to
disassemble functional binaries into ledgible source, or similarly
function assembly. Hell, I've been doing it for years.

Does this requisite a criminal? No.

You put it into the public domain, regardless of statute, it gets
scrutinized. (Public Domain, in this case, meaning that it is freely
available to the public, regardless of purchase.)

Glen Roberts

unread,
Sep 20, 1994, 7:46:10 PM9/20/94
to
Barry Margolin (bar...@nic.near.net) wrote:

And... if someone thinks their secrets are SECURE, simply because it's
"not fair" to disassemble it... they have much to learn in our world
of technology.

Surely, they don't protect their trade secrets, by placing them in a
filing cabinet in their parking lot with a "do not read" sign attached.

Let's get real... if the algorithm is embodied in the object code...
sooner or later, someone will read the object code... I guess if you
were trained at it, you could disassemble it in your head.

--
--------------------------------------
Glen L. Roberts, Editor, Full Disclosure Magazine
Host Full Disclosure Live (WWCR 5,810 khz - Sundays 7pm central)
email g...@rci.ripco.com for information on The Best of Full Disclosure,
four volumes to blow your mind. Voice/Fax on demand: (708) 356-9646
email for uuencoded .TIF of T-Shirt Honoring the FBI
-------------------------------------

jmke...@news.delphi.com

unread,
Sep 20, 1994, 8:34:35 PM9/20/94
to
shir...@sprite.cs.berkeley.edu (Ken Shirriff) writes:

>If you use two long (256 bytes or slightly less) keys with a certain stream
>cipher, and these keys differ only in the last byte (or so), then the
>output streams from these two keys will usually not diverge for many bytes,
>in some cases more than 100.

Yes. Clearly, a certain stream cipher that claims variable length
keys shouldn't be used with keys anywhere near 256 bytes in
length--indeed, probably, keys more than 128 bytes are questionable.

Of course, if the passphrases are passed through a good hash function
designed by the same cryptographer that designed said stream cipher, more
than a 16 byte keywould probably be more keyspace than was really needed.

I'm interested in the other side. How does it affect the security of
the cipher when it's fed a 16-bit key? Or for that matter, a 40-bit
key? The ideal situation for the key setup would seem to be to expand a
short key into 256 bytes of strongly key-dependent pseudorandom data, and
use that to shuffle the internal state. Is there a reason why that's not
a
good idea? Or just why it's not needed?

>Ken Shirriff shir...@cs.Berkeley.EDU

--John Kelsey, jmke...@delphi.com

David Sternlight

unread,
Sep 21, 1994, 2:17:34 AM9/21/94
to
In article <35j7l2$f...@nntp.ucs.ubc.ca>,

William Unruh <un...@physics.ubc.ca> wrote:
>strn...@netcom.com (David Sternlight) writes:
>>At least as of the time RSADSI published their notice, everyone who read it
>>(and everyone who reads this message) has reason to know that the trade
>>secret was acquired by improper means, I would think. What's more, depending
>No we don't know!. Reverse engineering is expresely excluded from
>"improper means".

Simply appalling.I though that after the past complaints about your reading
comprehension you would have taken a course or two. Apparently not. Reverse
engineering is not excluded from improper means. Read the law again. It says
that reverse engineering ALONE isn't improper means, but if it is associated
with theft, or with failure to honor a duty of secrecy, then reverse
engineering won't get you off.

> Nor is there any reason for us to believe that all
>copies of all programs containing it were obtained with a "no reverse
>engineering " license, nor that the "no reverese engineering" clause was
>part of any license signed by all individuals nor that any such license
>was a valid license, etc.

Bidzos says that all copies are covered by such a license. Unless you are
prepared to call him a liar and back it up, you're simply wrong about the
first part of the above.

As to whether the licenses are valid or not, assertion that they're not
won't answer that question. THAT's spreading FUD.

>We do not know how the source was obtained,
>nor has any statement by you or RSA told us how the source was obtained,

>Bidzos has said that it was a trade secret. That is not enough to tell
>us that it was obtained by improper means, nor have we any way of
>knowing whether or not it was.

You haven't been following this discussion. Jim says that all copies are
protected by a "no reverse engineering, no disclosure" license. Jim says that
the only way the code could have gotten out is by theft or license
violation. He is in a position to know; you are not and can only make up
stories. They cannot carry any weight with serious people, being unsupported
by any evidence.


>Bill Unruh
>un...@physics.ubc.ca

Kenneth Lerman

unread,
Sep 21, 1994, 9:04:59 AM9/21/94
to
David Sternlight (strn...@netcom.com) wrote:
...

<In the interests of brevity, lines have been deleted.

: Bidzos says that all copies are covered by such a license. Unless you are


: prepared to call him a liar and back it up, you're simply wrong about the
: first part of the above.

What does the phrase "covered by such a license" mean in the above
context?

The "license" that came with a copy of Lotus Notes I've seen says:
"You may make one(1) archival copy of the Software."

It does NOT say:
"This software contains trade secrets, you must guard it from disclosure."
"You must affix a copy of this license to the archival copy of the
Software."

So, even if the license which is hidden inside the package is binding,
it does NOT require that I treat the copy as if it contained a trade
secret.

It may be binding on me, but is not binding on others who may have
access to my machine.

So I conclude that if Bidzos says that all copies are covered by such
a license, he:

1 -- means something very different than my understanding of those
words, OR

2 -- he is mistaken, OR

3 -- he is a liar.

Not knowing anything about the man, I am loathe to call him a liar.
On the otherhand, if he is a lawyer, then "res ipso loquitor", as they
say in the trade. (pardon my spelling)

...


: You haven't been following this discussion. Jim says that all copies are


: protected by a "no reverse engineering, no disclosure" license. Jim says that
: the only way the code could have gotten out is by theft or license
: violation. He is in a position to know; you are not and can only make up
: stories. They cannot carry any weight with serious people, being unsupported
: by any evidence.

The copy of the "license" of Lotus Notes in my possession says that I
"may not loan, rent, lease or license the Software or any copy." It
does NOT say that I may not leave it lying round on my coffee table.
The word disclosure does not appear to be anywhere in the license.

If you want me to treat something like a secret, you should at least
tell me that it IS a secret.

Ken

--
Kenneth Lerman ler...@seltd.newnet.com
Systems Essentials Limited (203)426-4430
55 Main Street
Newtown, CT 06470

Peter D. Junger

unread,
Sep 21, 1994, 7:03:20 AM9/21/94
to
No one seems to have commented on the fact that the California Trade Secret
Act probably cannot constitutionally be applied to prevent members of the
general public from copying, or making, using, and selling, an algorithm
or section of code like the alleged RC4 code that has become widely
disseminated and thus public, even though the secret was originally released
to the public by someone who obtained the former secret improperly or who
released it in violation of a non-disclosure agreement.

There are two reasons for this, one being the first amendment's protection
of free speach. The other, and stronger, constitutional argument is simply
that a state law forbidding the use or copying of information that is in
fact generally available to the public is the equivalent of a patent or a
copyright, and only the federal government can constitutionally grant
patents or copyrights.

It thus seems highly improbable that the information can be put back in the
bottle even if, as seems unlikely, it was not obtained by reverse engineering
or by some other means that is forbidden by the California Trade Secrets
law.

Please note that I have removed sci.crypt from the follow-up line.

--
Peter D. Junger -- Case Western Reserve Univ. Law School
Home: jun...@pdj2-slip.dialin.cwru.edu (preferred)
Office: jun...@samsara.law.cwru.edu

Nick Maclaren

unread,
Sep 21, 1994, 7:41:19 AM9/21/94
to
In article <strnlghtC...@netcom.com>, strn...@netcom.com (David Sternlight) writes:
|>
|> You haven't been following this discussion. Jim says that all copies are
|> protected by a "no reverse engineering, no disclosure" license. Jim says that
|> the only way the code could have gotten out is by theft or license
|> violation. He is in a position to know; you are not and can only make up
|> stories. They cannot carry any weight with serious people, being unsupported
|> by any evidence.

So? I am afraid that you haven't been following all of the discussion
either. Many states (and I don't just mean states of the U.S.A.) have
the concept of void conditions in contracts - i.e. you can put the
condition in a contract, but it carries no legal weight. If a copy
were legally passed onto an organisation in a state where the license
contained void conditions (or were void in its entirety), no law need
necessarily have been broken.

Your remark about unsupported allegations is quite true, but it applies
to both sides. Perhaps the evidence will be produced in court, though
I am rather doubtful. Until it has been produced, the best that we
outsiders can say is that there has been an unsupported allegation of
wrong-doing.


Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: nm...@cus.cam.ac.uk
Tel.: +44 223 334761 Fax: +44 223 334679


Jonathan Adams

unread,
Sep 21, 1994, 7:37:58 AM9/21/94
to
David Sternlight (strn...@netcom.com) wrote:
: In article <35j7l2$f...@nntp.ucs.ubc.ca>,
: William Unruh <un...@physics.ubc.ca> wrote:
: > Nor is there any reason for us to believe that all

: >copies of all programs containing it were obtained with a "no reverse
: >engineering " license, nor that the "no reverese engineering" clause was
: >part of any license signed by all individuals nor that any such license
: >was a valid license, etc.

: Bidzos says that all copies are covered by such a license. Unless you are
: prepared to call him a liar and back it up, you're simply wrong about the
: first part of the above.

The burden of proof is on Bidzos, not us. Why don't you ask *HIM* how
he knows that every copy of it is licensed.

: As to whether the licenses are valid or not, assertion that they're not


: won't answer that question. THAT's spreading FUD.

Asserting that Bidzos is some oracle of truth is spreading FUD, too.

: >We do not know how the source was obtained,


: >nor has any statement by you or RSA told us how the source was obtained,

: >Bidzos has said that it was a trade secret. That is not enough to tell
: >us that it was obtained by improper means, nor have we any way of
: >knowing whether or not it was.

: You haven't been following this discussion. Jim says that all copies are
: protected by a "no reverse engineering, no disclosure" license. Jim says that
: the only way the code could have gotten out is by theft or license
: violation. He is in a position to know; you are not and can only make up
: stories. They cannot carry any weight with serious people, being unsupported
: by any evidence.

So Bizdos doesn't need any evidence to support his arguments, but
everyone *ELSE* on the internet (with the miraculous exception of
YOU), does?

: >Bill Unruh
: >un...@physics.ubc.ca

: --
: People who post newsgroup flames
: Must have flammable gas for brains.
: Burma Shave.

Jonathan Adams
--
jona...@netcom.com
PGP 2.6 key available. Fingerprint: (Jonathan Adams)
40 27 43 E0 5C 20 66 0E EE 8C 10 9F EC 40 78 6A (revoked!)
A5 77 E9 28 88 DD B7 D4 9C 8C F9 D5 D8 3F 45 BE (new! 1024 bit)

Peter Berger

unread,
Sep 22, 1994, 5:17:15 PM9/22/94
to
In article <strnlghtC...@netcom.com>,
David Sternlight <strn...@netcom.com> wrote:
>Bidzos says that all copies are covered by such a license. Unless you are
>prepared to call him a liar and back it up, you're simply wrong about the
>first part of the above.
>
>As to whether the licenses are valid or not, assertion that they're not
>won't answer that question. THAT's spreading FUD.

Whether the licenses were valid or not is the linchpin on which the entire
case turns.

--
........................................................................
Peter G. Berger, Esq. Telerama Public Access Internet, Pittsburgh
Internet: pet...@telerama.lm.com Phone: 412/481-3505 Fax: 412/481-8568
http://www.lm.com/ gopher://gopher.lm.com/ ftp://ftp.lm.com/

Clive D.W. Feather

unread,
Sep 22, 1994, 9:17:41 AM9/22/94
to
In article <35qlsg$4...@zeus.IntNet.net>,

Jay Ashworth <j...@zeus.IntNet.net> wrote:
> strn...@netcom.com (David Sternlight) writes:
>> Thanks for posting the text of the code. It seems pretty conclusive that
>> there was a violation. Since RSADSI asserts that every copy is covered by a
>> "no reverse engineering" agreement, either theft or breach of a duty to
>> maintain secrecy must have been involved, and thus improper means must have
>> been used.
> David, you're bound and determined to go around making a fool of yourself,
> aren't you?

There seems to be a tendency to flame David Sternlight, just because his
political opinions are unpopular, without reading his comments with a
reasonable mind.

> You're asserting that RSA's "agreements", presumably with it's licensee's,
> contain a claus prohibiting people from reverse engineering, and that
> therefore, people in California bette watch their backs, even though the
> California Penal Code says it's ok; right?

David said "Since RSADSI asserts ... either theft or breach of a duty
... must have been involved.". If you make the reasonable assumption
that, before the word "either", David meant "and you assume they are
telling the truth", then what is wrong with his statement ?

Now, you can argue that RSADSI's assertion is unlikely to be true, but
why flame David for that ?

> I see 2 possible outcomes here:
> 1) A reverse engineer is a licensee, and there can be covered by the
> more restrictive terms in that license... but why would such an
> engineer _need_ to do this. They'd _have_ the code.

Not necessarily.

> 2) A reverse engineer is not a licensee, and therefore isn't covered
> by such a more-restrictive clause,

But *if* the assertion of RSADSI is true, and your case 2 applies, then
*someone* broke the licence. David didn't say it was the reverse
engineer who did.

> (Ever hear of the Uniform Commercial Code? Produce the contract.)

No. And I'm sure it doesn't apply to me.

> some of us _listened_ in Logic 101.

Your statement number 2 makes it less than obvious that you *understood*.

--
Clive D.W. Feather | Santa Cruz Operation | If you lie to the compiler,
cl...@sco.com | Croxley Centre | it will get its revenge.
Phone: +44 1923 813541 | Hatters Lane, Watford | - Henry Spencer
Fax: +44 1923 813811 | WD1 8YN, United Kingdom | <= NOTE: NEW PHONE NUMBERS

Message has been deleted

Peter Berger

unread,
Sep 23, 1994, 12:49:58 PM9/23/94
to
In article <jlicquia.8...@mhc.uiuc.edu>,
Jeff Licquia <jlic...@mhc.uiuc.edu> wrote:
>In article <35putl$k...@zaphod.mps.ohio-state.edu> j...@math.ohio-state.edu (Jim Corder) writes:
>Peter Berger has posted a few responses on sci.crypt with legal opinions
>(nonbinding, of course) that seem to indicate that those kind of licenses
>(shrinkwrap/disk-envelope/boxtop/your-favorite-packing-material-here) are
>considered invalid. He's a legal scholar though, not a lawyer, and I'm
>certainly not a lawyer. Your mileage may vary.

I beg your pardon. I am licensed to practice law in both Pennsylvania and
New Jersey.

The seminal case finding that state law validating and making enforceable
"shrink-wrap" licenses is preempted by the Copyright Act is _Vault Corp.
v. Quaid Software Ltd._, 847 F.2d 255 (5th Cir. 1988).

The trial court held that the "contract" contained in the license
agreement was unenforceable in the absence of enabling legislation as an
"adhesion contract". The enabling legislation was preempted as an attempt
to frustrate section 117 of the Copyright act. But don't take my word for
it -- go read (and Shepardize) the case yourself.

This isn't legal advice. Get your own lawyer.

Jeff Licquia

unread,
Sep 23, 1994, 9:06:28 AM9/23/94
to
In article <35v0vm$n...@ivory.lm.com> pet...@telerama.lm.com (Peter Berger) writes:

>In article <jlicquia.8...@mhc.uiuc.edu>,
>Jeff Licquia <jlic...@mhc.uiuc.edu> wrote:

>>Peter Berger has posted a few responses on sci.crypt with legal opinions
>>(nonbinding, of course) that seem to indicate that those kind of licenses
>>(shrinkwrap/disk-envelope/boxtop/your-favorite-packing-material-here) are
>>considered invalid. He's a legal scholar though, not a lawyer, and I'm
>>certainly not a lawyer. Your mileage may vary.

>I beg your pardon. I am licensed to practice law in both Pennsylvania and
>New Jersey.

My deepest apologies. I fully retract, of course.

I must have confused you with someone else in a fit of mental breakdown, since
I've seen you post before about your status.

Jochen Bern

unread,
Sep 23, 1994, 1:03:24 PM9/23/94
to
In <strnlghtC...@netcom.com> strn...@netcom.com (David Sternlight) writes:
>In article <35j7l2$f...@nntp.ucs.ubc.ca>,
>William Unruh <un...@physics.ubc.ca> wrote:
>> Nor is there any reason for us to believe that all
>>copies of all programs containing it were obtained with a "no reverse
>>engineering " license, nor that the "no reverese engineering" clause was
>>part of any license signed by all individuals nor that any such license
>>was a valid license, etc.
>Bidzos says that all copies are covered by such a license. Unless you are
>prepared to call him a liar and back it up, you're simply wrong about the
>first part of the above.

No Sir! Other than in your Imagination, real Life (and Math, too, in these
Days) knows a third Value besides "true" and "false" which is called
"unknown". If Mr. Bidzos makes Assertions which are perfectly in his own
Interest, we can safely deny taking that as a Proof for "true" *without*
being restricted to call it "false" (i.e., he lied).

>You haven't been following this discussion. Jim says that all copies are
>protected by a "no reverse engineering, no disclosure" license. Jim says that
>the only way the code could have gotten out is by theft or license
>violation. He is in a position to know; you are not and can only make up
>stories. They cannot carry any weight with serious people, being unsupported
>by any evidence.

Fortunately, most legal Systems in democratic Countries do *not* assume
that He Who Knows may effectively decide the Matter. If I were accused
of releasing confidential Material derived from propietary Software in
Germany, I would first be asked where I obtained the Software; Then I
can either say that I didn't use the Software to get at the Material in
Question or tell them where I got it. In the first Case, the Guy suing
me would have to make reasonably clear that I can't have obtained the
released Material without the Software; In the second, it's *his* Job
to provide Proofs that the Copy I got and the Proceedings how I got it
imply the Restrictions he's claiming on me.

Granted, a Software Salesman showing around how the S/W gets sold at this
Moment (with a big "BREAK THIS SEAL AND WE TELL YOU WHAT YOU'RE ALLOWED
TO DO" on it) and claiming that it's been always this Way is likely to
impress the Court in such a Situation; However, if I can then come up
with the Remainders of the Package I bought and they look quite different,
eventually with different License Agreements on the Back, he's going to
lose a Lot of his Credibility. And, in Contrast to you, Mr. Sternlight,
no Judge would be bewildered by the Fact that someone has claimed Rights
he hasn't got. Judges see this Kind of Thing sometimes, you know.

*Disclaimer* I don't know the Software in Question, not to mention the
License Terms for it. I'm only objecting to the Point of View "If the
Salesman says you go to Jail, you'll do".

Regards,
J. Bern
--
/ \ Mail: be...@Uni-Trier.DE (7Bit); be...@TI.Uni-Trier.DE (OW Mails OK) /\
/ J. \ <A HREF="http://www.informatik.uni-trier.de/~bern">My Homepage</A> / \
\Bern/ FINGER, NEWS ETC. AT THIS SITE ARE BROKEN, PLEASE USE MAIL (+ WWW) \ /
\ / P.O. Box 1203, 54202 Trier, Germany, Europe - Ham Call Sign: DD0KZ \/

David Cain

unread,
Sep 23, 1994, 4:12:28 PM9/23/94
to
Barry Margolin (bar...@nic.near.net) wrote:

But recently the District Court of Northern California held (Triad Systems
Corp. v. Southeastern Express Co.) that loading software into RAM can be
sufficient fixation for copyright infringement purposes.

dc
--
David Cain *
Speaking for no one *
dc...@uspto.gov *
d.c...@genie.geis.com *

David Sternlight

unread,
Sep 23, 1994, 7:35:53 PM9/23/94
to

Bushwa! California law applies in California, and against those who can be
extradited to California.

As it happens the Uniform Trade Secrets Act has very similar provisions.

Don't you get tired of making personal attacks against others when you
haven't anything substantive to add, or is that a sign of the level of your
psychosocial development?

David

Iolo Davidson

unread,
Sep 20, 1994, 1:19:55 PM9/20/94
to
In article <phrCwD...@netcom.com> p...@netcom.com "Paul Rubin" writes:

> This is a logical fallacy. It assumes that anything RSADSI asserts
> is automatically true.

But Sternlight has told us that it is true, and we know that
everything *he* says is automatically true.

--

THE TIME IS WHEN YOU'RE
TO START OFFERED A SUBSTITUTE
A REAL DISPUTE Burma Shave

HALLAM-BAKER Phillip

unread,
Sep 25, 1994, 1:19:01 PM9/25/94
to

In article <strnlghtC...@netcom.com>, strn...@netcom.com (David Sternlight) writes:

|>Thanks for posting the text of the code. It seems pretty conclusive that
|>there was a violation. Since RSADSI asserts that every copy is covered by a
|>"no reverse engineering" agreement, either theft or breach of a duty to
|>maintain secrecy must have been involved, and thus improper means must have
|>been used.

Such conditions are legaly unenforcable in Europe under EU anti-monopoly
law. The directive explicitly states that such conditions cannot be enforced.

So all you need to do is to export the algorithm to the EU, reverse engineer
it and return it to the US.

Since EU monopoly law is based on US anti trust in part I would be amazed if
the US had no similar provision.


David should stop making serious allegations about others. Before he deduced
from a five line report that a company had filled a vexatious suit without
even having read the statement of claim. Now he makes similar allegations
about others having performed criminal acts. He really should take legal
advice before making such serious allegations.

--

Phillip M. Hallam-Baker

Not Speaking for anyone else.

Jay Ashworth

unread,
Sep 25, 1994, 5:15:42 PM9/25/94
to
cl...@sco.com (Clive D.W. Feather) writes:

Hey, Clive...

>In article <35qlsg$4...@zeus.IntNet.net>,
>Jay Ashworth <j...@zeus.IntNet.net> wrote:
>> strn...@netcom.com (David Sternlight) writes:
>>> Thanks for posting the text of the code. It seems pretty conclusive that
>>> there was a violation. Since RSADSI asserts that every copy is covered by a
>>> "no reverse engineering" agreement, either theft or breach of a duty to
>>> maintain secrecy must have been involved, and thus improper means must have
>>> been used.
>> David, you're bound and determined to go around making a fool of yourself,
>> aren't you?

>There seems to be a tendency to flame David Sternlight, just because his
>political opinions are unpopular, without reading his comments with a
>reasonable mind.

Hmmm... I thought I was reading his comments with a reasonable mind. I've
just come across Mr. Sternlight this week, in fact...

>> You're asserting that RSA's "agreements", presumably with it's licensee's,
>> contain a claus prohibiting people from reverse engineering, and that
>> therefore, people in California bette watch their backs, even though the
>> California Penal Code says it's ok; right?

>David said "Since RSADSI asserts ... either theft or breach of a duty
>... must have been involved.". If you make the reasonable assumption
>that, before the word "either", David meant "and you assume they are
>telling the truth", then what is wrong with his statement ?

Because there's a perfectly logical third alternative, and his language
seemed calculated to exclude it: someone encrypted a bunch of cleartext,
and gave the input, output, and keys to a third party not bound by
anyone's license agreement with RSADSI.

>Now, you can argue that RSADSI's assertion is unlikely to be true, but
>why flame David for that ?

I wasn't flaming him for that. I was flaming him for doing his best to
demonstrate _every_ form of fallactious argument in my Logic text.

>> I see 2 possible outcomes here:
>> 1) A reverse engineer is a licensee, and there can be covered by the
>> more restrictive terms in that license... but why would such an
>> engineer _need_ to do this. They'd _have_ the code.

>Not necessarily.

Or they're a thief, in which case the license _still_ doesn't apply.

>> 2) A reverse engineer is not a licensee, and therefore isn't covered
>> by such a more-restrictive clause,

>But *if* the assertion of RSADSI is true, and your case 2 applies, then
>*someone* broke the licence. David didn't say it was the reverse
>engineer who did.

No, Clive.. this _doesn't_ follow. See above.

>> (Ever hear of the Uniform Commercial Code? Produce the contract.)

>No. And I'm sure it doesn't apply to me.

I was going to respond with "bullshit". And then I saw who the poster
was. :-)

>> some of us _listened_ in Logic 101.

>Your statement number 2 makes it less than obvious that you *understood*.

As I noted above... no. He was asserting that people not party to a
contract with RSADSI were subject to a clause of such a contract which was
more restrictive than an explicit clause in California law. I was simply
refuting him. How does this demontrate fallacious thinking, pray?

Cheers,
-- jra
--
Jay R. Ashworth High Technology Systems Comsulting Ashworth
Designer Linux: The Choice of a GNU Generation & Associates
ka1fjx/4
j...@baylink.com "Hey! Do any of you guys know how to Madison?" 813 790 7592

Clive D.W. Feather

unread,
Sep 26, 1994, 9:02:30 AM9/26/94
to
In article <364p9u$1...@zeus.IntNet.net>,

Jay Ashworth <j...@zeus.IntNet.net> wrote:
>>> You're asserting that RSA's "agreements", presumably with it's licensee's,
>>> contain a claus prohibiting people from reverse engineering, and that
>>> therefore, people in California bette watch their backs, even though the
>>> California Penal Code says it's ok; right?
>> David said "Since RSADSI asserts ... either theft or breach of a duty
>> ... must have been involved.". If you make the reasonable assumption
>> that, before the word "either", David meant "and you assume they are
>> telling the truth", then what is wrong with his statement ?
> Because there's a perfectly logical third alternative, and his language
> seemed calculated to exclude it: someone encrypted a bunch of cleartext,
> and gave the input, output, and keys to a third party not bound by
> anyone's license agreement with RSADSI.

That's not what you said at the time, though.

And it's the first claim I've seen that seriously suggests that the code
in question can be broken in that way (as a practical proposition, I
mean; I am quite aware that it is theoretically possible).

>>> I see 2 possible outcomes here:
>>> 1) A reverse engineer is a licensee, and there can be covered by the
>>> more restrictive terms in that license... but why would such an
>>> engineer _need_ to do this. They'd _have_ the code.
>> Not necessarily.
> Or they're a thief, in which case the license _still_ doesn't apply.

Other way round. A licensee doesn't necessarily have the code. They may
only have object files, in which case the licence *does* still apply.

>>> 2) A reverse engineer is not a licensee, and therefore isn't covered
>>> by such a more-restrictive clause,
>> But *if* the assertion of RSADSI is true, and your case 2 applies, then
>> *someone* broke the licence. David didn't say it was the reverse
>> engineer who did.
> No, Clive.. this _doesn't_ follow. See above.

If the assertion is true, and case 2 applies, then someone broke the
licence. What doesn't follow about that.

>>> (Ever hear of the Uniform Commercial Code? Produce the contract.)
>> No. And I'm sure it doesn't apply to me.
> I was going to respond with "bullshit". And then I saw who the poster
> was. :-)

Do you know me ? Have we met in person or on the net before ? Or do you
mean "where" rather than "who" ?

>>> some of us _listened_ in Logic 101.
>> Your statement number 2 makes it less than obvious that you *understood*.
> As I noted above... no. He was asserting that people not party to a
> contract with RSADSI were subject to a clause of such a contract which was
> more restrictive than an explicit clause in California law.

Not as I read it. He asserted that, if the code were reverse engineered
(by which I think he means disassembled), then *someone* subject to such
a contract breached it. He did *not* say that the reverse engineer did so.

David Sternlight

unread,
Sep 26, 1994, 4:22:57 PM9/26/94
to
In article <35pqng$d...@nntp.ucs.ubc.ca>,

William Unruh <un...@physics.ubc.ca> wrote:
>strn...@netcom.com (David Sternlight) writes:
>
>>In article <35j7l2$f...@nntp.ucs.ubc.ca>,
>>William Unruh <un...@physics.ubc.ca> wrote:
>>>strn...@netcom.com (David Sternlight) writes:
>>>>At least as of the time RSADSI published their notice, everyone who read it
>>>>(and everyone who reads this message) has reason to know that the trade
>>>>secret was acquired by improper means, I would think. What's more, depending
>>>No we don't know!. Reverse engineering is expresely excluded from
>>>"improper means".
>
>>Simply appalling.I though that after the past complaints about your reading
>>comprehension you would have taken a course or two. Apparently not. Reverse
>>engineering is not excluded from improper means. Read the law again. It says
>>that reverse engineering ALONE isn't improper means, but if it is associated
>>with theft, or with failure to honor a duty of secrecy, then reverse
>>engineering won't get you off.
>
>Simply appalling.I though that after the past complaints about your reading
>comprehension you would have taken a course or two. Apparently not. Reverse
>is specifically exempted from improper means. If it is accompanied by
>other improper means it does not nullify those others but I never said
>it did. I simply said that in and of itself reverse engineering was not
>improper means.

You did not say "in and of itself". And that is what the law says--that
reverse engineering ONLY is not a violation. But reverse engineering in
assocation with other violations mentioned in the same breath in the law
WOULD BE.

The case some have tried to make here is that if RC4 was obtained by reverse
engineering it is not a violation of law, but rather is exempted. That is a
one possible necessary, but not a sufficient condition for it to be
exempted. Other things must be involved as well, and are inextricably bound
to the statement about reverse engineering in the written law. Those other
things include that the item not have been obtained by theft, or by the
failure of a duty to secrecy. What is more, in a subsequent subsection, the
law makes clear that if the reverse engineer could be expected to know that
the item was obtained by another through theft or failure of a duty to
secrecy, then his reverse engineering is not protected even if HE wasn't the
thief or failee.

Thus it is false to state or imply that reverse engineering itself is prima
facie evidence that the violation is protected by law.

David Sternlight

unread,
Sep 26, 1994, 4:31:28 PM9/26/94
to
In article <CwqMw...@scone.london.sco.com>,

Clive D.W. Feather <cl...@sco.com> wrote:
>
>Not as I read it. He asserted that, if the code were reverse engineered
>(by which I think he means disassembled), then *someone* subject to such
>a contract breached it. He did *not* say that the reverse engineer did so.

That's a pretty good summary, to which I'd add that the California law, and
I think the Uniform Trade Secrets Act also provides, in effect, that if the
reverse engineer could be presumed to know that somebody else breached the
contract or stole the material, then the reverse engineer himself is guilty
of misappropriation of the trade secret if he publishes his reverse
engineering or uses it.

Given the logic of the situation, I think if RSADSI can prove their
assertions about the way in which the program is distributed, it would be
possible to make the case that someone HAD TO have stolen or violated, and
thus the reverse engineer CAN be presumed to know this even if he wasn't the
original thief or violator of a duty to secrcy.

That's assuming, of course that the published code was reverse engineered
rather than being the original code distributed by RSADSI under safeguards.
If the latter, there's at least an open and shut copyright case, in addition
to the possible trade secrets case.

David

William Unruh

unread,
Sep 27, 1994, 12:47:08 AM9/27/94
to
strn...@netcom.com (David Sternlight) writes:


>You did not say "in and of itself". And that is what the law says--that
>reverse engineering ONLY is not a violation. But reverse engineering in
>assocation with other violations mentioned in the same breath in the law
>WOULD BE.

...


>Thus it is false to state or imply that reverse engineering itself is prima
>facie evidence that the violation is protected by law.

But I never said or implied that reverse engineering is prima facia evidence that
the violation is protected by law. You keep wanting to make me say more
than I actually said. reverse engineering is simply not improper means.
In the list of things the law regards as improper means, reverse
engineering is nowhere to be found in that list. Almost any other action
may be in taht list, but reverse engineering is distinguished in being
virtually the only action not to be found there.
If improper means WERE used then a violation occured. Those improper
means do not include reverse engineering period. ( they also do not
include many other things such as buying the program, etc, but in fact
reverse engineering is more protected than anything else since it is
explicitely excluded from the list of improper means.)

Am I now clear?
Furhtermore, when in discussions someone says "it was obtained by
reverse engineering" in distinction from "by improper means" they
usually do not menat " it was obtained by reverse engineering and by
improper menas" such as a violation of an explicit non-disclosure
agreement. It measns it was obtained by reverse engineering rather than
by one of the catalog of improper means. It is true that it could have
been obtained by reverse engineering and still have also been revealed
by improper means (such as the explicit violation of a non-disclosure
agreement, invasion of the offices of RSA at midnight and theft from the
files etc) but it is hard to see why reverse engineering would then have
been needed. One usually signs non-disclosure agreements only if
something has been disclosed to one ( and I agree that there are cases
in which you would sign a non-diclosure for other reasons than to see
RC4 etc).

Anyway I apologise for having had to write this long and totally
obvious post, but for someone to be appalled at my not being able to
follow a logical argument and other ad hominem attacks
and then to blithly proceed to impute
statements to me that I never made in order to attack me,
tends to bring out the cussedness in me.
--
Bill Unruh
un...@physics.ubc.ca

David Sternlight

unread,
Sep 27, 1994, 12:11:03 PM9/27/94
to
In article <35lnab$gqk$4...@mhadf.production.compuserve.com>,
Tim Farley <76711...@CompuServe.COM> wrote:

>
>By publicly releasing the actual source to RC4, RSA could have
>deliberately sunk any possible future clean room efforts to
>disassemble the code. How could anyone prove that they hadn't
>seen this code, and thereby prove they had a clean room?

Hardly. There are plenty of clean-room re-engineerings of IBM's ROM BIOS
code which is public though protected.

All you have to do is prove the programmers never saw the code itself, and
that the worked from functional specifications. That's been proven legally
several times before, in the BIOS cases.

In the RSADSI case you cannot write functional specifications for the crypto
kernel which don't violate the trade secrets. That is the clean room problem
here. You cannot describe the transformation from input to output (as you
can for various BIOS functions) without describing the trade secret itself.

Had you asserted a lesser point, it would be correct, but rather
unconvincing. That is--the published code would prevent those who read
it--those on the cypherpunks list, from clean-room reproduction (independent
of the point in the previous paragraph). But it is highly unlikely RSADSI
would reveal the code just to "get" a few cypherpunks who weren't known to
be trying to re-engineer RC4 at the time. What's more, they'd be taking a
big risk with respect to others who hadn't seen the leaked code.

Your hypothesis doesn't make sense.

David Sternlight

unread,
Sep 27, 1994, 12:32:35 PM9/27/94
to
In article <35qlsg$4...@zeus.intnet.net>,

Jay Ashworth <j...@zeus.IntNet.net> wrote:
>strn...@netcom.com (David Sternlight) writes:
>>Thanks for posting the text of the code. It seems pretty conclusive that
>>there was a violation. Since RSADSI asserts that every copy is covered by a
>>"no reverse engineering" agreement, either theft or breach of a duty to
>>maintain secrecy must have been involved, and thus improper means must have
>>been used.
>
>David, you're bound and determined to go around making a fool of yourself,
>aren't you?

It is not I who am making a fool of myself. Your message contains errors
which make your associated personal attacks look like the work of a juvenile
defamer.

>
>Let's make this perfectly clear, shall we?


>
>You're asserting that RSA's "agreements", presumably with it's licensee's,
>contain a claus prohibiting people from reverse engineering, and that
>therefore, people in California bette watch their backs, even though the
>California Penal Code says it's ok; right?

The California Penal Code does not say it's o.k. It says that reverse
engineering, not associated with theft or betrayal of a duty to secrecy by
any party (not just by the reverse engineer) is o.k.

Putting it another way, it says:

1. If you steal the secret you're culpable;
2. If you betray a duty to keep the secret, you're culpable;
3. If you publish the secret when you could be assumed to know that someone
else did 1 or 2 (above) you're culpable.
4. Some other stuff you can do to make you culpable.
5. If you reverse engineer WITHOUT 1-4, the act of reverse engineering alone
doesn't make you culpable.

That is a far cry from "the California Penal Code says it's ok". In the
present case, there's very good reason to believe that some of 1-4 apply,
and in addition, nobody on the other side has proven that some of 1-4 didn't
happen. Thus we cannot conclude anything about the reverse engineering or
subsequent publication except that it will take a court to rule on this one.
In particular, we cannot CONCLUDE that the reverse engineer was "ok", though
many here keep ASSERTING it by posting an erroneous description, or an
out-of-context piece of the penal code.

As to the RSADSI notice et al, that's legitimate notice to insure that
people don't "innocently" publish--i.e. to protect their trade secret.
Anyone who has read that notice might be assumed to have the knowledge in
(3.) above, and thus is being warned that RSADSI asserts that they would be
in violation of the California Criminal Code if they (re)publish the trade
secret. That meets any obligation under the law for RSADSI to give notice to
third parties, an important point if the issue of whether RSADSI was
diligent in protecting their trade secrets arises in a civil case against a
publisher of the trade secret.

If you're looking for motive, one could assert that RSADSI's notice was
posted not to frighten anyone else, but to meet any test on RSADSI
themselves that they were diligent in protecting the secret and in advising
others who might have seen the publication that the matter was trade secret.

The full code was posted some time ago in this discussion by Grady Ward, yet
people such as you keep ignoring it. That you, in particular, do so as a
basis to make personal attacks speaks volumes about your own integrity.

By the way, all of the above should be read in the context of "if" the
revealed code was obtained by reverse engineering. That hasn't been
demonstrated and there is a possibility it is the real (copyright) code in
which case the revelation and any republication also runs afoul of the
copyright laws.

I understand RSADSI intends to take legal action on this one--stay tuned.
The legal situation will become quite clear if a case proceeds to trial.
I would not be surprised to see it involve multiple defendants.

Barry Margolin

unread,
Sep 27, 1994, 2:22:26 PM9/27/94
to
In article <36884c$n...@nntp.ucs.ubc.ca> un...@physics.ubc.ca (William Unruh) writes:
>One usually signs non-disclosure agreements only if
>something has been disclosed to one ( and I agree that there are cases
>in which you would sign a non-diclosure for other reasons than to see
>RC4 etc).

Actually, it's quite common to require NDA's as part of beta-test
agreements. The intent there is to prohibit the tester from disclosing
anything they might learn about the software while testing it. This would
include trade secrets they learn by reverse-engineering the software (and
the beta-test agreement usually mentions reverse-engineering explicitly).
--

Barry Margolin
BBN Internet Services Corp.
bar...@near.net

Peter Berger

unread,
Sep 27, 1994, 2:33:29 PM9/27/94
to
In article <strnlghtC...@netcom.com>,

David Sternlight <da...@sternlight.com> wrote:
>In article <CwqMw...@scone.london.sco.com>,
>Clive D.W. Feather <cl...@sco.com> wrote:
>>
>>Not as I read it. He asserted that, if the code were reverse engineered
>>(by which I think he means disassembled), then *someone* subject to such
>>a contract breached it. He did *not* say that the reverse engineer did so.
>
>That's a pretty good summary, to which I'd add that the California law, and
>I think the Uniform Trade Secrets Act also provides, in effect, that if the
>reverse engineer could be presumed to know that somebody else breached the
>contract or stole the material, then the reverse engineer himself is guilty
>of misappropriation of the trade secret if he publishes his reverse
>engineering or uses it.

Nope. You can't create privity of contract where there is none, even by
legislative fiat.

William Unruh

unread,
Sep 27, 1994, 2:53:15 PM9/27/94
to
strn...@netcom.com (David Sternlight) writes:

>1. If you steal the secret you're culpable;
>2. If you betray a duty to keep the secret, you're culpable;
>3. If you publish the secret when you could be assumed to know that someone
>else did 1 or 2 (above) you're culpable.
>4. Some other stuff you can do to make you culpable.
>5. If you reverse engineer WITHOUT 1-4, the act of reverse engineering alone
>doesn't make you culpable.

>That is a far cry from "the California Penal Code says it's ok". In the
>present case, there's very good reason to believe that some of 1-4 apply,
>and in addition, nobody on the other side has proven that some of 1-4 didn't
>happen. Thus we cannot conclude anything about the reverse engineering or
>subsequent publication except that it will take a court to rule on this one.
>In particular, we cannot CONCLUDE that the reverse engineer was "ok", though
>many here keep ASSERTING it by posting an erroneous description, or an
>out-of-context piece of the penal code.

Let us keep the discussion in context. You stated that because you had
posted RSA's claims that the code was obtained by unlawful means, that
we should all therefor know that it was and therefor that anyone who
reads this newsgroup therefor falls under your point 3. What many of us
have been trying to point out to you is that we know nothing of the
sort. You cannot conclude from the possibility that the code was
obtained wrongly that it was obtained wrongly. What many have been
trying to point out to you is that it is also possible that it was
obtained by perfectly valid means amongst which reverse engineering (
yes, by assumption without any of the possible wrongful means also
having been used) falls.

Now, David, do you grant that it is possible that the code was obtained
by means that do not fall under the catagory of unlawful means? The key
word in that sentence is POSSIBLE. (and yes, I will put in that the
possibility must be a reasonable possibility- ie that a majority of
reasonable people would agree that the means were a possible means.)

If so, then you do not know that the the code was obtained by unlawful
means. That is the question the courts will ask. Are there means by
which the code could, given the knowledge of the person, have been
obtained which do not violate the code. The answer of most of us is yes,
amongst which reverse engineering of store bought code containing RC4
falls. If that is possible, then we do NOT fall under your section 3.
The onus is on RSA (for civil) and on the prosecution (criminal) to show
with high probability that we knew (not guessed, not hypothesised, not
speculated, but knew) that the means used were unlawful. We do not know
that, and your postings have neither convinced us that unlawful means
were used. and even if they did it would be irrlevant because we are not
responsible for releasing the code. It is done finished. There is no
trade secrect to reveal anymore. The trade secrect is dead.
RSA can try to find the person responsible and try to convince the
courts that that person revealed the secrect unlawfully, but neither RSA
nor the criminal code have any hold on us anymore.

I hope that this clarifies the argument contra your position that people
have been advancing here time and again.
--
Bill Unruh
un...@physics.ubc.ca

David Sternlight

unread,
Sep 27, 1994, 1:53:15 PM9/27/94
to
In article <36884c$n...@nntp.ucs.ubc.ca>,

I think this to be more muddying of the waters.

The presenting issue was the assertion that if it was done by reverse
engineering it is ok because the law permits reverse engineering. Your
specific statement is that the law says reverse engineering is ok. It does
not.

The truth is that it may or may not be ok depending on whether certain other
conditions are ALSO met:

1. The reverse engineer may not have stolen the trade secret;
2. The reverse engineer may not have violated a duty to secrecy;
3. The reverse engineer may not be presumed to know that someone else did 1
or 2.

THAT is what the California Code says, not that "reverse engineering is ok".

David

D. J. Bernstein

unread,
Sep 27, 1994, 3:27:26 PM9/27/94
to
Sternlight is confused as usual. The point of a clean room is to clone
a competitor's product without infringing on its copyright. If you're
at this stage, you've already broken any trade secrets in the product.

Another flaw in his argument, as several people have pointed out, is
that it's not clear RC4 meets the law's definition of ``trade secret.''

Finally, Sternlight's ``could be presumed to know'' standard is a
figment of his imagination.

Further discussion in talk.politics.crypto.

---Dan

Jay Ashworth

unread,
Sep 27, 1994, 6:09:57 PM9/27/94
to
cl...@sco.com (Clive D.W. Feather) writes:
>>> David said "Since RSADSI asserts ... either theft or breach of a duty
>>> ... must have been involved.". If you make the reasonable assumption
>>> that, before the word "either", David meant "and you assume they are
>>> telling the truth", then what is wrong with his statement ?
>> Because there's a perfectly logical third alternative, and his language
>> seemed calculated to exclude it: someone encrypted a bunch of cleartext,
>> and gave the input, output, and keys to a third party not bound by
>> anyone's license agreement with RSADSI.
>That's not what you said at the time, though.

I did say that, somewhere... but I think my news server ate the posting.

>And it's the first claim I've seen that seriously suggests that the code
>in question can be broken in that way (as a practical proposition, I
>mean; I am quite aware that it is theoretically possible).

Actually, someone else suggested this while I was waiting to see my
version of it come up. I don't recall who. We do agree it's practical,
though, right?

>>>> 1) A reverse engineer is a licensee, and there can be covered by the
>>>> more restrictive terms in that license... but why would such an
>>>> engineer _need_ to do this. They'd _have_ the code.
>>> Not necessarily.
>> Or they're a thief, in which case the license _still_ doesn't apply.
>Other way round. A licensee doesn't necessarily have the code. They may
>only have object files, in which case the licence *does* still apply.

Ok... stipulated. Hadn't thought about that possibility.

>>>> 2) A reverse engineer is not a licensee, and therefore isn't covered
>>>> by such a more-restrictive clause,
>>> But *if* the assertion of RSADSI is true, and your case 2 applies, then
>>> *someone* broke the licence. David didn't say it was the reverse
>>> engineer who did.
>> No, Clive.. this _doesn't_ follow. See above.
>If the assertion is true, and case 2 applies, then someone broke the
>licence. What doesn't follow about that.

That wasn't what I meant. What I meant was that it didn't follow that
_the licensee_, one covered by the restrictive license, was necessarily
the reverse engineer. David said that Californians "better watch out",
implying that a contract they aren't party to could bind them more tightly
than state law.

>>>> (Ever hear of the Uniform Commercial Code? Produce the contract.)
>>> No. And I'm sure it doesn't apply to me.
>> I was going to respond with "bullshit". And then I saw who the poster
>> was. :-)
>Do you know me ? Have we met in person or on the net before ? Or do you
>mean "where" rather than "who" ?

No, not personally. I guess 'where' is appropriate. I've seen quite a
bit of your news, and done quite a bit of business with SCO.

>>>> some of us _listened_ in Logic 101.
>>> Your statement number 2 makes it less than obvious that you *understood*.
>> As I noted above... no. He was asserting that people not party to a
>> contract with RSADSI were subject to a clause of such a contract which was
>> more restrictive than an explicit clause in California law.
>Not as I read it. He asserted that, if the code were reverse engineered
>(by which I think he means disassembled), then *someone* subject to such
>a contract breached it. He did *not* say that the reverse engineer did so.

Ok... he might have meant that. But it's not necessary that someone
subject to a contract had to breach it for some independent third party to
reverse engineer the code. It's possible that the contract simply wasn't
strong enough. Or, it's possible, as noted, that someone created a batch
of ciphertext, and the ciphertext, plaintext and key found their way to a
R.E.

If the license prohibits _that_ (releasing your key in conjunction with a
batch of such texts), then I submit that the license is unenforceable,
since it might make the product impossible to use.

David Sternlight

unread,
Sep 27, 1994, 8:25:33 AM9/27/94
to


In article <newcombe.7...@aa.csc.peachnet.edu>,
Dan Newcombe <newc...@aa.csc.peachnet.edu> wrote about RC4:

>But couldn't the algorithm have also been deduced via
> c) taking the original text, encrypted text, and password and working back
> from that?

Not practically speaking with respect to RC4 if we assume the alleged
version IS the real thing, except perhaps for the NSA or similarly staffed
and funded organizations.

But I'd recede in the face of a more specific reply from some of the crypto
experts here. Perhaps your question might get a more authoritative reply in
sci.crypt.research, which I am adding to the distribution list for this
reply.

David Sternlight

unread,
Sep 27, 1994, 4:05:46 AM9/27/94