- cypherpunks-legacy@lists.ogf.org

wpcrack on archive site
by Eric Hughes 05 Apr '93

05 Apr '93

I just put up Ron Dippold's wpcrack code up on the ftp site, a program that breaks the (very bad) encryption of Word Perfect files. The distribution is four files wpcrack.c wpcrack.doc wpuncryp.c wpuncryp.doc in directory pub/cypherpunks/cryptanalysis. The anonymous ftp site is soda.berkeley.edu. Eric

1 0

PGP help
by J. Michael Diehl 05 Apr '93

05 Apr '93

Hi all. The manual for pgp ver. 2.2 says that it can encrypt a file for receipt by multiple users, pgp -e file user1 user2. I can't seem to get it to work. It creates one file, readable by user1. I'm using the msdos version. What am I doing wrong? Thanx in advance. +----------------------+----------------------------------------------------+ | J. Michael Diehl ;-) | I thought I was wrong once. But, I was mistaken. | | +----------------------------------------------------+ | mdiehl(a)triton.unm.edu| "I'm just looking for the opportunity to be | | Thunder@forum | Politically Incorrect! | | (505) 299-2282 | <me> | +----------------------+----------------------------------------------------+

2 1

Re: PGP help and comments.
by J. Michael Diehl 05 Apr '93

05 Apr '93

> [lost attributions, sorry] So did I! ;^) > >> I could do an ascii upload of my secret key and never expose my > >> key to disk-storage. > > This is even more dangerous than storing it on the disks of a multi-user > > machine. Unless you are running in a kerberos environment it is trivial to > > snoop your upload off the network... > I don't find the risk of a real-time snoop to be as bad as the risk > of a future snoop finding my private key alongside encrypted files that > have been stored forever (backups). I am the writer of the original post, and I quite agree with the responce that said that this was a bad idea. The whole point in being secure, is being as secure as possible. > To mitigate either problem, how about having two layers of encryption: a > private key to decrypt files for reading on a public machine, and a second > public/private pair to reencrypt the files for storage and > transmission to the home machine. The public machine knows > the first private key (if snooped) and the second public key; only the > home machine knows the second private key. Snooping the first private You still have to store a secret key somewhere. And to do that, you must trust your system administrater..... > key compromises only unread and future messages until the key is > changed. Messages archived in the reencrypted state are secure, but > messages archived in the unread state with the first private key are > still compromised forever. Is backing up mail directories a common > practice? Are there (probably system-dependent) ways to avoid backups, > such as anticipating or detecting when backups are about to occur, > hidden directories, file permissions, etc? > > Also, this system introduces some user hostility, in that > reencrypted files cannot be read again until moved to the > home machine. It was suggested that I keep my public keyring on the mainframe and use it to read mail. When I want to send mail, I encrypt it at home and upload it into my mailer. This is what I do now. I forgot who you were, but you gave me a good idea. Thanx. > Another idea is to implement the relevant features of Kerberos in > a high-level client/server package that can be used to secure personal > network communications of this kind. The package could be distributed > with PGP. What are these features? I don't know what kerberos is. +----------------------+----------------------------------------------------+ | J. Michael Diehl ;-) | I thought I was wrong once. But, I was mistaken. | | +----------------------------------------------------+ | mdiehl(a)triton.unm.edu| "I'm just looking for the opportunity to be | | Thunder@forum | Politically Incorrect! | | (505) 299-2282 | <me> | +----------------------+----------------------------------------------------+

1 0

Problems with "high quality" random number generators, FYI
by gnu＠cygnus.com 05 Apr '93

05 Apr '93

Good sources of randomness are key to good cryptography. Date: 03 Apr 1993 13:04:37 -0700 (MST) From: uunet!asgard.lpl.Arizona.EDU!schulze(a)uunet.UU.NET (Dean Schulze) Subject: Problems with "high quality" random number generators To: na.digest(a)surfer.EPM.ORNL.GOV Cc: numeric-interest(a)validgh.com Message-Id: <9304032004.AA06752(a)asgard.lpl.Arizona.EDU.LPL-West> A recent Physical Review Letter [1] points out that serious problems can arise in Monte Carlo computations due to subtle correlations in "high quality" random number generators. The quality of these number generators was determined to be "good" because they passed a battery of tests for randomness. However, they produced erroneous results when used together with the Wolff algorithm for cluster-flipping in a simulation of a 2 dimensional Ising model for which the results are known. The author of this Letter, Alan M. Ferrenburg of the University of Georgia, says that an algorithm must be tested together with the random number generator being used regardless of which tests the random number generator has passed on its own. In another development, Shu Tezuka of IBM, Tokyo and Pierre L'Ecuyer of the University of Montreal have proven that the Marsaglia-Zaman random number generators are "essentially equivalent" to linear congruential methods [2]. (Linear congruential number generators produced better results in Ferrenburg's simulations than random number generation algorithms that are of higher quality, however.) [1] Alan M. Ferrenburg, D.P. Landau, and Y. Joanna Wong, "Monte Carlo simulations: Hidden errors from 'good' random number generators", Phys. Rev. Lett., 69, pp. 3382-4, 1992. [2] Science News, v142, pg. 422, 1992. ------- End of Forwarded Message

1 0

CONF - "CopCon", organized by B Sterling
by wixer!pacoid＠cactus.org 05 Apr '93

05 Apr '93

