August 1993 - cypherpunks-legacy

Cypherpunk Mailing List
by Jon_Axelrad＠third.wsgr.com 03 Aug '93

03 Aug '93

I've read about the cypherpunks and your mailing list in recent issues of _Wired_ and the _Whole Earth Review_. I support your goals and would appreciate being added to the mailing list. While I probably couldn't contribute to discussions from a technical standpoint, I am a lawyer and may have an occasional useful comment on policy/legal matters.

1 0

mail failed, returning to sender (fwd)
by bart＠netcom.com 03 Aug '93

03 Aug '93

Forwarded message:

1 0

PKZIP Encryption is worthless
by nobody＠pmantis.berkeley.edu 03 Aug '93

03 Aug '93

To the best of my knowledge, PKZip uses a simple Vigenere algorithm for its encryption. There is a program called "zipcrack", widely available on BBSes, that does cryptanalysis of encrypted PKZip files. The rumor is that the "zipcrack" program originated in Russia, but really, cryptanalysis of the stuff that PK is using is relatively trivial. There are many good implementations of DES, including Symantec's in the Norton Utilities. You could also use PGP. But don't rely on PKZip to protect your privacy. That's not what it's designed for. Note the reply-to address above if you wish to reply.

1 0

mail failed, returning to sender
by MAILER-DAEMON＠uunorth.north.net 03 Aug '93

03 Aug '93

|------------------------- Failed addresses follow: ---------------------| accesspt.north.net!brettm ... loop detection: maximum hop count exceeded |------------------------- Message text follows: ------------------------| Received: from uunorth.uucp by uunorth.north.net with uucp (Smail3.1.28.1) id m0oNUVi-0001dLC; Tue, 3 Aug 93 18:07 EDT Received: from uunorth.uucp by uunorth.north.net with uucp (Smail3.1.28.1) id m0oNUTS-0001b8C; Tue, 3 Aug 93 18:04 EDT Received: from uunorth.uucp by uunorth.north.net with uucp (Smail3.1.28.1) id m0oNURC-0001dKC; Tue, 3 Aug 93 18:02 EDT Received: from uunorth.uucp by uunorth.north.net with uucp (Smail3.1.28.1) id m0oNUOM-0001b8C; Tue, 3 Aug 93 17:59 EDT Received: from uunorth.uucp by uunorth.north.net with uucp (Smail3.1.28.1) id m0oNULt-0001c8C; Tue, 3 Aug 93 17:57 EDT Received: from uunorth.uucp by uunorth.north.net with uucp (Smail3.1.28.1) id m0oNUJT-0001c8C; Tue, 3 Aug 93 17:54 EDT Received: from uunorth.uucp by uunorth.north.net with uucp (Smail3.1.28.1) id m0oNUH5-0001c7C; Tue, 3 Aug 93 17:52 EDT Received: from uunorth.uucp by uunorth.north.net with uucp (Smail3.1.28.1) id m0oNUEY-0001c7C; Tue, 3 Aug 93 17:49 EDT Received: from uunorth.uucp by uunorth.north.net with uucp (Smail3.1.28.1) id m0oNUBz-0001b8C; Tue, 3 Aug 93 17:46 EDT Received: from uunorth.uucp by uunorth.north.net with uucp (Smail3.1.28.1) id m0oNU9a-0001b8C; Tue, 3 Aug 93 17:44 EDT Received: from uunorth.uucp by uunorth.north.net with uucp (Smail3.1.28.1) id m0oNU79-0001c7C; Tue, 3 Aug 93 17:41 EDT Received: from uunorth.uucp by uunorth.north.net with uucp (Smail3.1.28.1) id m0oNTpc-0001c7C; Tue, 3 Aug 93 17:23 EDT Received: from uunorth.uucp by uunorth.north.net with uucp (Smail3.1.28.1) id m0oNTnB-0001c8C; Tue, 3 Aug 93 17:21 EDT Received: from uunorth.uucp by uunorth.north.net with uucp (Smail3.1.28.1) id m0oNTka-0001c8C; Tue, 3 Aug 93 17:18 EDT Received: from uunorth.uucp by uunorth.north.net with uucp (Smail3.1.28.1) id m0oNTiB-0001c8C; Tue, 3 Aug 93 17:15 EDT Received: from uunorth.uucp by uunorth.north.net with uucp (Smail3.1.28.1) id m0oNTfX-0001c8C; Tue, 3 Aug 93 17:13 EDT Received: from uunorth.uucp by uunorth.north.net with uucp (Smail3.1.28.1) id m0oNTcu-0001c8C; Tue, 3 Aug 93 17:10 EDT Received: from uunorth.uucp by uunorth.north.net with uucp (Smail3.1.28.1) id m0oNTaB-0001c7C; Tue, 3 Aug 93 17:07 EDT Received: from uunorth.uucp by uunorth.north.net with uucp (Smail3.1.28.1) id m0oNTXp-0001c7C; Tue, 3 Aug 93 17:05 EDT Received: from uunorth.uucp by uunorth.north.net with uucp (Smail3.1.28.1) id m0oNTVY-0001c8C; Tue, 3 Aug 93 17:02 EDT Received: from netcom.com by uunorth.north.net with uucp (Smail3.1.28.1) id m0oNJFk-0001eWC; Tue, 3 Aug 93 06:05 EDT Received: from toad.com by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA26190; Tue, 3 Aug 93 06:06:28 -0400 Received: by toad.com id AA20888; Tue, 3 Aug 93 02:57:42 PDT Received: by toad.com id AA20824; Tue, 3 Aug 93 02:55:25 PDT Return-Path: <bart(a)netcom.com> Received: from netcom5.netcom.com ([192.100.81.113]) by toad.com id AA20820; Tue, 3 Aug 93 02:55:23 PDT Received: by netcom5.netcom.com (5.65/SMI-4.1/Netcom) id AA27451; Tue, 3 Aug 93 02:56:11 -0700 From: bart(a)netcom.com (Harry Bartholomew) Message-Id: <9308030956.AA27451(a)netcom5.netcom.com> Subject: Other shoe drop confirmation To: cypherpunks(a)toad.com Date: Tue, 3 Aug 93 2:56:10 PDT X-Mailer: ELM [version 2.3 PL11] Well, somebody else heard the story as I did. Bart >From netcom.com!csus.edu!decwrl!decwrl!spool.mu.edu!agate!library.ucla.edu!ddsw1!uunet!news.claremont.edu!ucivax!ucla-cs!gast Tue Aug 3 02:52:20 1993 Newsgroups: alt.privacy.clipper Path: netcom.com!csus.edu!decwrl!decwrl!spool.mu.edu!agate!library.ucla.edu!ddsw1!uunet!news.claremont.edu!ucivax!ucla-cs!gast From: gast(a)cs.ucla.edu Subject: FBI wants to ban Crypto Message-ID: <1993Aug3.012316.9036(a)cs.ucla.edu> Originator: gast(a)oahu.cs.ucla.edu Sender: usenet(a)cs.ucla.edu (Mr Usenet) Nntp-Posting-Host: oahu.cs.ucla.edu Reply-To: gast(a)CS.UCLA.EDU (David Gast) Organization: UCLA Computer Science Department Distribution: alt Date: Tue, 3 Aug 93 01:23:16 GMT Lines: 10 I just heard a little of the report on NPR on Saturday, but it seems that the FBI went public last week at a security conference with its desires to ban cryptography, at least crypto that it cannot break. The FBI said that in four different wiretap cases, it got encrypted messages instead of talk. I know that the FBI has previously announced similar plans including at CFP-2, but this seems to be a new salvo. David --

