November 1992 - cypherpunks-legacy

Re: How far is to far?
by George A. Gleason 20 Nov '92

20 Nov '92

Re. Fen's proposal to utilise "broadcatch." We still have the problems of slander/libel and breaches of legitimate secrecy. At risk of sounding naive/idealistic, it would seem that since there is no way to block information passing through the net (aside from screening at source, impractical at least!), the solution rests with education of the net-using population. Power carries responsibility in equal measure. We are giving ourselves the power which comes with privacy; we can begin to take responsibility for promoting a sense of ethics in the use of the net. One possible place to start would be at highschool-level computer courses; perhaps with accomplished hackers coming in and giving guest lectures or something... the culture of computer-literate youth can begin to include strong ethical positions regarding respect for the privacy of others, respect for truthfulness, and a position of personal conscience regarding law and authority. Re the latter, this isn't the same thing as blind obedience, but rather the idea that if there is to be disobedience it needs to be grounded in deeply held personal ethics, as for example in the case of civil disobedience. A strong set of cultural values in these areas might set a tone which discourages mindless negativity and wrecking. Now there will always be those who wreck for thrills.... I don't know how to address that problem except to note that such individuals are hardly stopped today by the threat of prosecution. -gg(a)well.sf.ca.us

3 2

The Cypherpunks Mail Project
by Eric Hughes 20 Nov '92

20 Nov '92

The time is now arrived for a more concerted effort to deploy encryption. It has become clear from the discussions on the list here that the first step should be encrypted e-mail. Unfortunately, mail is not homogeneous; there is no one place to push on the mail system to add encryption. Thus, regardless of the method used for encryption, we will need to add support to every single mail user agent. I now call for this work to begin. We will begin with the first step: a survey of existing mail agents. I volunteer to conduct the survey. I want to collect the following information from _everybody_ on the list: 1. What mail agent(s) do you use to read your everyday mail? 2. What platforms, hardware and software, do you use it on? Reply to hughes(a)soda.berkeley.edu as soon as you read this message. It only takes a minute to tell me how you read mail. Eric

1 0

The Cypherpunks Mail Project
by Eric Hughes 20 Nov '92

20 Nov '92

Step Two in the Mail Project is to gather together the social facts of mail software development: where the source code is and who maintains it. Participation in this step is not required, but a distributed effort to find this information would be greatly appreciated. Therefore, if you know where to find source code for your own (or any other) mail reader, please send it along. Be complete. Include at least the following information: 1. The name of the mail agent. 2. The current version number. 3. A machine name where the code is located, presumably via anonymous ftp. 4. The directory on the machine where it can be found. 5. The author(s) and maintainer(s) of the software. 6. The licensing status of the software: public domain, Gnuware, university property but publicly usable, etc. 7. Any useful political information about convincing whoever to support encryption. If your mail agent is commercial, then send the name of the manufacturer and any other information you can think of. Eric

1 0

Re: The Dining Cryptographers Protocol
by Marc.Ringuette＠GS80.SP.CS.CMU.EDU 20 Nov '92

20 Nov '92

Can DC-nets be used in a hierarchical or "backbone" framework to reduce communications overhead? Bill Stewart (in personal mail) suggested that such a scheme could satisfy my objections to DC-nets, namely that in order to get N-way anonymity, you must exchange N bits of traffic per bit of anonymous message transmitted. But when we tried to come up with such a scheme, it ended up being an unsatisfying hybrid of DC-nets and mixes. If you know of a backbone arrangement for DC-nets with a local net of size L<<N but an "anonymity parameter" of N, please tell us about it... -- Marc Ringuette (mnr(a)cs.cmu.edu)

1 0

Lots of work to do.
by crunch＠netcom.com 20 Nov '92

20 Nov '92

