- cypherpunks-legacy - lists.cpunks.org

Boulder, Colorado RMIUG Crypto-Fest 9/13 6:30pm
by Michael Johnson 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- What: Rocky Mountain Internet User's Group (RMIUG) Crypto-Fest When: Tuesday 13 September 1994 7:00pm-9:00pm, cookies at 6:30pm Where: NCAR (West end of Table Mesa Drive), Boulder, COLORADO Who: Philip Dubois (Philip Zimmermann's lawyer and a very nice guy) and Mike Johnson (alledged crypto expert, designer of the Diamond Encryption Algorithm, PGP beta tester, and PGP user). Sorry, Philip Zimmermann had a change of plans and will be at a conference in Atlanta. The show must go on! RMIUG "Crypto-Fest" A users approach to encryption with PGP (Pretty Good Privacy): I. A Very Short History of Cryptography A. Single Key Systems B. Two Key Systems (Public Key Cryptography) C. Hash Functions (MD4, MD4, SHA) D. What can be done with encryption? II. Current crypto applications III. PGP Building Blocks A. Public Key Algorithm (RSA) B. Hash function (MD5) C. Symmetric Key Algorithm (IDEA) D. Compression engine (Info-ZIP) E. ASCII armor engine F. Key database G. File formats IV. What can PGP do? What are its advantages? A. Privacy B. Authentication with nonrepudiation C. Compression (ZIP) D. ASCII armor C. Distributed Key Management (the Web of Trust) D. Inter-platform compatibility E. Wide availability F. Source code available (except for Viacrypt Digi-Sig) G. Ease of use (best around, but could be better) V. Who uses PGP? What do they use it for? VI. How do you use PGP? Read the fine manual. 2 books coming. A. Getting PGP B. Installing PGP C. Generate your key D. Distribute your public key E. Add keys from your correspondents E. Signing messages F. Encrypting messages (public key method) G. Conventional encryption pgp -c VII. History/development of PGP & Legal Issues A. Why did Philip Zimmermann write pgp? B. Legal Issues C. Version History VIII. What's happening now? A. Legal Actions & Status B. Political Action C. Future Development Plans There will be opportunities to ask questions of the two panelists during and after the presentation. ___________________________________________________________ | | |\ /| | | Michael Paul Johnson Colorado Catacombs BBS 303-772-1062 | | \/ |o| | PO Box 1151, Longmont CO 80502-1151 USA Jesus is alive! | | | | / _ | mpj(a)csn.org aka mpj(a)netcom.com m.p.johnson(a)ieee.org | | |||/ /_\ | ftp://ftp.csn.net/mpj/README.MPJ CIS: 71331,2332 | | |||\ ( | ftp://ftp.netcom.com/pub/mpj/README.MPJ -. --- ----- ....| | ||| \ \_/ | PGPprint=F2 5E A1 C1 A6 CF EF 71 12 1F 91 92 6A ED AE A9 | |___________________________________________________________| -----BEGIN PGP SIGNATURE----- Version: 2.7 iQCVAgUBLnUoSPX0zg8FAL9FAQE6nAQAmWpomcfCcWslktsuRYPNotY8kJFOwiuL BUrh5L/UbCnM8L9Gh36CF2PGjrwuxDLhlySc70yhAGpBuMijWryTk0mPcJVKDoDm 6Z9v+L0Xs4Ql2kTshYpiJg5DlUd7CKsuREN0r07xJUMybudUXM8NLUG9YGvDz4CX tIGH4nlDAS4= =Qedh -----END PGP SIGNATURE-----

1 0

Re: "Packet Sniffers"
by Oluf Bagger 17 Dec '03

17 Dec '03

You should tell the staff at your campuss that a Linux box is no greater threat than any of those PC's used for word processing. A packet sniffer can hide itself as a resident program on a doze box and collect data into a data file. Such a program can be installed by any user on the doze box or even spread as a virus. On a Linux box only root programs have access to the ethernet driver. Any packet sniffer programs can therefore only be installed by root. On a Linux box you only allow access to known users and you have log files stating when users have logged in and out. If the machine have been abused in some way you can trace the problem using the log files. Best Regards, Oluf -------------------------------------------------------------------- Oluf Bagger, Eurochip DTU. tlf: +45 4593 3332 lok. 5722 fax: +45 4593 0216

