December 2003 - cypherpunks-legacy

Number Theory
by Matt Thomlinson 17 Dec '03

17 Dec '03

Peter Murphy writes: >... > >and see the major number theorist in this department, Dr. Keith Matthews. >He is a really nice guy, and is always interested in writing and/or >distributing programs for number theory calculations. He even showed me >one of his newest programs, and demostrated it by factoring 2^71 -1 for Is this really that impressive? MapleV and my 386dx-20 just factored it into 212885833 * 48544121 * 228479 in a matter of 23 cpu seconds. >he teaches, and could I post it to the list. Voila! Not only did he have >it printed out on paper, but he also mailed me the relevant LATEX files. way cool. thanks for the legwork.. >{Textbooks: Number Theory} >... >N. Koblitz, "A course in number theory and cryptography", QA3.G7NO.114, Speaking of who .. he's at my university. :) Nice guy; one of the people who offered to help me with the remailer situation last year. Funny thing; last year the computer administrators wouldn't even allow a copy of PGP to reside on their systems -- now it is part of their public account (student-run officially University unsupported software, usable by all). >H. Shapiro, "Introduction to number theory", QA 241.S445 1983, this isn't the Hawk Shapiro..? >D.E.R. Denning, "Cryptography and Data Security", Addison-Wesley, 1982, > QA76.9.A25D461982 sigh. mt Matt Thomlinson University of Washington, Seattle, Washington. phone: (206) 548-9804 Check my home page -- ftp://ftp.u.washington.edu/public/phantom/home.html PGP 2.2 key available via email, or finger phantom(a)hardy.u.washington.edu

3 2

fake pgp messages
by hh＠xcf.Berkeley.EDU 17 Dec '03

17 Dec '03

in the process of doing stuff to fight traffic analysis, i need to generate a bunch of fake pgp messages. it is possible to asciiarmor random bits, but this is pretty easy to spot. does anyone know a good way to generate a large amount of bogus pgp messages? e

4 3

Re: fake pgp messages
by Jeff Davis 17 Dec '03

17 Dec '03

Eric Hollander asked about faking pgp messages. How much disk space do you have? I have a couple of megs of active files of text I could email you and you could just send them out as ascii.armored real messages. -- PGP PUBLIC KEY via finger! JAFEFFM Speaking & Thinking For Myself! * eagle(a)deeptht.armory.com email info(a)eff.org * *** O U T L A W S On The E L E C T R O N I C F R O N T I E R **** ***** Committed to Free Public Internet Access for World Peace *****

1 0

rng, anyone?
by Erich von Hollander 17 Dec '03

17 Dec '03

i'm doing some stuff on this remailer which requires a good rng. perl's rng just calls c's rng, which totally sucks. does anyone know of a cryptographically sound rng i can use? i could just call it from perl or something. thanks, e

2 1

Re: fake pgp messages
by cort 17 Dec '03

17 Dec '03

> > in the process of doing stuff to fight traffic analysis, i need to generate > > a bunch of fake pgp messages. it is possible to asciiarmor random > > bits, but this is pretty easy to spot. does anyone know a good > > way to generate a large amount of bogus pgp messages? > > What better way than to generate real pgp messages that encrypt noise files? > Just generate pseudorandom binary data of pseudorandom length (biased > toward the length of real messages), and encrypt with pgp, using the > public key of some person's key from a public server, selected at > random. If you want to be able to spend less cpu time, you could hack a > copy of pgp to simulate doing this, of course, using the symmetric key > cipher (idea) in a stream cipher mode. > Better "noise" might be _real_ words, paragraphs, etc. It occurred to me once that some of the remailer operators could bounce the cypherpunks mailing list around through their remailers to get more traffic/noise. Cort.

1 0

Press Release on Secure NCSA Mosiac
by Dave Banisar 17 Dec '03

17 Dec '03