I said earlier: >> I've been getting good support for my ideas on implementing machine >>independent modules or "Libraries" of PGP routines that don't include >>I/O portions, but after looking at the code, I see this is going to >>take a lot of work, both in organizing the effort, and in implementing >>the code. Just how this is going to be done, I'm not sure, but this >>is what cypherpunks is all about. To hash these things over, flame on >>each other's ideas, etc. Miron says: >It would be very nice if PGP behaved better as a UNIX filter. For >example, I'd like it to return an exit code if it fails. I'd >also like it to have a flag that disables any access to the tty >for prompts. For example, if I have an automatic filter that >tries to decrypt all incoming messages, I don't want it to prompt >for a secret ring file when it can't decrypt something. I say the folliwing: The UNIX filter can certainly be written, but it should use the "services" of the PGP library code, which might have functions specifically for use with UNIX, But may not be called by Mac API's. It's important for me to point out that these PGP routines as C functions should be implemented as "Agents" or "Engines" and be totally self contained and not be depending on UNIX, MacOS or other facilities. It is fair for UNIX programs to CALL them, but the PGP should not depend on UNIX, or Machine dependent facilities other than File IO. Paul Rubin writes: >Those of us who support the freedom to use cryptography, run PGP, and >write whatever programs we wish (cryptographic and otherwise) should >be aware that the boycott against Lotus and Apple is still on. By >making PGP run on Macintoshes and with Lotus Notes, we improve the >usefulness of those systems and thereby help our enemies take away our >rights. I say --- Great!! but I have invested a lot of my own finances into purchasing my Mac II (Probably long before the boycott), and I certainly want to put it to good use. This includes my rights to privacy and to use PGP. I don't like Apple's policy, and think it sucks, especially if they dump hundreds of Mac programmers on the job marketplace, but sure don't want to ditch my Mac just because a few Apple FAT CATS made bad decisions. David Clunie writes: >2. A preliminary perusal of the code makes it obvious that extracting the > functionality from the interface is not an easy task. I agree, this isn't going to be easy, SW development is NEVER easy, so who is afraid of a little work? With all those unemployed programmers out there, we should be able to get PLENTY of help! JD

1 0

Re: PGP to SMTP mailer
by phr＠napa.Telebit.COM 20 Nov '92

20 Nov '92

Those of us who support the freedom to use cryptography, run PGP, and write whatever programs we wish (cryptographic and otherwise) should be aware that the boycott against Lotus and Apple is still on. By making PGP run on Macintoshes and with Lotus Notes, we improve the usefulness of those systems and thereby help our enemies take away our rights.

2 1

Re: Some proposals, Anonymous mailers
by dclunie＠pax.tpa.com.AU 20 Nov '92

20 Nov '92

> I've been getting good support for my ideas on implementing machine > independent modules or "Libraries" of PGP routines that don't include > I/O portions, but after looking at the code, I see this is going to > take a lot of work, both in organizing the effort, and in implementing > the code. Just how this is going to be done, I'm not sure, but this > is what cypherpunks is all about. To hash these things over, flame on > each other's ideas, etc. > > I have been studying the PGP code, and can see it's going to take a > lot of work to get it into a form where true machine portability can > be realized. As a Mac purist, a abhore the idea if translating Mac > GUI actions into ascii text and sending it to the current PGP "engine". > > Although it would take a lot of work, I propose that we develop PGP > to have the following form. > > a) Encryption engine library - Main set of routines currently in the > PGP program dealing with encryption of data. These would be I strongly support this concept. Having just implemented a new anonymous mail and posting system with privacy enhancement using PGP on a Unix machine, using the existing PGP code which is very keyboard oriented, proved to be a real headache, trying to second guess the responses that pgp expected. The whole deal would have been much easier calling library routines, or even more "Unix" like tool type interfaces. I am seriously considering rewriting some bits of PGP to do what I need but unfortunately: 1. I don't know anything about encryption, as Phil has made obvious in his responses to my ideas (quite rightly so). 2. A preliminary perusal of the code makes it obvious that extracting the functionality from the interface is not an easy task. However, I would be happy to volunteer my services should no one Unix based with more PGP or encryption experience is available. I also live outside the US at present which is a plus I guess as far as RSA is concerned. BTW. Re. my anonymous service - once I have Phil and Hal's suggestions implemented feel free to use it. Send mail to "anon.info(a)pax.tpa.com.au". The service is not yet really on-line, but if anyone wants to play with it feel free (given the proviso that I might change things and take it up and down periodically until I get it right; I will try to preserve alias #'s and stored public keys that have already been sent along). It is not based on the current perl scripts - I hacked it up in Bourne shell scripts before I heard about other peoples efforts, so all bugs are mine ! Note that it is basically a typical anonymous mailing system like that used in the various alt.personals and alt.sex groups, except that you can encrypt your messages to it, and it will encrypt responses back to you automatically, so dubious bounced mail and replies will not be readable by other's at your site or on the path. At present it is set up to allow posting to any group, but I am seriously considering blocking out the k12 groups after the recent godiva fiasco, quite against my philosophy, but my better judgement may yet prevail :( The same may go for file size and even rapidly repeated messages to the same addresses to prevent common patterns of "anonymous abuse". I hate to do this and may not, but I get the impression that I would be foolish not to. The immaturity of some people out there amazes me. BTW. I have also started a new mailing list for discussion of anonymous groups in general as well as my system. Send mail to "anon.subscribe@ pax.tpa.com.au" if you want to join. The list is strictly plaintext at the moment though unfortunately ! david