1 0

RC4
by schneier＠chinet.chinet.com 17 Dec '03

17 Dec '03

It occurs to me that if the code has not been posted to sci.crypt, then some cypherpunks reader outside the US/Canada should do so. Bruce

2 1

RC4
by schneier＠chinet.chinet.com 17 Dec '03

17 Dec '03

I've been out of e-mail range for a while, so some of sci.crypt has fallen off the back end of my host. And I don't read the full Cypherpunks feed. So some of these may be dumb questions, but they're mine and I would like them answered. Does anyone know if this is really RC4? Has anyone compiled it to see if it will run? Has anyone tried to use it to decrypt messages encrypted with some commercial RC4 program? I see that it has been posted anonymously. Was it posted to Cypherpunks only, or did it also get on sci.crypt? If not, did someone from Cypherpunks, anonymously or not, crosspost it to sci.crypt? Has there been any reaction from anybody? RSADS? NSA? NIST? I just sent a copy of Bidzos asking for comment. This seems to be a REALLY GOOD THING, but I would like some verification that it is not a hoax. Inquiring minds want to know. Bruce

3 4

Int'l Workshop on Electronic Commerce
by LAURENN%smtpgate＠earth.wri.org 17 Dec '03

17 Dec '03

With all the discussion relating to financial transactions on this list, I thought I'd forward the following call for papers that appeared in INFOSYS this weekend. -- LaurenN(a)wri.org * CALENDAR OF UPCOMING EVENTS * *The INFOSYS Calendar of Upcoming Events is updated * *fortnightly and can be obtained in the following ways: * * * *--E-mail: send the following one-line message to * * listserv(a)american.edu: get infosys calendar * *--FTP: anonymous FTP to ftp.american.edu; file is \infosys\ * * infosys.calendar * *--Gopher: gopher to auvm.american.edu; choose INFOSYS * *--WWW: http://gopher://auvm.american.edu/INFOSYS * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * ** 0298* * * * * * * * * * * * * * * * * * * * * * * * * * * * ** CALL FOR PAPERS - International Workshop on Electronic Commerce Richard Holowczak, Rutgers Univ <holowcza(a)andromeda.rutgers.edu> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * ACM International Workshop on Electronic Commerce In conjunction with The Third International Conference on Information and Knowledge Management (CIKM'94) December 2, 1994 National Institute of Standards and Technology (NIST) Gaithersburg, Maryland OBJECTIVE The workshop will provide an international forum to discuss evolving research issues and applications in the area of Electronic Commerce. Invited speakers from industry, universities and government will present their experiences and vision for the future. The Workshop will begin with a kick-off dinner on Thursday, December 1 evening and a full program on Friday, December 2. The final version of the papers will be included in an edited book that will be published by Springer Verlag as part of its Lecture Notes Series on Computer Science. INFORMATION TO AUTHORS Authors interested in participating in the workshop are invited to submit 2-3 page abstract by October 10 to: Prof. Nabil R. Adam Rutgers University 180 University Avenue Newark, NJ 07102 Fax: (201) 648-1459 E-mail: ecomm(a)adam.rutgers.edu Notification of acceptance will be sent by October 25. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * ABOUT INFOSYS INFOSYS is an electronic newsletter for faculty, students, and practitioners in the field of Information Systems. INFOSYS publishes news items, requests for assistance, announcements of professional meetings and conferences, position notices, a calendar of upcoming events, comments on recent publications, abstracts of papers that authors are willing to share, and other items of interest to the Information Systems community. INFOSYS is published biweekly, more frequently if volume requires it. INFOSYS operates as an electronic mailing list on listserv software at American University in Washington, DC. The editor is Dennis W. Viehland <d.viehland(a)massey.ac.nz>. To subscribe to INFOSYS send the following one-line electronic mail message to listserv(a)american.edu (Internet) or listserv@auvm (Bitnet): subscribe infosys yourfirstname yourlastname (e.g., subscribe infosys John Smith). You will receive a welcome letter that will tell you more about INFOSYS and listserv. Guidelines for submitting articles to INFOSYS are published in the Welcome message each new subscriber receives (or e-mail "GET infosys welcome" to listserv(a)american.edu) Send articles to infosys(a)american.edu or d.viehland(a)massey.ac.nz. * * * * * * * * * * * * * * * * * * * * * * * * ------------------------------ End of NEWSLTR Digest - 12 Sep 1994 to 13 Sep 1994 - Special issue ******************************************************************