Secure NCSA Mosaic establishes necessary framework for electronic commerce onthe Internet PALO ALTO, CALIF. (APRIL 12) BUSINESS WIRE - April 12, 1994-- Enterprise Integration Technologies (EIT), the National Center for Supercomputing Applications (NCSA) at the University of Illinois and RSA Data Security Tuesday announced agreements to jointly develop and distribute a secure version of NCSA Mosaic, the popular point-and-click interface that enables easy access to thousands of multimedia information services on the Internet. The announcement was made in conjunction with the launch of CommerceNet, a large-scale market trial of electronic commerce on the Internet. Under the agreements, EIT will integrate its Secure-HTTP software with public key cryptography from RSA into NCSA Mosaic Clients and World Wide Web (WWW) servers. WWW is a general-purpose architecture for information retrieval comprised of thousands of computers and servers that is available to anyone on Internet. The enhancements will then be made available to NCSA for widespread public distribution and commercial licensing. Jay M. Tenenbaum, chief executive officer of EIT, believes secure NCSA Mosaic will help unleash the commercial potential of the Internet by enabling buyers and sellers to meet spontaneously and transact business. "While NCSA Mosaic makes it possible to browse multimedia catalogs, view product videos, and fill out order forms, there is currently no commercially safe way to consummate a sale," said Tenenbaum. "With public key cryptography, however, one can authenticate the identity of trading partners so that access to sensitive information can be properly accounted for." This secure version of NCSA Mosaic allows users to affix digital signatures which cannot be repudiated and time stamps to contracts so that they become legally binding and auditable. In addition, sensitive information such as credit card numbers and bid amounts can be securely exchanged under encryption. Together, these capabilities provide the foundation for a broad range of financial services, including the network equivalents of credit and debit cards, letters of credit and checks. In short, such secure WWW software enables all users to safely transact day-to-day business involving even their most valuable information on the Internet. According to Joseph Hardin, director of the NCSA group that developed NCSA Mosaic, over 50,000 copies of the interface software are being downloaded monthly from NCSA's public server - with over 300,000 copies to date. Moreover, five companies have signed license agreements with NCSA and announced plans to release commercial products based on NCSA Mosaic. "This large and rapidly growing installed base represents a vast, untapped marketplace," said Hardin. "The availability of a secure version of NCSA Mosaic establishes a valid framework for companies to immediately begin large- scale commerce on the Internet." Jim Bidzos, president of RSA, sees the agreement as the beginning of a new era in electronic commerce, where companies routinely transact business over public networks. "RSA is proud to provide the enabling public key software technology and will make it available on a royalty-free basis for inclusion in NCSA's public distribution of NCSA Mosaic," said Bidzos. "RSA and EIT will work together to develop attractive licensing programs for commercial use of public key technology in WWW servers." At the CommerceNet launch, Allan M. Schiffman, chief technical officer of EIT, demonstrated a working prototype of secure NCSA Mosaic, along with a companion product that provides for a secure WWW server. The prototype was implemented using RSA's TIPEM toolkit. "In integrating public key cryptography into NCSA Mosaic, we took great pains to hide the intricacies and preserve the simplicity and intuitive nature of NCSA Mosaic," explained Schiffman. Any user that is familiar with NCSA Mosaic should be able to understand and use the software's new security features. Immediately to the left of NCSA's familiar spinning globe icon, a second icon has been inserted that is designed to resemble a piece of yellow paper. When a document is signed, a red seal appears at the bottom of the paper, which the user can click on to see the public key certificates of the signer and issuing agencies. When an arriving document is encrypted, the paper folds into a closed envelope, signifying that its formation is hidden from prying eyes. When the user fills out a form containing sensitive information, there is a "secure send" button that will encrypt it prior to transmission. To effectively employ public-key cryptography, an infrastructure must be created to certify and standardize the usage of public key certificates. CommerceNet will certify public keys on behalf of member companies, and will also authorize third parties such as banks, public agencies and industry consortia to issue keys. Such keys will often serve as credentials, for example, identifying someone as a customer of a bank, with a guaranteed credit line. Significantly, all of the transactions involved in doing routine purchases from a catalog can be accomplished without requiring buyers to obtain public keys. Using only the server's public key, the buyer can authenticate the identity of the seller, and transmit credit card information securely by encrypting it under the seller's public key. Because there are fewer servers than clients, public key administration issues are greatly simplified. To successfully combine simplicity of operation and key administration functions with a high level of security that can be accessible to even non- sophisticated users, significant changes were necessary for existing WWW security protocols. EIT developed a new protocol called Secure-HTTP for dealing with a full range of modern cryptographic algorithms and systems in the Web. Secure-HTTP enables incorporation of a variety of cryptographic standards, including, but not limited to, RSA's PKCS-7, and Internet Privacy Enhanced Mail (PEM), and supports maximal interoperation between clients and servers using different cryptographic algorithms. Cryptosystem and signature system interoperation is particularly useful between U.S. residents and non-U.S. residents, where the non-U.S. residents may have to use weaker 40-bit keys in conjunction with RSA's RC2 and RC4 variable keysize ciphers. EIT intends to publish Secure-HTTP as an Internet standard, and work with others in the WWW community to create a standard that will encourage using the Web for a wide variety of commercial transactions. EIT will make Secure NCSA Mosaic software available at no charge to CommerceNet members in September and NCSA will incorporate these secure features in future NCSA Mosaic releases. Enterprise Integration Technologies Corp., of Palo Alto, (EIT), is an R&D and consulting organization, developing software and services that help companies do business on the Internet. EIT is also project manager of CommerceNet. The National Center for Supercomputing Applications (NCSA), developer of the Mosaic hypermedia browser based at the University of Illinois in Champaign, Ill., is pursuing a wide variety of software projects aimed at making the Internet more useful and easier to use. RSA Data Security Inc., Redwood City, Calif., invented Public Key Cryptography and performs basic research and development in the cryptographic sciences. RSA markets software that facilitates the integration of their technology into applications. Information on Secure NCSA Mosaic can be obtained by sending e-mail to shttp- infoeit.com. --30--pc/sf CONTACT: Hamilton Communications Nancy Teater, 415/321-0252 KEYWORD: CALIFORNIA ILLINOIS INDUSTRY KEYWORD: COMPUTERS/ELECTRONICS COMED Z REPEATS: New York 212-575-8822 or 800-221-2462; Boston 617-330-5311 or 800- 225-2030; SF 415-986-4422 or 800-227-0845; LA 310-820-9473 Transmitted: 94-04-12 12:08:00 EDT