1 0

Some proposals to consider
by crunch＠netcom.com 20 Nov '92

20 Nov '92

Greetings fellow cypherpunks: A lot has happened since I got on here last Friday. My previous message contains my public key, Pse use it if you want to send me private mail. I bet the NSA boys are tearing the hair out of their heads by now, but it's about time we do something to preserve our privacy. It is my plan to help "organize" the Mac implementation of PGP, by putting together a Mac Implementation team of programmers to beef up MacPGP, by added better GUI, such as cutting and pasting of keys DIRECTLY into key rings without having to go through a file (makes for added security). My plans also call for tight coordination with the other platform development teams. I've been getting good support for my ideas on implementing machine independent modules or "Libraries" of PGP routines that don't include I/O portions, but after looking at the code, I see this is going to take a lot of work, both in organizing the effort, and in implementing the code. Just how this is going to be done, I'm not sure, but this is what cypherpunks is all about. To hash these things over, flame on each other's ideas, etc. So far, the Mac inplementaion team consists of the following individuals, and are (or soon will be) working closly with Eric Hughs, Phil Zimmerman, and the other PGP folks Mac PGP team: Richard Outerbridge [71755.204] Jim Clausing internet: jac(a)cis.ohio-state.edu Zbigniew Fiedorowicz internet: fiedorow(a)function.mps.ohio-state.edu INTERNET:crunch@netcom.com INTERNET:crunch@netcom.com Doug McNaught internet: doug(a)midget.towson.edu Philip Zimmermann internet: prz(a)sage.cgd.ucar.edu I talked with another individual last evening who also wants to be added to the team, but the others haven't yet been introduced to him yet. It is my plan to propose this idea to the PGP meeting at Sygnus this upcoming Saturday at noon. Then, I'll report to those that couldn't make it, due to their location. The progress on the Rander box is as follows: I am currently evaluating several proposed designs, and have sent out queries for data sheets on devices I plan on checking out for use, prices, etc. I have been studying the PGP code, and can see it's going to take a lot of work to get it into a form where true machine portability can be realized. As a Mac purist, a abhore the idea if translating Mac GUI actions into ascii text and sending it to the current PGP "engine". Although it would take a lot of work, I propose that we develop PGP to have the following form. a) Encryption engine library - Main set of routines currently in the PGP program dealing with encryption of data. These would be a set of "support" routines that would permit encryption of data in files, as well as data in memory. These would be totally machine independent, and only ONE set of sources should exist and contain compiler options for platform specific code. These functions would then return error codes instead of console output. Needed "key phrases" can be passed in as "char *", and sucessful operations would return NULL or if error, an appropriate code be returned. Other routines would be necessary, such as telling it where the random ring buffer is located, and how long it is. These routines would maintain their own pointers into this buffer. This library would call routines in the Random number manager and pass information such as where the buffer is located. See below: b) Key management library - Main set of routines that know how to manage the keyring files, it would have functions designed to extract keys, add and remove them, and work on the keyring files directly. Again, these would be machine independent routines. This would also call routines in the Random number manager below. c) Random number management - Main set of routines to manage a "circular buffer" of random numbers used to generate keys. This would work with both software and hardware random number generators, and would provide externally machine independent functions, but internally they would be machine specific. d) GUI's for the various PGP application programs. Mail management, file management, network applications, etc, all calling the routines in a,b, and c. Also includes Hypercard Xcmds, etc. Items a and b should have only ONE set of source code, and be maintained and managed by existing people. Items c would also be same source code, but have conditional compiler statements to "switch in" the machine dependent portions as apppropriate. I think it's possible to design the code in a and b to have very few machine dependent conditional compiler #ifdef statements, by forming the main PGP guts portion to operate on textual input in the form of "char *" instead of console input, and let the calling code pass "char *" to PGP library routines. Machine dependent stuff is in (d) and might include existing UNIX PGP "main()", Mac PGP main application, and lower level "utilities" such as Hypercar XCMD's etc. In fact, it is even possible to build these libraries to use NO global variables, and use structures instead. But me, being Mac biased, will probably get a lot of resistance to this proposal, but it is just that, a PROPOSAL. At any rate, I think that portability issues would be better solved if we were to adopt C code portability and to assume that not ALL platforms work well with console type input, and that Console I/O should be "factored out" of the machine independent portions of the existing PGP code. So, what way folks, has anyone got a better idea or proposal? Cheers JD

