- cypherpunks-legacy@lists.ogf.org

generic source for mail available
by an23135＠anon.penet.fi 06 Sep '93

06 Sep '93

sorry about this, it's a bit off the subject, but it will be very much on the subject if I ever find what I am looking for and do what I plan to do to it. Wanted: generic source code for mail. I just want to find some source that is not dependant on bsd or on SVR4 UNIX. It's for a "patch" I am planning for mail and sendmail. thanks in advance, ------------------------------------------------------------------------- To find out more about the anon service, send mail to help(a)anon.penet.fi. Due to the double-blind, any mail replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin(a)anon.penet.fi.

1 0

Key signing, authentication
by Christian D. Odhner 06 Sep '93

06 Sep '93

Recently there was some discussion about when to sign somebody's public key and when not to. Does anybody have a short, to the point set of guidelines on when it is ok to sign? I think minimum requirements to sign would most likely be receiveing that key from the owner both on and off the net. That way somebody on the net who is doing man-in-the-middle type attacks is thwarted, as is somebody who gives you the key off the net with a false net-id. Anyway, I'm sure there's more to it than that, like are phone calls ok? I mean, how did you get the # anyway? And what about meeting the person in the flesh? How do you know they are the same person you talk to on the net? Thinking too much about this could make a person .realy. paranoid! ______________________________________________________________________________ Christian Douglas Odhner | "The NSA can have my secret key when they pry cdodhner(a)indirect.com | it from my cold, dead, hands... But they shall pgp 2.3 public key by finger | NEVER have the password it's encrypted with!" My opinions are shareware. To register your copy, send me 15$ in DigiCash. Key fingerprint = 58 62 A2 84 FD 4F 56 38 82 69 6F 08 E4 F1 79 11 ------------------------------------------------------------------------------

2 1

Re: Law Review Articles
by doug＠netcom.com 06 Sep '93

06 Sep '93

Here's some more: authenticated signatures in regard to digital banking, direct democracy (both net and actual government), contract law, protection of sources in reporting, power of attorney, treaty signatures, anonymity of crime tips to police international bill of rights (some of these mechanisms potentially confer rights that certain governments do not) international law enforcement enforceability of information import/export restrictions evolution of international cooperative inter-government institutions (UN, world courts, world banks, interpol, etc) to match evolution of international net activities jurisdictional issues of international net activities (what does location mean in the net? Can I send an information agent to do things that are legal in the target country but not locally? What if the target country is indeterminate?) future changes in interpretation of sovereignty impact of a hypothetical declaration of a new nation in cyberspace (considering technical ability to vote, trade, "print" currency, tax, implement and enforce contracts, negotiate treaties, etc) U.S. bill of rights and its transferability to net activities U.S. federal versus state jurisdiction over net activities ability of existing legal theory to adequately cover such topics, including strength of current theories of philosophy of law Conceivably it's too early in the state of things to address some of these topics, but they'll all arise at some point, will he nill he. Doug -- Doug Merritt doug(a)netcom.com Professional Wild-eyed Visionary Member, Crusaders for a Better Tomorrow Unicode Novis Cypherpunks Gutenberg Wavelets Conlang Logli Alife HC_III Computational linguistics Fundamental physics Cogsci SF GA VR CASE TLAs

1 0

Law Review Articles
by Matthew J Miszewski 06 Sep '93

06 Sep '93

