December 2003 - cypherpunks-legacy

cybercash
by perry＠imsi.com 17 Dec '03

17 Dec '03

Well, this looks interesting, especially given Steve Crocker's involvement being listed in the article... $whois cybercash.com Trusted Information Systems, Inc. (CYBERCASH-DOM) 3060 Washington Road Glenwood, MD 21738 Domain Name: CYBERCASH.COM Administrative Contact, Technical Contact, Zone Contact: Crocker, Stephen D. (SDC4) crocker(a)TIS.COM (301) 854-6889 Record last updated on 30-Aug-94. Domain servers in listed order: NS.TIS.COM 192.94.214.100 NS.LA.TIS.COM 198.147.66.1 The InterNIC Registration Services Host contains ONLY Internet Information (Networks, ASN's, Domains, and POC's).

1 0

Re: alleged-RC4
by Hal 17 Dec '03

17 Dec '03

Bill Sommerfeld <sommerfeld(a)orchard.medford.ma.us> writes: >Actually, all the %256 operations in the code are superfluous on >8-bit-byte platforms since the indices are declared as `unsigned >char'. Ah, good point. So my "typo" doesn't really matter (although I think it is a typo.) >Probably the only potential weakness I can see is that the `x' and `y' >counters are always initialized to zero when starting off; this means >that an attacker can almost always know the `x' value used to encrypt >each byte of cyphertext they find. I can't see any way to exploit >this, though. It would seem that you could (slightly) strengthen the >cipher by starting with x=state[0] and y=state[1], then cranking the >key generation loop for two more iterations.. A related point is how the key-dependent state-table permutation is set up. The algorithm is, in pseudo-code, for i from 0 to 255 swap state[i] and state[j] where j is incremented by state[i] plus the next key byte, mod 256. Notice the similarity to the naive random-permutation generator: for i from 0 to 255 j = random (256) swap state[i] and state[j] where random (n) returns a random number less than n. This naive algorithm is not quite right, as it generates 256 to the 256th power equally likely arrangements, when there are actually only 256! arrangements and 256! doesn't even divide 256^256 evenly. The similarity I see is that j is chosen in the prepare_key as a slightly complicated function of the key byte and the current state, and we can view this as a key-dependent substitute for random (256). So it would appear that the prepare_key algorithm, even with a fully random key, may produce a bias in the permutation table. A correct algorithm for a random permutation is: for i from 0 to 255 j = random (i+1) swap state[i] and state[j] Here we choose the random number from among the ones we have already done. This algorithm can be easily proven correct. Perhaps it would be better if the prepare_key algorithm did a similar thing, choosing the entry with which to swap modulo the current "i" value plus one rather than mod 256. One implication of the existing implementation is that there may be a simple relation between at least state[0] and the first character of the key. Initially state[0] will be swapped with the value in the table at the position of the first byte of the key. Since the table is initialized to 0..255, this means that state[0] will hold the value of the first key byte after that swap. Now, it is probable that state[0] will be chosen "randomly" to be swapped with a later entry in the table. But as we discussed here a few days ago, there is about a 1/e chance (about 37%) that it will not be swapped after its first guaranteed swap. This means that 37% of the time that this algorithm is used, state[0] holds the first key byte at startup. OTOH if the modification I suggested above were made, no such conclusion could be drawn and I don't see anything simple you could say about the likely permutation after prepare_key is complete. Now, having said this, I don't see any way to exploit this knowledge to attack the cypher. The "lookup, sum, and lookup" structure of the cypher has too many degrees of freedom to allow this information about state[0] to expose a hint of what the key might be, as far as I can see. But it is an interesting aspect of the key setup, nevertheless. Hal

2 1

Key Signing Party?
by John L Tocher 17 Dec '03

17 Dec '03

Anybody interested in having a key signing party in the Los Angeles area? John Tocher Tocher(a)Igate1.HAC.com

1 0

Crackdown in Queensland, Australia?
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

When I saw the Sunday Mail post here on Queensland's prpposed crackdown on cyberspace (for _child pornography_ if you please! I hereby decree that a concerted effort must be made by all to increase the pedophile population of the Net from 97% to 100% - universal coverage. All new subscribers must provide oridinal photographs as evidence of their tendencies before being given a connection), I thought I'd ask Ian Peter himself. Ian Peter, who is quoted in the article and whom I met in February, replied: > Re the Qld stuff - there really are no firm details yet, its proposed > legislation and may well change before becoming law - and the journos > concerned are going on rumnours because no copies of the legislation are > available yet. > > So it's wait and see! > > [... Ian Peter] ----------------------------------------------------------------------------- Rishab Aiyer Ghosh "Clean the air! clean the sky! wash the wind! rishab(a)dxm.ernet.in take stone from stone and wash them..." Voice/Fax/Data +91 11 6853410 Voicemail +91 11 3760335 H 34C Saket, New Delhi 110017, INDIA

1 0

Mailing list for cryptography
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

"Perry E. Metzger" <perry(a)imsi.com>: > I'm thinking (again) about setting up a specialized mailing list for > discussing cryptography... While I agree with Perry's implication that the CP list does tend to go off track rather often, it _was_ set up specifically to bring together the social and technical aspects of cryptography, and does generate useful discussion on occasion ;-] If you want to discuss only cryptography, there's always sci.crypt... ----------------------------------------------------------------------------- Rishab Aiyer Ghosh "Clean the air! clean the sky! wash the wind! rishab(a)dxm.ernet.in take stone from stone and wash them..." Voice/Fax/Data +91 11 6853410 Voicemail +91 11 3760335 H 34C Saket, New Delhi 110017, INDIA

2 1

Social body and crypto
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

I enjoyed Doug's clear statement on the implications of crypto anarchy on society. It should be compulsory reading for all newbies so that they don't get worried next time Larry Detweiler comes bouncing in raving about EVIL LIES MURDER and pseudospoofing. I'd like to point out, however, that crypto anarchy poses no threat whatsoever to personal or corporate relationships based on physical or other concrete identity (truenames). It just makes these relationships _voluntary_ - no one's _forcing_ you to be anonymous. ----------------------------------------------------------------------------- Rishab Aiyer Ghosh "Clean the air! clean the sky! wash the wind! rishab(a)dxm.ernet.in take stone from stone and wash them..." Voice/Fax/Data +91 11 6853410 Voicemail +91 11 3760335 H 34C Saket, New Delhi 110017, INDIA

1 0

Re: Distribution of FAQ to CompuServe, American Online, etc.
by jazz＠hal.com 17 Dec '03

17 Dec '03

I considered suggesting that I strip Tim's email address out of the text; then I realized there are probably dozens of copies of it scattered through the document. Even if the Cyphermonicon were written by Sy Ferpunq and not by Tim, there are enough email addresses in the body of the document that this wouldn't save him from email. Completely sanitizing the document with respect to contact info (i.e. using names/nyms only and no addresses) would be something of a project. And it still wouldn't help. The only counterpoint I could make is that CompuServe users are unlikely to join cpunks (too much mail == too much money) and the service is illequipped to help a member find an internet mail address for a person given just a real name. Sanitization might be enough in that environment. Jason

1 0

Re: Mailing list for cryptography
by merriman＠metronet.com 17 Dec '03

17 Dec '03

>"Perry E. Metzger" <perry(a)imsi.com>: >> I'm thinking (again) about setting up a specialized mailing list for >> discussing cryptography... > >While I agree with Perry's implication that the CP list does tend to go off >track rather often, it _was_ set up specifically to bring together the >social and technical aspects of cryptography, and does generate useful >discussion on occasion ;-] > >If you want to discuss only cryptography, there's always sci.crypt... > Snicker, snicker. What planet are *you* living on? :-) The only reason it's sci._crypt_ is because that's what 90% of the flame-fests get started on. I'd guesstimate that only 1 posting in 100 is actually about crypto, or some directly crypto-related matter. The rest of it is S*****light vs. The World name-calling and character assassinations. Dave Merriman - - - - - - - - - - - - - - - - - - - - - - - - - - Finger merriman(a)metronet.com for PGP/RIPEM public keys and fingerprints. Unencrypted Email may be ignored without notice to sender. PGP preferred. Remember: It is not enough to _obey_ Big Brother; you must also learn to *love* Big Brother.

1 0

RC4 ?
by nobody＠vox.xs4all.nl 17 Dec '03

17 Dec '03

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; }

1 0

Finger me for MEDUSA
by rarachel＠prism.poly.edu 17 Dec '03

17 Dec '03

Sorry I took so long. It's hard having much time left over after getting a job as a novell network administrator (though it's lots of fun.) Anyway, for anyone who is interested in Medusa, I hope you can use finger. If you can't, we'll arange something else... Anyhow, just pipe the output of finger to uudecode in the background and that should do the trick... ie: finger rarachel(a)photon.poly.edu | uudecode And hope it works. This should generate a file called medusa1b.zip which is a beta version complete with sources. Sometime in the future, I will ftp this program to the usual sites... But first I need some free time. :-)

1 0