2 1

Another remailer
by wmo＠rebma.rebma.mn.org 20 Nov '92

20 Nov '92

I've installed Eric's anonymous remailer scripts at remailer(a)rebma.mn.org. Rebma is my home machine... It's not right on the Internet, but it is a Telebit connection away. Feel free to use it as you see fit. I don't have Hal's PGP additions, but I am interested in running them. Hal's messages said he hoped more people put up remailers so that they could be chained together. Sounded good to me. -Bill -- Bill O'Hanlon wmo(a)rebma.mn.org

1 0

Re: How far is to far?
by tcmay＠netcom.com 20 Nov '92

20 Nov '92

Mark (mark(a)coombs.anu.edu.au) writes: > Maybe it's not in the spirit of this mailing group but what of the question > of purposeful abuse of the anon mailers/newsposters? Say for instance some > person posts either a sh*tload of garbage to every known group, flooding > the USENET or a more personal attack whereby they send out anonymously > information that was so fundamentally personal to someone they could > possibly react very badly.... > > What if someone posted some top secret information and the various three > letter acronyms all went out for someone's blood. Abuses of various sorts will surely occur. The same thing happens with the postal systems of the world ("blackmail," poison pen letters, ransom demands, extortion threats, child pornography, sedition, etc.), with the phone systems (ditto above), freely available Xerox machines, and so on. Computers and computers nets will be no different. A difference is that the authorities are trying to stop all such abuses on computer nets and all such things they dislike by banning privacy and by restricting use. This is a doomed effort. > As a few people have mentioned they would *like* the opportunity to use > an anon system but the initial step of creating and running it isnt so > appealing due to the fundamental dangers of it. > > Most people would respect such systems but you find one really rotten or > immature loser that will use it for there own anti-social ends. This is where "reputations" and "kill" files come to the fore. Immature flames and other minor crimes are best dealt with by "down-checking" the reputation of the digital pseudonym of the offender. (Completely anonymous postings, where no "handle" or digital pseudonym is provided are likely to be "killed" by most readers.) For more serious "crimes" perpetrated by crypto users, well, nothing's perfect. As I said above, they have other channels to use as well. An advantage of the digital pseudonym nets is that these criminals don't know who you are or where you live (a la "True Names") and hence can't perpetrate certain crimes. When in cypherspace, be careful! --Tim -- .......................................................................... 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^756839 | PGP Public Key: awaiting Macintosh version. -- .......................................................................... 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^756839 | PGP Public Key: awaiting Macintosh version.

1 0