April 1993 - cypherpunks-legacy

PGP and problems therewith.
by Scott Northrop 06 Apr '93

06 Apr '93

I was under the impression that there was a newsgroup for discussion of how to use PGP. I most certainly don't mind talk about how to most effectively use PGP (PC-based decryption of files on your unsecure unix box, for example), and I don't have much room for criticism given the nil that I've contributed to this forum. But please, in the name of all that's holy, could the How To Use PGP Q&A go somewhere else? Please? Scott PS - Did the list get the message by sand(a)u.washington.edu about the correct place to put hidden data in a JPEG image? Our mail reflector burped, and we didn't get that week... :( (Mail, please, don't reply to the list.)

1 0

WB: public kiosks
by Marc.Ringuette＠GS80.SP.CS.CMU.EDU 06 Apr '93

06 Apr '93

Public kiosks are OK as a simple and moderately effective technique for assuring anonymity, and they're ideal for a security-naive person who is unable to verify the security of a more complex system. But for my own use, I am much more confident in the security guarantee given by encryption on a portable computer and anonymizing using Chaum-style remailers... -- Marc Ringuette (mnr(a)cs.cmu.edu)

1 0

PGP error.
by J. Michael Diehl 06 Apr '93

06 Apr '93

When I use the following command line in a batch file, I get a Compression/ decompression error. No files are created. The contents of the batch file is: pgp -es %1 %2 Diehl Where %1 is the name of the file to send, and %2 is the other person's name. What am I doing wrong, or is ther a problem with my pgp? Thanx in advance. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.2 mQA9Aiu/jVAAAAEBgM2F5mSlCA+KRd6TXIrqmPfiiAEytwSttZs7Yua939GMu2mP JL+5Qpi/ZKqF2nAJAwAFEbQsSi4gTWljaGFlbCBEaWVobCwgMSwgPG1kaWVobEB0 cml0b24udW5tLmVkdT4= =lyvx -----END PGP PUBLIC KEY BLOCK-----

1 0

Re: Re: PGP help and comments.
by stig＠transam.ece.cmu.edu 06 Apr '93

06 Apr '93

In message <9304040758.AA07164(a)tigger.cc.utexas.edu> you write: > >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, and even without that weakness you are >exposing yourself to the same problem that the docs mention (it is really >pretty easy to scan someone's terminal input) only you are giving them the >key outright instead of only giving them the passphrase to your key. > Yeah.... So if your key can be snooped off the net, so can your cleartext. To decript online, then, is akin to using only weak encription...which indicates only the desire for limited privacy. But if even if you do decript online, you're still protected from file snooping. What's needed is PGP decription built into your terminal program. stig

1 0

Re: WB: public kiosks
by George A. Gleason 06 Apr '93

06 Apr '93

Re public kiosks; recall that Community Memory started the idea of coin-operated kiosks years ago; and presumably still has terminals located around town. The technology is quite simple apparently. Could be genralised pretty easily. The terminals are connected to their servers via off-premise extension circuits, which allow keeping the lines open fulltime at no per-minute charge. Then you drop coins in order to respond to stuff. This of course requires a server in evrey local exchange area where you want terminals, but that should be no problem in most places. -gg

2 1

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