To answer many of your questions, I am alive. Ive been doing considerable research and thus been unable to reply to much of my mail. I am preparing to write one or several articles for publication on the legal effects of the internet and of course more specifically cryptography. Unfortunately, in the midst of my research i have come along a great deal more i could write about then first thought. So, I come to the list asking for input. For those who do not know, Law Review articles help litigators to support arguments that they need to make. They are not primary authority but often times one article will feed on another and develop into a school of thought. It is important to break into this cycle in order to further legitimize our (several) causes. Among topics already considered: International Data Havens Digitial Cash Algorithmic Patents Electronic Signiture reliability Cryptographic Export Laws First Amendment and the Net Computers, Freedom and Privacy (I wonder if thats a copyright infraction) Fair Use Laws and general Copyright Telecommunication Laws Effects on Competitiveness And a General Overview of the Cryptography Controversy I appeal to the list for further suggestions for topics as well as votes on which topic is most important to establish now. I am not locked in to any particular topic right now but will need to get going soon. Please forward any sources (good technical papers and legal sources), and any ideas or thoughts you may have. To those who care, Im back. To those who dont know me, Im back. To those who have offered help, I have not forgotten or abondoned ship, I will contact you. BTW, glad to see so much activity on the list. Keep up the good work. Matthew J. Miszewski mjmiski(a)macc.wisc.edu

1 0

please send me info on the Randy Weaver case..
by nate＠VIS.ColoState.EDU 06 Sep '93

06 Sep '93

A while back there was a bit about a guy named Randy Weaver, I think in the mountains of California. Please send me all the information you may have on that case... what transpired, what was done about it, anything. thanks, -nate nate(a)vis.colostate.edu

1 0

Anonymous Forwarding
by rjc＠gnu.ai.mit.edu 06 Sep '93

06 Sep '93