1 0

another shirt idea...
by Brian D Williams 03 Aug '93

03 Aug '93

How 'bout this one; NSA Mother to Big Brother MYK-78 Brian Williams Cypherpatriot

1 0

PKZIP Encryption Been Compromised?
by Reply to: hahn＠lds.loral.com 03 Aug '93

03 Aug '93

A friend of mine tells me that the encryption feature of the PKZIP compressor/archiver is vulnerable. I have been using it for private material that is not to be passed to anybody else. To what extent is this material vulnerable to attack, given that the attacker has no examples of a plaintext/ciphertext pair using my key. Also, to what extent is the vulnerability a function of the key length? Thanks in advance to anybody who can help me. Karl | (V) | "Tiger gotta hunt. Bird gotta fly. | (^ (`> | Man gotta sit and wonder why, why, why. | ((\\__/ ) | Tiger gotta sleep. Bird gotta land. | (\\< ) der Nethahn | Man gotta tell himself he understand." | \< ) | | ( / | Kurt Vonnegut Jr. | | | | ^ |

1 0

REMAIL: Virtual remailers
by anonymous＠extropia.wimsey.com 03 Aug '93

03 Aug '93

-----BEGIN PGP SIGNED MESSAGE----- I run two remailers; one is hal(a)alumni.caltech.edu and the other is hfinney(a)shell.portal.com. The first one is on a system to which I have free access, while the second is on a system for which I am paying about $40 a month. I feel like the second one is "stronger" politically, since I am paying hard-earned money for it. Also, I remember the summaries that were posted of last year's Hacker's conference, in which it was stated that the owner of the Portal system was eager to support remailers. I don't know if he realizes that he is indirectly supporting them now since I am using my Portal account to run one, but I feel that if they get some complaints and come to me, I might be able to get the boss to step in on my behalf. Given this situation, it has occured to me that it would be easy to have the caltech remailer forward all mail to the portal remailer, to be remailed from there. This way nobody would receive objectionable mail from the caltech account, and no one would ask for it to be shut down. In the past, we have had suggestions that this would be a desirable mode of operation for our cypherpunks remailers: to have the "front ends" be a different set of machines than the actual remailers. It was said that this would represent a sort of "distributed computing" environment, a "virtual remailer" that would span the network, thus making it harder to shut down. I did not really agree with these arguments, since I felt that the targets would simply be the final-remailing machines, since these are the ones from which people would receive anonymous mail. If they were shut down, then other machines would have to come on-line to replace them. Given that such replacements actually existed, I felt that it would be better simply to use them from the beginning as stand-alone remailers, so that there would be more remailers out there for people to use. Now I am faced with a concrete test of this principle, and I'm soliciting suggestions. Would it be better to keep my two remailers operating, even though I might eventually have to shut one down due if complaints arise? Or should I make one just a front-end for the other, thereby creating a "virtual remailer" (a term I don't really agree with) which spans the two machines and which makes it unlikely that the front-end remailer at caltech will be terminated. Are there any advantages to having the caltech remailer if it just feeds into the one at portal? I'm not sure I see much point in keeping it operating if it performs no useful task. On the other hand, if people do see advantages, we could create a set of "second-tier" remailers which would be politically safe. They would always feed into one of the "first-tier" remailers which would be the ones which would actually send mail. No anonymous mail or postings would ever come from these second-tier remailers, hence their operators, owners, and sysops would receive no complaints. Perhaps more people would be willing to run remailers on this basis, knowing they were relatively immune from political pressure. Hal Finney hfinney(a)shell.portal.com -----BEGIN PGP SIGNATURE----- iQCVAgUBLF2/d6gTA69YIUw3AQEHOQP/dU996sl0yQk8FlbSVG3LjUzLOIg7ktGs 57IRPU9zWJXOTGbxxhcA/p+kApXzU4hwnLV4ch9+DFst/hPFDMoHuuetmUMSLscL EjaCz5ySzS532i/6TdfNbHMiDMgpWNIorQCysC+Ilpi5J9VCBXURbd0ZSlMPj19a 0crq5P/scvA= -----END PGP SIGNATURE-----

2 1

Sign my Key?
by J. Michael Diehl 03 Aug '93

03 Aug '93

Hi all! Well, I'm getting married Aug. 7. for our Honeymoon, we are taking a driving trip through Pheonix, Az., Las Angeles, Ca., Sacramento, Ca., and Denver Co. I MIGHT be able get away from my wife in order to have my pub key signed. Are there any Cypherpunks in these cities who might be willing to sign my key? Thanx in advance. Laters. ========================+==========================================+ J. Michael Diehl ;^) | Have you hugged a Hetero........Lately? | mdiehl(a)triton.unm.edu | "I'm just looking for the opportunity to | mike.diehl(a)fido.org help| be Politically Incorrect!" +=========+ al945(a)cwns9.ins.cwru.edu| Is Big Brother in your phone? | PGP KEY | (505) 299-2282 (voice) | If you don't know, ask me. |Available| ========================+================================+=========+ PGP Key = 7C06F1 = A6 27 E1 1D 5F B2 F2 F1 12 E7 53 2D 85 A2 10 5D This message is protected by 18 USC 2511 and 18 USC 2703. Monitoring by anyone other than the recipient is absolutely forbidden by US Law

1 0

BOOK: Differential Cryptanalysis
by Karl Barrus 03 Aug '93

03 Aug '93

Just yesterday I saw _Differential Cryptanalysis of the Data Encryption Standard_ by Biham and Shamir at a local bookstore and immediately purchased it. It is published by Springer-Verlag (who also publish Salomaa's _Public Key Cryptography_); ISBN 0-387-97930-1 and 3-540-97930-1. The book describes the differential cryptanalysis attack, which is also applicable to "bounded-round versions" of certain other cryptosystems [what is a "bounded-round version" anyway?]. Phil Zimmerman is acknowledged in the Preface [could this be the same prz of PGP?] I haven't had a chance to read the book - I've just been flipping around so far, but here are the chapters: 1 Introduction 2 Results 3 Introduction to Differential Cryptanalysis 4 Differential Cryptanalysis of DES Variants four rounds six rounds eight rounds arbitrary number of rounds modified variants of DES DES with independent keys generalized DES 5 Differential Cryptanalysis of the Full 16-Round DES 6 Differential Cryptanalysis of FEAL FEAL-8 FEAL-N and FEAL-NX other properties 7 Differential Cryptanalysis of Other Cryptosystems Khafre REDOC-II LOKI Lucifer 8 Differential Cryptanalysis of Hash Functions Snefru N-Hash 9 Non-Differential Cryptanalysis of DES with a Small Number of Rounds Ciphertext Only Known Plaintext Statistical Known Plaintext Appendix A: Description of DES Appendix B: Difference Distribution Tables of DES I doesn't look like IDEA, MD4, or MD5 are mentioned. /-----------------------------------\ | Karl L. Barrus | | elee9sf(a)menudo.uh.edu | <- preferred address | barrus(a)tree.egr.uh.edu (NeXTMail) | \-----------------------------------/

1 0

Re: Sterilized medflies of crypto
by nate＠VIS.ColoState.EDU 03 Aug '93

03 Aug '93

Detweiler says: We should fight the only thing which matters: key registration. I think that he has a point here. The SkipJack *may* be secure, it may not (my feeling is that it is not), but the whole bit about key registration is absolutely absurd (at best). -nate sammons nate(a)vis.colostate.edu

1 0