Electronic Frontier Foundation -- Austin in conjunction with The University Co-op and The University of Texas Computer Science Department Presents ..from the Federal Computer Investigations Committee, Federal Law Enforcement Training Center, and the International Association of Computer Investigation Specialists: GAIL THACKERAY Maricopa County prosecuting attorney, Phoenix, Arizona speaking on: computer crime in the 1990s, "Operation Sundevil," corporate PBX fraud, boiler-room consumer-fraud rackets, credit-card rip-offs, pirate bulletin-board systems, and outlaw hacking! Sunday, April 18, 1993, 1:30PM-3:30PM UT Campus, Taylor Hall, room 2.106 TO BE FOLLOWED BY: C O M P U T E R S E C U R I T Y S O I R E E ! UT Co-op, Second Floor, Computer Books Section From 3:30 PM -- (?) where Ms. Thackeray will greet the Austin public and answer questions from any and all interested parties! FREE!! ..another EFF-Austin service to the Texan computer community EFF-Austin, PO Box 18957, Austin, Texas 78760 eff-austin(a)tic.com

1 0

PGP 2.2 for mac
by trump＠pluto.ee.cua.edu 04 Apr '93

04 Apr '93

yes i am looking for pgp 2.2 for mac so if anyone knows where i can find it or if anyone can tell me if they can uuencode it and mail it to me (please contact me before mailing) i would be most greatful... i do not have a mac but i have a friend at the university of wisconsin that i feel sould have pgp... so as i plea for help into the black hole of the internet cypherpunk remailer i hope to hear some feed back.... also do the people in dc want to get a cypher punk meeting together??? i am wi willing to organize... Clovis

1 0

Keys on public machines
by szabo＠techbook.com 04 Apr '93

04 Apr '93

[lost attributions, sorry] >> I could do an ascii upload of my secret key and never expose my >> key to disk-storage. >> > This is even more dangerous than storing it on the disks of a multi-user > machine. Unless you are running in a kerberos environment it is trivial to > snoop your upload off the network... I don't find the risk of a real-time snoop to be as bad as the risk of a future snoop finding my private key alongside encrypted files that have been stored forever (backups). To mitigate either problem, how about having two layers of encryption: a private key to decrypt files for reading on a public machine, and a second public/private pair to reencrypt the files for storage and transmission to the home machine. The public machine knows the first private key (if snooped) and the second public key; only the home machine knows the second private key. Snooping the first private key compromises only unread and future messages until the key is changed. Messages archived in the reencrypted state are secure, but messages archived in the unread state with the first private key are still compromised forever. Is backing up mail directories a common practice? Are there (probably system-dependent) ways to avoid backups, such as anticipating or detecting when backups are about to occur, hidden directories, file permissions, etc? Also, this system introduces some user hostility, in that reencrypted files cannot be read again until moved to the home machine. Another idea is to implement the relevant features of Kerberos in a high-level client/server package that can be used to secure personal network communications of this kind. The package could be distributed with PGP. Nick Szabo szabo(a)techbook.com

1 0

Looking for PGP porting help
by zane＠genesis.mcs.com 04 Apr '93

04 Apr '93

I'm busy (actually, I'm procrastinating doing my schoolwork ;-) porting PGP 2.2 to the Apple IIGS. I have two problems and one question-- The question: Who should I contact with the fact that I'm doing this port so that once a new version of PGP comes out all my porting work isn't lost? The problems: I'm not a very experienced C programmer/porter. I seem to be one of two people in the Apple IIGS community who's interested in porting PGP. (The other is even LESS experienced at C-- he just learned C recently.) Any ideas? Thanks, -- | Sameer Parekh-zane(a)genesis.MCS.COM-PFA related mail to pfa(a)genesis.MCS.COM | | Apprentice Philosopher, Writer, Physicist, Healer, Programmer, Lover, more | | "Be God" - Me __ "Specialization is for Insects" - Robert A. Heinlein ____/ \_____________/ \____________________________________________________/

1 0

Second posting (emucs)
by treason＠gnu.ai.mit.edu 04 Apr '93

04 Apr '93

This is the second posting I have posted about emucs (encrypted multi-user chat system) on the list. I am hoping to get a little more involvement from stable coders to help develop this product. Most of you are knowledgable of irc and how flawed it is, the ease of logging, and the fascism of the operators therof. I want to alleviate this problem by producing a multi-user chat system involving 1 server and up to 50 clients which is counterproductive to promoting logging and such. My design is easy: All messages sent from a user will be encrypted(pgp) by the pc(msdos machine initially) before its sent over the phone line, to the server. The server will then determine if the message is public or private (very easy to do) and if private, will decrypt it using the servers public key. It will then pass the message to all users on the server in unencrypted format. If it is private the server will pass it directly to the recieving party, who's client will decrypt it (if its private the sender must have the receiver's public key) and display it to their view screen. I was considering encrypting and handling everything in a private manner, but have decided that this would be more than too much load on the recieving pc's so have decided to keep only private messages completely secure. When the person wanting to engage in the chat decides to run the client, he would supply his pass phrase as a command line parameter, and it would be stored in memory until the chat is terminated. Any time a private message comes to him the client would automatically decrypt it with his key and pass phrase. There will be key handling and exchanging utilities built into the server. The client will allow for vt100 emulation and will work as a terminal program until the chat is entered, at which time, the client wwill be prompted by the server to start its new function(ie. encryption). If anyone has any ideas or wishes to help me with this, please respond to treason(a)gnu.ai.mit.edu and explain what you can do, or what ideas you have. On the last posting of this sort, there was very little response, which frightens me because of the serious need for this kind of software. Treason(a)gnu.ai.mit.edu

1 0

Mailing LIst
by x62727g2＠usma8.USMA.EDU 04 Apr '93

04 Apr '93

I am very very interested in getting on your mailing list. PLease include me. Thank you. Anthony GAtlin ------------------------------------------------------------------------------ Notice: In accordance with Title 18 USC 2511 and 18 USC 2703, any monitoring of this communication without a Federal warrant or consent of sender or receiver is in violation of Federal Law. Consent for monitoring is not given.

1 0