Do you have spare email accounts laying around? Would you like to have them forward mail to your main account anonymously? These are the questions which led me to hack up an anonymous .forward technique. I figured that I'd use a spare account to receive mail which I normally wouldn't want connected to my main address. Furthermore, mail forwarded to my main email address would be automatically encrypted to prevent the prying eyes of the sysadmin from snooping. Anonymous Forwarding -------------------- My software works like this. The destination address is prepared as a standard remailer header and pgp encrypted for one or more remailers, e.g. ==================================== :: Request-Remailing-To: my_real_address ==================================== becomes =================================== :: Encrypted: PGP -----BEGIN PGP MESSAGE----- Version: 2.3a hIwCPhjICRQCw4kBBACnRARz+qDK21BXcSUba3WjT4NEjoMtq+PZoJujGN2A/Ati O31UHYpULTP7j8OKBC+4Zuuan2e8CLTG9f3/XgYSuv8YRU5DtKr6bEuDDuojjgfr /ZudUWTej646ZJTqhrXRQldg/x/Wuu3kx8tby0zf+PcqqOssw7S2rgT6yrrdG6YA AABFct7lohDMViS01vOxzWr3RYernaqB9bkQmWlGd32TFrbe9bGf6BFBMvlDT8v+ C6xf1qI24mDslNiGoabjd/nCsE6d4EFT =7jt6 -----END PGP MESSAGE----- =================================== These "anonymous return addresses" are stored in the home directory (e.g. lib/shell.addr, lib/rosebud.addr, etc) on the spare account. When an incoming message is processed through .forward, the body of the message is stored and optionally encrypted with the public key of the main email account. The software then picks a remailer return address at random (e.g. lib/rosebud.addr), and appends it on the front of the encrypted body. This file is then re-encrypted with the public key of the destination anonymous remailer (optional). I did this so no one sees the obvious two-part message (pgp encrypted return address and pgp encrypted body). It probably doesn't add security, but it's optional. There is a configuration variable called "chain". If it is higher than 1, then up to "chain" number of remailers are chosen at random and chained together. Optionally, each new envelope in the chain will use the public key of the next remailer for encryption. So what happens is an incoming message is encrypted, the forwarding address (which is already encrypted for specific remailers) is added to an encrypted body and bounced randomly off a certain number of remailers to the final destination which is the main email account. Now you're all set to subscribe to alt.bomb.building with your other email account without fear of it being connected to your "real" account. ;-) Anonymous Mailing Lists ----------------------- Using my anonymous-forwarding script I have thrown together a kludgy anonymous mailing list program. Not only are the users on this list totally anonymous but the list address itself is secret! (Don't ya just love double-blind mechanisms?) To subscribe, users simply pgp encrypt a "Request-Remailing-To:" block as I detailed above and send it to the list request address. The list software sends out messages using the exact same script as anonymous-forward. At no time does the mailing list software see the real e-mail address. Only by collaborating with the operators of anonymous remailers can the list operator find out the real address of a user. The list address itself is also secret. Ihe true address is embedded in an encrypted "Request-Remailing-To:" block and chained through several remailers. Users post to the mailing list by adding their response to the encrypted return block and sending it to the first anonymous remailer in the chain. (the list software automatically puts the list's return block at the start of every message for easy response. [no cut/pasting needed]) Hopes, Dreams, and Bugs ----------------------- Obviously, with the small number of remailers on the net, and most of them running from multiuser machines and student accounts, security is not high. As the number of remailers increase, the probability of a bunch of remailer operators all collaborating is small. If remailers ever reach the level of popularity of gopher/fsp sites, it would be near impossible to shut down an anonymous mailing list. (there's no postmaster to complain to because you don't know the true address!) Alas, there is currently no way of returning error messages so if something bad happens, you aren't notified. Shutting down a single remailer in the chain would be very harmful. A fault-tolerant mechanism is needed and a robust way of returning error messages. -rjc p.s. If I have reinvented the wheel, ignore this message. I didn't see any anonymous forward/list software on soda so I figured no one had written any.

1 0

Anonymous Forwarding
by remail＠tamsun.tamu.edu 06 Sep '93

06 Sep '93

Do you have spare email accounts laying around? Would you like to have them forward mail to your main account anonymously? These are the questions which led me to hack up an anonymous .forward technique. I figured that I'd use a spare account to receive mail which I normally wouldn't want connected to my main address. Furthermore, mail forwarded to my main email address would be automatically encrypted to prevent the prying eyes of the sysadmin from snooping. Anonymous Forwarding -------------------- My software works like this. The destination address is prepared as a standard remailer header and pgp encrypted for one or more remailers, e.g. ==================================== :: Request-Remailing-To: my_real_address ==================================== becomes =================================== :: Encrypted: PGP -----BEGIN PGP MESSAGE----- Version: 2.3a hIwCPhjICRQCw4kBBACnRARz+qDK21BXcSUba3WjT4NEjoMtq+PZoJujGN2A/Ati O31UHYpULTP7j8OKBC+4Zuuan2e8CLTG9f3/XgYSuv8YRU5DtKr6bEuDDuojjgfr /ZudUWTej646ZJTqhrXRQldg/x/Wuu3kx8tby0zf+PcqqOssw7S2rgT6yrrdG6YA AABFct7lohDMViS01vOxzWr3RYernaqB9bkQmWlGd32TFrbe9bGf6BFBMvlDT8v+ C6xf1qI24mDslNiGoabjd/nCsE6d4EFT =7jt6 -----END PGP MESSAGE----- =================================== These "anonymous return addresses" are stored in the home directory (e.g. lib/shell.addr, lib/rosebud.addr, etc) on the spare account. When an incoming message is processed through .forward, the body of the message is stored and optionally encrypted with the public key of the main email account. The software then picks a remailer return address at random (e.g. lib/rosebud.addr), and appends it on the front of the encrypted body. This file is then re-encrypted with the public key of the destination anonymous remailer (optional). I did this so no one sees the obvious two-part message (pgp encrypted return address and pgp encrypted body). It probably doesn't add security, but it's optional. There is a configuration variable called "chain". If it is higher than 1, then up to "chain" number of remailers are chosen at random and chained together. Optionally, each new envelope in the chain will use the public key of the next remailer for encryption. So what happens is an incoming message is encrypted, the forwarding address (which is already encrypted for specific remailers) is added to an encrypted body and bounced randomly off a certain number of remailers to the final destination which is the main email account. Now you're all set to subscribe to alt.bomb.building with your other email account without fear of it being connected to your "real" account. ;-) Anonymous Mailing Lists ----------------------- Using my anonymous-forwarding script I have thrown together a kludgy anonymous mailing list program. Not only are the users on this list totally anonymous but the list address itself is secret! (Don't ya just love double-blind mechanisms?) To subscribe, users simply pgp encrypt a "Request-Remailing-To:" block as I detailed above and send it to the list request address. The list software sends out messages using the exact same script as anonymous-forward. At no time does the mailing list software see the real e-mail address. Only by collaborating with the operators of anonymous remailers can the list operator find out the real address of a user. The list address itself is also secret. Ihe true address is embedded in an encrypted "Request-Remailing-To:" block and chained through several remailers. Users post to the mailing list by adding their response to the encrypted return block and sending it to the first anonymous remailer in the chain. (the list software automatically puts the list's return block at the start of every message for easy response. [no cut/pasting needed]) Hopes, Dreams, and Bugs ----------------------- Obviously, with the small number of remailers on the net, and most of them running from multiuser machines and student accounts, security is not high. As the number of remailers increase, the probability of a bunch of remailer operators all collaborating is small. If remailers ever reach the level of popularity of gopher/fsp sites, it would be near impossible to shut down an anonymous mailing list. (there's no postmaster to complain to because you don't know the true address!) Alas, there is currently no way of returning error messages so if something bad happens, you aren't notified. Shutting down a single remailer in the chain would be very harmful. A fault-tolerant mechanism is needed and a robust way of returning error messages. -rjc p.s. If I have reinvented the wheel, ignore this message. I didn't see any anonymous forwarding/anonymous list software on soda so I figured no one had written any.

1 0

Trusted timestamps
by Mike Ingle 06 Sep '93

06 Sep '93

There are a lot of additions being talked about for the remailers, and timestamping is another which could be put in. With commercial PGP coming out, people may soon be doing "real business" using PGP. In this case, timestamps can be a problem. A simple example: you sign an electronic contract with someone. Before signing, you set your date a month ahead. The other person doesn't stop to notice it - many people have trouble translating numeric dates to month names anyway - and accepts the contract. Two weeks later, you revoke your key. He can't enforce the contract because it was made two weeks after your key was revoked. There are plenty of problems which can be caused by modified timestamps. One means of protection would be to have future PGP's detect and warn of postdated timestamps when a signed message is checked. Another would be to use remailers to create trusted timestamps. The remailer would have a key labeled < Remailer xx timestamp >. Timestamped messages would not necessarily be anonymized. There are several ways this could work. You could send a message to a remailer and get back a detached signature certificate. Or the remailer could sign the message and send it on its way. Ideally the remailer would detect a PGP message, de-armor it, sign the .PGP file, re-armor it, and pass it on. This way, PGP would automatically check all the signatures on the received message. You could bounce a message through several remailers and onto its destination, acquiring several timestamps along the way. Or bounce it back to yourself to create a poor-man's copyright. -- MikeIngle(a)delphi.com

2 1

anonymous routing
by bill＠twwells.com 05 Sep '93

05 Sep '93

I've been thinking about the problem of sending anonymous e-mail without using explicit routing. Here's one solution. Each message is comprised of two parts, an encrypted address and the data to be transmitted. The encrypted address has N parts, each encrypted so that it can be decrypted by one remailer. These N parts each contain information such that M of them can be used to reconstitute the destination address. Note that no indication is given of which remailer decrypts which; a remailer is expected to attempt decryption of all of them and to check for success. When a remailer is able to decrypt a piece, it replaces it with its decrypted value. It then remails the results, either to a randomly chosen remailer or to the destination, if it has the M parts. Sounds like the mail will never get delivered? Possibly. N pieces in the message M pieces needed to recover the addresses R remailers If I haven't screwed the math, H = R * (1/N + 1/(N-1) + 1/(N-2)....1/(N-M+1)) That is, the average number of hops to deliver a message will be the product of the size of the remailer pool and a factor that is purely a function of the address information. This number amounts to an appreciable fraction of the remailer pool unless the number of pieces is very large. For example, with just two pieces needed and 20 pieces provided, you'll hit about 10% of the remailers. Combine this with two things: make all messages the same size and create a "background" set of noise messages and I think that just about covers connecting sender to receiver. The only exception I can think of is that, since a message going into the system has the same data going out, if the bad guys see it in both places you're screwed. There's an obvious solution to that that I've overlooked, right?

1 0

REMAIL: 9/6/93
by Karl Lui Barrus 05 Sep '93

05 Sep '93

With all the new remailers, and more to come soon, I thought I'd post an updated list. Updated public keys and unix scripts should be available soon; hopefully I'll update the dos batch files this weekend as well. NOTE: my new remailer (elee9sf(a)menudo.uh.edu) is not on this list, partly because I don't expect it to run for any great length of time. It is more of an experiment to support PGP and RIPEM at the same remailer. If you missed the public keys, mail to me and I'll send them. -----BEGIN PGP SIGNED MESSAGE----- Cypherpunk anonymous remailers, 9/6/93 Q1: What are the anonymous remailers? A1: 1: nowhere(a)bsu-cs.bsu.edu 2: hh(a)cicada.berkeley.edu 3: hh(a)pmantis.berkeley.edu 4: hh(a)soda.berkeley.edu 5: 00x(a)uclink.berkeley.edu 6: cdodhner(a)indirect.com 7: hal(a)alumni.caltech.edu 8: cs60a-qu(a)cory.eecs.berkeley.edu 9: ebrandt(a)jarthur.claremont.edu 10: catalyst(a)netcom.com 11: sameer(a)netcom.com 12: remailer(a)rebma.mn.org 13: elee7h5(a)rosebud.ee.uh.edu 14: hfinney(a)shell.portal.com 15: remail(a)tamsun.tamu.edu 16: remail(a)tamaix.tamu.edu 17: remailer(a)utter.dis.org 18: remailer(a)entropy.linet.org 19: remail(a)extropia.wimsey.com NOTES: 1-6 no encryption of remailing requests 7-19 support encrypted remailing requests 19 special - header and message must be encrypted together 12,17,18,19 introduce larger than average delay (not direct connect) 12,17,19 running on privately owned machines ====================================================================== Q2: What help is available? A2: Check out the pub/cypherpunks/remailer directory at soda.berkeley.edu (128.32.149.19). chain.zip - program that helps with using remailers dosbat.zip - MSDOS batch files that help with using remailers hal's.instructions.gz - in depth instruction on how to use hal's.remailer.gz - remailer code pubkeys.tar.gz - public keys of remailers which support encryption pubkeys.zip - MSDOS zip file of public keys scripts.tar.gz - scripts that help with using remailers Mail to me (klbarrus(a)owlnet.rice.edu) for further help and/or questions. ====================================================================== Q3. Email-to-Usenet gateways? A3. 1: group-name(a)cs.utexas.edu 2: group.name.usenet(a)decwrl.dec.com 3: group.name(a)news.demon.co.uk 4: group.name(a)news.cs.indiana.edu 5: group-name(a)pws.bull.com 6: group-name(a)ucbvax.berkeley.edu NOTES: * This does not include ones that work for single groups, like twwells.com. #1 apparently blocks anonymous remailer posts #6 blocks from non-berkeley sites (so use the berkeley remailers :-) -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLIoT9IOA7OpLWtYzAQEyNQP/YeinL8uNCiOLDLVr0U+keX2LOkdyftHb FYOc56yGa+GcvqZ0KwqQk3cIAhZjdpNoRv6HcFHUcbD25lh77vyP/F/8OCXtRrG1 6708o0gGPcj2CSuzYygSFlfey4bv9FAsIgwe71oHpe5W0u/XxHUlaBFebi+u0310 lRTAiuBNRhI= =CcA+ -----END PGP SIGNATURE-----

1 0