1 0

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

e$: WSJ, CyberCash, and the Falling Barometer
by rah＠shipwright.com 17 Dec '03

17 Dec '03

On the front page of today's (9/13/94) Wall Street Journal Marketing section (Page B-1, lower right hand column) is an article about internet commerce. It talks about a group of companies who formed a consortium called CyberCash. The companies and players include the guy who started Interop, and RSA. They are claiming the ability to do credit cards and bank drafts and they say they are in negotiations with Chaum about licencing digital cash. Anonymity was specifically mentioned as a distinguishing marketable feature of digital cash. They still don't get it, but they will soon enough, I suppose. BTW, there was a veiled reference to Bibliobytes(?). At least the WSJ got their story straighter than the Times did. Like I said before, Secure Mosaic meant that "Wallets" and "Cash Registers" for digital cash were imminent. They're not imminent anymore, they're here, and they were just announced at Interop this week. I should have realized something was up, the barometer was falling at a pretty good clip. It started when I was chatting offline with someone from buyinfo and they said that they were under non-disclosure about something very big, but that I would know about it when Interop opened. Then, last Tuesday, I got an interesting cold call from a stringer for a largeish venture capital outfit in Menlo Park. He was doing due dillegence and wanted to ask me some questions about Internet Commerce, and in particular, about digital cash. I told him what I knew, and referred him to some of the senior members of these lists for much better information. I bent his ear a bit about off-line cash underwriting, and I hope it's healing now. I also sent him all of the traffic I had archived since I subscribed to cypherpunks having to do with the internet and the economics thereof. He had the buyinfo and imp-interest archives already. He seemed to think a "schmooze" conference on e$, including invitations to all the usual crypto suspects, plus people in financial operations, regulatory, political, and the institutional investor community might be a good idea. When I came back from a hike(!) in the White Mountains this weekend, I found at long last a reply to my query to DigiCash, Inc. for information. I answered the beta test questionnaire they sent me and sent it back. The barometric pressure was going down very fast all last week, and I didn't even realize it until this morning. My wife got a membership at the Harvard club. A couple of months ago we decided it was time for me to exercise (I push 350), so I work out in the morning there and walk back to the office in my house here in Roslindale (about 7 miles) about 3 or 4 times a week. (ever see the senior senator from Massachusetts' bare butt? You will... at the Harvard Club) This morning, when I looked at the Journal in the locker room, I let out a whoop. (not from seeing Teddy. From seeing the WSJ e$ article.) I was born in El Paso. I whoop a lot. Everyone in the locker room looked at me like I was from Yale, or something. Jeez. I hope we don't get blackballed. A very happy Tuesday to you all, Bob Hettinga Oh. If anyone's crazy enough to want to work on the technology part (development and integration and eventual operations) for very small startup offline digital cash underwriter, let me know. I've already started talking to a finance guy and a (very) part-time treasury management person. It also looks like the legal stuff has been figured out, or CyberCash wouldn't have done a triple-gainer into the pool like that. Any job offer would be contingent upon funding, of course. ;-). ----------------- Robert Hettinga (rah(a)shipwright.com) "There is no difference between someone Shipwright Development Corporation who eats too little and sees Heaven and 44 Farquhar Street someone who drinks too much and sees Boston, MA 02331 USA snakes." -- Bertrand Russell (617) 323-7923

2 1

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

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