1 0

Re: Quants vs Congress
by Mike Markley 17 Dec '03

17 Dec '03

---------- | From: Timothy C. May <netmail!tcmay(a)netcom.com> | To: John E. Kreznar <jkreznar(a)ininx.com> | Cc: <cypherpunks(a)toad.com> | Subject: Re: Quants vs Congress | Date: Wednesday, April 13, 1994 8:13PM | | Received: from relay2.UU.NET by netmail.microsoft.com with SMTP (5.65/25-eef) | id AA14155; Wed, 13 Apr 94 19:20:40 -0700 | Received: from toad.com by relay2.UU.NET with SMTP | (5.61/UUNET-internet-primary) id AAwlnp10043; Wed, 13 Apr 94 23:21:22 -0400 | Received: by toad.com id AA17257; Wed, 13 Apr 94 20:13:54 PDT | Received: from mail.netcom.com (netcom5.netcom.com) by | toad.com id AA17248; Wed, 13 Apr 94 20:13:47 PDT | Received: from localhost by mail.netcom.com (8.6.4/SMI-4.1/Netcom) | id UAA15518; Wed, 13 Apr 1994 20:13:38 -0700 | Message-Id: <199404140313.UAA15518(a)mail.netcom.com> | In-Reply-To: <9404140219.AA09878@ininx> from "John E. Kreznar" | at Apr 13, 94 07:19:36 pm | X-Mailer: ELM [version 2.4 PL23] | Mime-Version: 1.0 | Content-Type: text/plain; charset=US-ASCII | Content-Transfer-Encoding: 7bit | Content-Length: 1913 | Sender: netmail!owner-cypherpunks(a)toad.com | Precedence: bulk | | John Krexnar writes: | | (Duncan Frissell's section elided) | | > Aw c'mon Duncan. Derivative of what? What's a quant? Where was the | > term ``intermediation of political risk'' used? | > | > I love your postings when I can make sense of them. This one is so well | > encrypted I can't. | | "Derivatives" mean secondary financial instruments, based on ("derived | from") things like stocks, bonds, and real estate. Things like futures | markets, "baskets" of other instruments, etc. These started, it may be | argued, in the trading pits of Chicago, but have now spread around the | world. I think I recall reading (in "Time"'s cover story last week on | derivatives and quants, ironically enough--the Wall Street nerd with | the "messy room" has replaced the hacker as the Number One Threat to | Civilization) that $ 4 Trillion in derivatives trades _daily_. | | "Quants," closely related to "rocket scientists," are those who use | math and statistics for investment purposes. Short for "quantitative." | | I urge all Cypherpunks who can afford to do so to subscribe to "The | Economist." It's filled with good, incisive articles, including the | best treatments of breaking science and technology stories in any | general magazine. Shoot your t.v., maybe, but don't let your | subsription lapse. Available also on newstands, whence information on | subscribing may be found (read the mag long enough, and you too will | speak in terms of "whence"). | | --Tim May | | | -- | .......................................................................... | Timothy C. May | Crypto Anarchy: encryption, digital money, | tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero | 408-688-5409 | knowledge, reputations, information markets, | W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. | Higher Power: 2^859433 | Public Key: PGP and MailSafe available. | "National borders are just speed bumps on the information superhighway." | The derivatives market is a very dangerous place also. In yesterdays financial section here in Seattle there was an article about how Proctor and Gamble is reporting a loss of over $100 million in the mortgage derivative market. Also in RISKS Digest 15.75 there is an article with the subject ' God Grants Granite Gift to RISKS Punsters' that talks about a company losing $600 million over the period of several weeks in the deriviative market. Mike. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Mike Markley || The opinions here do not represent the mmarkley(a)microsoft.com || opinions of my employer. Attempts to || associate the two are pointless. "I want to look at life, In the available light" - Neil Peart -

2 1

Re: Soldier of Fortune
by Duncan Frissell 17 Dec '03

17 Dec '03

M > M >This seems counterproductive. PGP should not be portrayed as a tool M >for those that most Americans consider antisocial. M > M >M Carling M > A quote from pgpdoc1.doc: "If privacy is outlawed, only outlaws will have privacy. Intelligence agencies have access to good cryptographic technology. So do the big arms and drug traffickers. So do defense contractors, oil companies, and other corporate giants. But ordinary people and grassroots political organizations mostly have not had access to affordable "military grade" public-key cryptographic technology. Until now." Now Phil wrote PGP in part so that "grassroots" political organizations could have strong crypto. SOF is a "grassroots political organization." It happens that some people don't like SOF. It happens that some other people think that the organizations that Phil was thinking of when he wrote PGP are unamerican communist front organizations who should be on the Attorney General's List (if we still had an Attorney General's List)(if we still had an Attorney General). Tastes differ. The point of cypherpunks is that everyone (even FBI agents) should have strong crypto if they want it. I know that Phil feels a personal sense of embarrassment at being adopted by all sorts of nut groups (including ourselves) and he has pleaded for stories of "worthy PGP use." Standards of worthiness will vary. DCF Who, as it happens, *is* a member of an organization on the Attorney General's list. --- WinQwk 2.0b#1165

2 1

Re: fake pgp messages
by Ian Turton 17 Dec '03

17 Dec '03

> > > in the process of doing stuff to fight traffic analysis, i need to generate > > > a bunch of fake pgp messages. it is possible to asciiarmor random > > > bits, but this is pretty easy to spot. does anyone know a good > > > way to generate a large amount of bogus pgp messages? > > > > What better way than to generate real pgp messages that encrypt noise files? > > Just generate pseudorandom binary data of pseudorandom length (biased > > toward the length of real messages), and encrypt with pgp, using the > > public key of some person's key from a public server, selected at > > random. If you want to be able to spend less cpu time, you could hack a > > copy of pgp to simulate doing this, of course, using the symmetric key > > cipher (idea) in a stream cipher mode. > > > > Better "noise" might be _real_ words, paragraphs, etc. > > It occurred to me once that some of the remailer operators could > bounce the cypherpunks mailing list around through their remailers > to get more traffic/noise. why not take a random news group comp.talk.eff seems like a good one and encrypt that and mail out one article whenever you need or whenever your news server recieves one. You could then tailor the frequency by choosing high or low volume news groups. > > Cort. > > > Ian Turton - School of Geography, Leeds University 0532 -333309

1 0

Code review is requested.
by kafka＠desert.hacktic.nl 17 Dec '03

17 Dec '03

In article <199404110553.AA00997@xtropia>, you write the following: AN> Cypherpunks review code! AN> AN> I have written a hack to allow pgp's random.h and random.c to be used AN> with a hardware random number generator. I have mailed this to a AN> number of U.S. cypherpunks with the request that the hack be AN> distributed widely in the U.S. test --- "In a Time/CNN poll of 1,000 Americans conducted last week by Yankelovich Partners, two-thirds said it was more important to protect the privacy of phone calls than to preserve the ability of police to conduct wiretaps. When informed about the Clipper Chip, 80% said they opposed it." - Philip Elmer-Dewitt, "Who Should Keep the Keys", TIME, Mar. 4 1994 == To get PGP, FTP /pub/unix/security/crypt/pgp23A.zip from ftp.funet.fi ==

1 0

NBC's Kaul
by Jeff Davis 17 Dec '03

17 Dec '03

Well, NBC's Alan Kaul and I had a discussion a few moments ago. Apparantly a helicopter crashed and this is old news. He has been instructed by NBC superiors to move on. The downplaying by the NSA was key. It wasn't another "Pentagon Papers" leak. He's got my unlisted number and asked if he could call from time to time to use me as an informed source, and asked to be kept on my mailing list. I guess I'll scrounge up that abitrary finger data from the AmEmbMoscow.gov deal and send that to him as an item of interest. Perhaps a CIA hand was logged on when that stuff popped up on the screen... This is not a topic for discussion. I know some of you have grown to care about me, and some rip me routinely. I am responsible and accountable for my own actions. "Those who risk nothing, are nothing, do nothing, and become nothing." By the time you rebut, that finger information will be gone. -- PGP PUBLIC KEY via finger! JAFEFFM Speaking & Thinking For Myself! * eagle(a)deeptht.armory.com email info(a)eff.org * *** O U T L A W S On The E L E C T R O N I C F R O N T I E R **** ***** Committed to Free Public Internet Access for World Peace *****

1 0

Re: Soldier of Fortune
by m＠BlueRose.com 17 Dec '03

17 Dec '03

I happen to like SOF, and I don't think most Americans have a bad opinion of it (certainly some do, but that is true of any publication). But SOF's appeal is much broader than just "mercs and wannabees" [Sandy's words], and that "mercs and wannabees" is probably the subfocus of SOF that most Americans find the least tasteful of what SOF is about. Most Americans don't think highly of mercenaries. If anyone is going write something for SOF about PGP, I hope that the article focuses on anything but "mercs and wannabees". M Carling Begin forwarded message: Date: Thu, 14 Apr 1994 12:33:04 -0400 From: Duncan Frissell <frissell(a)panix.com> To: CYPHERPUNKS(a)toad.com Subject: Re: Soldier of Fortune Sender: owner-cypherpunks(a)toad.com Precedence: bulk M > M >This seems counterproductive. PGP should not be portrayed as a tool M >for those that most Americans consider antisocial. M > M >M Carling M > A quote from pgpdoc1.doc: "If privacy is outlawed, only outlaws will have privacy. Intelligence agencies have access to good cryptographic technology. So do the big arms and drug traffickers. So do defense contractors, oil companies, and other corporate giants. But ordinary people and grassroots political organizations mostly have not had access to affordable "military grade" public-key cryptographic technology. Until now." Now Phil wrote PGP in part so that "grassroots" political organizations could have strong crypto. SOF is a "grassroots political organization." It happens that some people don't like SOF. It happens that some other people think that the organizations that Phil was thinking of when he wrote PGP are unamerican communist front organizations who should be on the Attorney General's List (if we still had an Attorney General's List)(if we still had an Attorney General). Tastes differ. The point of cypherpunks is that everyone (even FBI agents) should have strong crypto if they want it. I know that Phil feels a personal sense of embarrassment at being adopted by all sorts of nut groups (including ourselves) and he has pleaded for stories of "worthy PGP use." Standards of worthiness will vary. DCF Who, as it happens, *is* a member of an organization on the Attorney General's list. --- WinQwk 2.0b#1165

2 1

uses for PGP
by Ed Carp 17 Dec '03

17 Dec '03

Here's the text of a message I sent to Phil. Thought I'd share it with y'all... ----------

1 0

cypherpunks and politics (Re: USWA)
by jamiel＠sybase.com 17 Dec '03

17 Dec '03

At 2:21 AM 04/14/94 -0500, Adam Lake wrote: >Did anyone ever think of involving the USWA (no, not the United States >Wrestling Association) United We Stand America in the Clipper fight? >Sounds to me like this would be a mass appeal if it appeared in their >newsletter. This is something I have been meaning to write to the list for several weeks, and this post is the perfect lead in. When I joined this list, I saw thought it was going to be much different. I had assumed 1) that people on this list would have much different politics and 2) that that wouldn't really matter, 'cause everyone here is concerned with one issue, which we could all agree on. 2) seems to have partially true, sometimes. Without expounding at lengths, my reaction was to unsubscribe on short order when I saw some of the first posts flying around. I didn't, because I try to keep an open mind and do change opinions sometimes. But not everyone who is a potential crypto supporter is gonna bother, and by tying (seemingly or not- impressions count here) the issue to a particular set of other beliefs, there is a huge chance that others are going to be alienated. I know *I* don't want to be associated with libertarianism or (even worse) Perot... The point is that even if you think anyone with a viewpoint opposing yours is automatically stupid and not worth your time (and I don't think that too many of you are that bad off ;), aren't they at least worth using to further something you believe strongly in? It might do well to be careful in alienating potential allys by flip political jokes and comments. -j

2 1

Re: fake pgp messages
by jamiel＠sybase.com 17 Dec '03

17 Dec '03

What about a chron task that creates a new PGP key every x hours and encrypts random Usenet posts, according to traffic patterns (if there it tons of real activity, don't do much, if little, do more. just a thought. -j

1 0

Speech compression and encryption (Secure Phone)
by danisch＠ira.uka.de 17 Dec '03

17 Dec '03

Hi folks, we want to start a project for a computer science class at the University of Karlsruhe. We want to write software to use a workstation/PC with a modem, speaker, and microphone as a secure Phone with encryption and authentication. Therefore we need speech compression. Can anyone give me hints to books, articles, algorithms or software for speech compression? Is CELP public available? Thanks a lot Hadmut

2 1

Re: Need info re Clipper/encryptions
by PAPAMICHAIL 17 Dec '03

17 Dec '03

I'm writing a script, need someone to advise me on technical points re encryption, cracking computers and other things I probably shouldn't know. If there's anyone out there that can help please contact me via CompuServe 72133,1415 P.S. I'm no computer wiz. Thanks - ERB

1 0

Re: Another reason for anonymity
by Jim Sewell - KD4CKQ 17 Dec '03

17 Dec '03

Preface: I inadvertently sent this via regular mail to Tim directly instead of on the list. He noted, correctly, that it should have been put to the list so I'm copying it there. Jim <My computer told me that Timothy C. May said:> > > (You should carry these discussions on the main list, so I can justify > putting more time into the replies.) > > > <My computer told me that Timothy C. May said:> > > > [ discussion of anonymity and defamation of character omitted since it's been posted before. - JCS] > > > > But what about the credit checking systems now or the "Data Hiway" (I'm > > growing very weary of the I.S. catchphrase) of the near future? What if > > I can type, anonymously, that Tim May is a pedophile and every newspaper, > > and thus every home, in the world sees it? Do you think you'd get a job > > as a elementary school teacher? Not likely. People always remember the > > accusation but rarely the retraction. Do you think Michael Jackson will > > ever shrug off the child molestation charges? Not fully. Even now, if > > I have a business and I tell XYZ Credit Check Company that you didn't > > pay your bill and owe me $1,000,000.00 then you're ruined! Oh, that's > > right, for me to report it I have to say who I am and then you can sue > > me for ruining your life. > > False or frivolous accusations are often made, and people take into > account the source. This is what free speech entails. Once again, though, if someone is granted anonymity then people can not take into account the source unless reputations are attached to the pseudonym, as you mention: > Look into how "reputations" work. > > As to the Michael Jackson case, people believed it because his > behavior supported the charges, there were corroborating witnesses, etc. > But we are guaranteed the right to face our accusor in legal cases which would go away with complete anonymity. > > > (What about shouting "Fire!" in a crowded theater? Let those who see > > > there's no fire beat the shit out of the twerp who shouted "Fire!" > > > Seems fair to me.) > > > > > > > Oops, tactical error, Tim. Under your statements a guy can shout "Fire!" > > anonymously so who do you "beat the shit out of" then? Neither argument > > (for or against anonymity) is water proof. > > No, if its anonymous, then it can't be punished anyway. I'm in favor > of "screenable anonymity": set your e-mail filters to ignore any > messages except from those names or pseuodonyms you place faith in. > Simple. Ok, so it is not just blind anonymity but rather one with some degree of responsibility and reputation, thus your psuedonym becomes known as a distinct entity that is not tied to you. Perhaps... > (My point about the "Fire!" example is that a rare, and solvable, > problem has been used inappropriately for decades to place legal > limits on free speech.) And a valid point it is. It seems that in 50 years we could have come up with a better example of limiting freedom than this. -- Tantalus Inc. Bringing people together Jim Sewell-KD4CKQ 2407 N. Roosevelt Blvd. to have a little fun. Internet: jims(a)mpgn.com Key West, FL 33041 CIS: 71061,1027 (305) 293-8100 "We keep coding and coding and coding..."

1 0

re:My public key
by SGT=DARREN=S.=HARLOW%ISB%MCTSSA＠nwsfallbrook3.nwac.sea06.navy.mil 17 Dec '03

17 Dec '03

Enclosed is my public key. I am new to the list and have a lot of catching up to do. Please excuse my ignorance. Sgt Darren Harlow - Computer Security MCTSSA, Camp Pendleton, USMC Internet: harlow%isb%mctssa(a)nwsfallbrook3.nwac.sea06.navy.mil Voice: Comm: (619) 725-2970 DSN (Autovon): 365-2970 Fax: Comm: (619) 725-9512 DSN (Autovon): 365-9512 "The views expressed are my own, and always will be..." -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAi2pYOoAAAEEAJ0Fdc1HDwlww3Wz8JPeQDZT2Gk/q1gh0J+4njtUC66HXngN DNyxzoGnZVcA0bbkirsCdjvvZlsP84QVgxdijzgW4pNOJKowJgrQWFftGEqJKH5b I2NxJrk0kmKt/jli5kV/wDs9Rr4PxXQjGN4B+uJOCSlyWX+fnWNyHMOkIY2tAAUR tENEYXJyZW4gSGFybG93IDxoYXJsb3claXNiJW1jdHNzYUBud3NmYWxsYnJvb2sz Lm53YWMuc2VhMDYubmF2eS5taWw+ =v34V -----END PGP PUBLIC KEY BLOCK-----

1 0

PGP encryption
by marssaxman＠aol.com 17 Dec '03

17 Dec '03

Are there any shareware/freeware/PD PGP-like encryption systems for the Macintosh? Or is there a Mac version of PGP and I just haven't heard about it? -Mars

1 0

Re: Remailer reply addresses
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

Ah! I'm glad conversation on this thread has picked up - I was afraid no-one was interested. :Graham's suggestion about automatic remailer reply chains reminded me of :a simpler system which I would like to see. :Suppose one site, somewhere, would create new mail addresses upon request, :and map them to encrypted remailer chain blocks. (These are nested remailer :requests, where the outer layer is encrypted for the first remailer and tells :it where to send the message, the next layer is encrypted for the 2nd remailer :and tells it where to send, and so on. No remailer sees anything more than :where it is sending the message and where it received it from.) A new account :is created which maps, say, to a file which has one of these "anonymous return :addresses" in it. Any mail incoming for that address simply gets sent to the :remailer in the file, with the ARA stuck in front of it. That's pretty much what I was thinking of, except you don't need the pseudonym server. I find this stuff easier to talk about with examples than in general, so here's what I'm thinking about: I mail to first remailer (R1). The remailer inserts my reply address into the mail, encrypted, and either mails it to the recipient if I gave one, or to the next remailer if I specified a remailer chain - or to another remailer at random on it's own whim if it feels like doing so. Let's assume it's going to another remailer then. This next remailer (R2) takes the header block with my reply address in it, and prepends what *it* sees as the reply address, ie remailer R1. It then encodes this into an identically-structured reply block, and inserts *that* in the mail instead of the original reply block, before passing it on. This can be repeated as often as desired - the mail will always have only two parts where-ever it turns up - an encrypted reply-block and the text. Let's say it ends up on the n'th remailer, Rn. When the real recipient gets the mail and replies to it, the reply goes to remailer Rn, and Rn can decode the header block. The decoded header block contains an address, and extra text which happens to be a fully-formatted header block itself. This extracted, smaller, header block is put back into the mail instead of the one which was just decoded, and the mail is sent back to the address that was extracted. eventually it goes through umpteen remailers, and R2 passes it back to R1. R1 decodes the header block, finds *only* the address - no nested header block, and passes the mail back to the user at that address. So the whole thing is really a trivial protocol - just <start of header block marker, for remailer to locate it> email address djhfkjsdhfdshf (opaque text from previous encryptions) kjfhkdhfkdhfkd dfkdfkjdfkhdf (possibly on multiple lines) jhldkjodkfdjfljdlfkjldjdl <end of header block marker> Sure, this could be extended to put all sorts of neat features in the encrypted area, but I rather like the simplicity of just keeping it to a plain username@site on a single line. :With this software I could do something which cannot be done today. I could :send mail to which someone could hit "r" to reply, and receive that reply, :without any one person knowing my pseudonym. This is not that much to ask :for! I'd say it is the bare minimum for the use of pseudonyms on the net, :yet we don't have it, after all this time. And look how close we are to :being able to do it. Absolutely! That's what I want too. :With this basic system in place, some of Graham's ideas about time-limited :or use-limited pseudonyms could be applied as well. Other extensions people :have suggested would have the pseudonym server hold messages in inboxes until :people trigger a dump to a freshly created anonymous address. A lot of things :are possible. I agree entirely except I don't see the need for a pseudonym server - just the normal remailer reply address should be enough (so that people who can't create aliases can run this stuff on remailers out their personal accounts) which is why I think the blinded reply addresses should be in the *body* of the mails. (Smart mail software would scan the text for these and handle stuff like indentation etc. It doesn't seem too difficult - I already use procmail for something like this where I scan for PGP blocks in mail and decrypt them on receipt where possible) :But we should walk before we run. Right now I don't feel that we are even :crawling yet. hh@soda seems to have shown us how to walk :-) G

1 0

Rejected mail
by John C. Brice 17 Dec '03

17 Dec '03

ag588 is rejecting mail from you

1 0

Re(2): Cyber PsyOps & Media
by Harry Shapiro Hawk 17 Dec '03

17 Dec '03

------ From: imsi.com!perry(a)panix.UUCP, Thu, Apr 14, 1994 ------ Jeff Davis says: > I just got off the phone with David Wilson with the Chronicle of Higher > Education. @ A really well known publication. Actually among staff and administration of colleges, schools, etc., this is a rather well know publication of much note... having the article appear there will certainly educate the the "campus" folks... but to agree with what I think was Perry's intent this not a mainstream publication. /hawk Harry Shapiro Hawk Manager of Computer Services Warwick Baker & Fiore habs(a)uucp.warwick.com

1 0

Re: New anon mailer idea?
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

: Graham Toal's suggestion for automatic insertion of an encrypted : return address block is interesting. We had some discussion here last : year of a similar approach, although Graham's twist of using a symmetric : rather than PK cypher for the return address is new. A few thoughts: I'm not sure it matters; it was just to focus the mind on the point that even if a PK cypher was being used in practice, it was *in effect* a private key cypher because its security depended in part on keeping the decoding key secret within the remailer. Primarily I suggested something like DES/IDEA because RSA keys are expensive to generate, and for this scheme you definitely need one new password for every incoming mail. : - You'd want this feature to be optional. Some people might not want : their anonymity limited by having their return address recorded, even : in encrypted form. Yes, I agree. I think Eric von Hollander is doing this for *every* posting in the soda implementation he hacked up impressively quickly, and I'm not sure that's wise. (Eric will correct me if I read his docs wrongly) I've a feeling some of his customers might complain when they realise! (*I*'m not complaining - I think it's great that he added this feature so quickly) : - Graham is right about the advantages of use-once (or use-only-a-few-times) : return addresses. Chaum discusses how multiple use of return addresses : allows these systems to be broken, similar to the way Graham describes. I also hope Eric is using individually-created DES keys for every incoming post and not a single shared key. That would be a serious risk. I get the impression he's not, from his comment about the system being vulnerable to known-plaintext attacks. (Eric, if I'm right, could you change your hack to use disposable DES keys asap please?) : - The use of a symmetric cypher is a very nice way of getting the use-once : capability, along with the "burn after reading" effect of a remailer : chain which destroys itself as it goes. But it could be a considerable : burden on the remailer operator to maintain the database. One possibility : would be to fix a maximum time limit on how long the return addresses are : kept "alive" and require some real money to keep them longer. I'm not sure I agree with that. Actually I think the database management might be trivial - here's one suggestion. Let's say the invented random key is a hex string - well, we need 64 bits for a DES key, that's 16 hex digits, so lets be generous and make our random hex string 24 digits instead. We just take the first six digits as an identifying tag and use that tag as a filename to store the rest of the key. The tag is output in front of the encrypted block too, so when you come to decrypting the data, it's a straight file-open call to find the correct key. We don't have the problem here that we do with the pgp key-id's clashing, because if the key generator returns a clash, it can easily generate a second key. (If you're saying that deleting time-expired keys is onerous, well, it's just a case of mastering the unix 'find' command ;-) ) So if you're saying that finding a key will be expensive, I disagree; if you're saying that the database might get rather large, I do agree. Since these reply tokens aren't the same as well-known anonymous addresses, maybe it's sensible to insist from the start that they have a lifetime of no more than (say) a year; which can be shortened by user request on creation, but not extended. This is a plus feature in my opinion, because it avoids the problems Julf has had with lots of stale ID's needing to be purged. : - What we would really like is for the recipient to hit the "reply" button : and be able to send his mail back. It sounds like this system would still : require some cut-and-paste. We already have programs to create encrypted : remailer chain addresses fairly automatically. It would be nice to automate : this last little bit. Unfortunately, there seems to be no easy way to : make this work under Graham's scheme. No, I don't think that any cut and paste is required *at all* over the normal inclusion of the sender's mail in your reply. The remailer could grep the body of the mail for the magic tokens that delimit such a header block, and find it that way. (Allowing for indentation markers etc - not hard - the current usenet voting software does something similar) eg if you had: > : *** Remailer reply block *** > : jdhfkhdfkshfkhgkhfgkhf > : *** End remailer reply block*** in your mail, you can see it's still pretty easy for a program to extract the encoded bit... - just find the magic start token, note the stuff on the line before it, and strip similar stuff out until it finds the end token. : - It doesn't look like this would be an easy drop-in to the current remailers, : unfortunately. The syntax for how the address would be built up as it : passes through a chain of remailers is a little unclear as well. I've discussed this in a previous post. I think it's actually easy. The very first message goes out from the first remailer looking like this: (original text is the single line: username(a)real_site.com ) which encodes to: *** Remailer reply block *** jdhfkhdfkshfkhgkhfgkhf *** End remailer reply block*** which is inserted at the top of the mail. The next remailer extracts the encoded data, and prepares this text: last_remailer(a)wherever.edu jdhfkhdfkshfkhgkhfgkhf and encodes it, and sends it out in the mail in place of the original block, looking like this: *** Remailer reply block *** dfkjgahfskghfghfskhgkfhgfs kjfdskjsfdhgkjfhsgkjhf *** End remailer reply block*** (OK, slight poetic licence here - I'm using 1 1:1 cypher; in fact you'd expect the text to get bigger each time to cover the binary encoding method used) So the net effect is that the encoded text gets larger, but the mail is otherwise identical as it passes from site to site. : The idea does have a lot of promise, though, and I think it is definately : worth keeping in mind for the next generation of remailers. I might even start using them myself :-) One more point... I've been saying that the encrypted reply block is most easily thought about if *all* it contains is an email address. I think in practice you'd probably want to be able to store arbitrary remailer flags in here, like the command 'delete this DES key as soon as you've handled this reply' - this would in fact be more robust than keeping the same information in the DES key file itself, which was my original suggestion. And it would allow fairly arbitrary extension of the whole scheme. One way of implementing it that I can see is if the encrypted part of a block was a series of mail-header-like lines, eg: The cleartext would be: Reply-To: gtoal(a)an-teallach.com Initial-Usage-Limit: 5 Expire-Completely-After: 12/25/94 Decrement-Use-Count-By: 1 Random-Remailer-Hops-Left-In-M&M-Machine: 3 Previous-encrypted-Block: jhufdkjlwhfsjhgflkjfshkjfdhkjffsvjlfsjvkl lkjdhfkldshfksahfkshdgkhfgvkhdfkvbghfdkvhfdkj jhflkdsajhfkljshdfkjhsdkfljhdskhfksdhfkjdshf ljdsfhdkghlksfhglkfdjhglkjfhglkjhfgkjfh which would be wrapped and inserted in the usual way. G

1 0

Re: New anon mailer idea?
by Anonymous 17 Dec '03

17 Dec '03

> Graham Toal's suggestion for automatic insertion of an encrypted > return address block is interesting. We had some discussion here > last year of a similar approach, although Graham's twist of using > a symmetric rather than PK cypher for the return address is new. [...] This is new? I thought Matt Ghio's remailer at andrew.cmu.edu did this already!?!?

1 0