- cypherpunks-legacy - lists.cpunks.org

Remailers...
by csm2747＠NebrWesleyan.edu 17 Dec '03

17 Dec '03

Ok, Ok, I'll admit I'm a newbie to encryption and the like. This idea of remailers seems excellent. My only question how do I use them? Also where could I get more info about all this? The ftp at soda.berkeley looks like a good place to start...any suggestions on specific files or programs, beside PGP. Thanks. +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | Chad Mawson *-* Nebraska Weseleyan University <> Lincoln, Nebraska *-* | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ csm2747(a)hobbes.nebrwesleyan.edu

1 0

message depots
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

The mailing list has been pretty quite today. How about a new(?) idea to kick around... One of the main unsolved problems with anonymous remailer networks is that, somewhere, there has to be a remailer that knows the mapping from your anonymous identity to your real identity (or at least your real e-mail address). This means that you will have to trust the person running the remailer. It seems to me that as long as remailers use a message *delivery* paradigm, this problem is unsolvable. However, there is another paradigm that can be used which can solve this problem. I call it the "message depot" paradigm. It wastes a lot of bandwidth and cpu cycles. However, I believe that in the not too distant future we'll have more bandwidth than we know what to do with (Telecosm). Perhaps someday we'll also have more cpu cycles than we'll know what to do with (cray on a chip). When that day arrives, this idea will become practical. Until then, it will probably just be a toy. Still... Here how I see it working... Simplest case: One message depot Not too different from a message-only BBS where all messages are encrypted. If Bob wants to send a secure message to Alice and defeat traffic analysis, he will encrypt the message with Alice's public key and send it to the message depot. Alice (and everyone else) periodically grabs *all* new messages from the message depot and attempts to decrypt them. Alice finds that she can decrypt one of them; the one from Bob. If Bob signed the message before encrypting it, and Alice has Bob's public key, she can verify the signature. Of course, this doesn't means she knows who "Bob" is, just that "Bob" sent the message. Replace "Bob" with you favorite 'nym. Since everybody is periodically downloading all new messages, the message depot doesn't know which message goes to which person. Also, since the only clue to the sender's identity is the message signature, the message recipient may not know the identity of the sender. (It would depend on how the recipient got the sender's public key.) Scaling Up a Step: Multiple message depots Place a dozen message depots in the picture. They each publish a unique public key, which means that people can send encrypted messages to the depots as end points. The depots would poll each other for new messages to see if there is a message encrypted with their public keys. Example: Depot A polls depot B for new messages. Depot A attempts to decrypt the new messages. It finds one that it can decrypt. Upon decrypting the message, the depot sees a depot command and more message. The one and only depot command will be: "PUT THE REMAINDER OF THE MESSAGE IN YOUR MESSAGE POOL AS A NEW MESSAGE". Any message the depot cannot decrypt will be discarded. How is this useful? Well, by nesting a message in layers of digital envelopes, a sender can effectively move the message around the set of message depots until it reaches a depot that the final recipient polls. Lets say that Bob knows that Alice polls Depot E, yet, for some reason, Bob doesn't want to send the message directly to Depot E. What does he do? He first signs the message with his private key (if he wants to), then encrypts it with Alice's public key, appends the depot command and encrypts everything with Depot E's public key, appends another depot command and encrypts everything with Depot B's public key. He then sends the result to Depot B. Depot B decrypts the message, sees the depot command, strips it off and places the remainder in its message pool as a new message. Some time later, Depot E polls Depot B for new messages. Depot B obliges. Depot E attempts to decrypt the messages, finds that it can decrypt one of them. It sees the depot command, strips and posts the remainder of the message to its message pool. Eventually, Alice polls Depot E for new messages. And you can guess the rest. If Bob doesn't know which message depot Alice polls, he can send copies to a number of different depots and hope that Alice will find it. If he sent it to *all* depots, Alice will eventually get the message (unless she stops polling altogether). Messages depots will delete messages after a configurable amount of time. Also, the depots will not keep track of who has sucked down which set of "new" messages. This implies that the people polling the depots will have to tell the depot they want all messages since a given time. The client-side polling software can easily keep track of this for the user. Interfacing to the rest of the world: To support sending messages to specific e-mail addresses or news groups, somebody will have to run a remailer that polls the message depots. A sender will encrypt a remailer command and a message using the remailer's public key and direct it to the depot that the remailer polls. The remailer will find the message and interpret the remailer command. The command could be "SEND THIS TO <an Internet address>", or "POST THIS TO <a newsgroup>", or whatever. Replies would have to travel back through the depot net. The body of the message can indicate a message depot to "reply" to. I believe most of this message depot idea can be automated. As you can see, this mechanism consumes lots of bandwidth and lots of cpu. But it does not require that you trust any part of the system except the part that sits in front of you. I also believe that it successfully defeats traffic analysis. "All the smarts will be at the fringes of the network." - the guy who is writing Telecosm (and whose name escapes me). Jim_Miller(a)suite.com

3 2

pseudospoofing SF
by L. Detweiler 17 Dec '03

17 Dec '03

cypherpunks interested in identity mutations, perversions, and crimes like MPD, impersonation, pseudospoofing, etc., and developing a legendary anecdotes and a complex mythology regarding it all with e.g. compiled science fiction references, (who comprise the majority of the members, based on my mail and enemies) may be delighted by the masterpiece novella `Mefisto in Onyx' by Harlan Ellison in the Oct. 1993 Omni magazine.

1 0

ciphers and such
by Lloyd Cowling 17 Dec '03

17 Dec '03

Cipherpunks: I have a long running interest in ciphers. Could you put me on to your modis operundi and FAQ's, etc. Where I might find out more about you and what you do? Thx - Lloyd

1 0

Re: message depots
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

It seems the message depot idea is not terribly original. Oh well, I'm not too surprised. I suspected this and that's why I put "new(?) idea" in my post. I can at least pat my self on the back for reinventing it a few years late. :-) Jim_Miller(a)suite.com

1 0

Next Step show
by crunch＠netcom.com 17 Dec '03

17 Dec '03

Saw Eric Hughes on the Next Step science show on the Discovery Channel last Tuesday. Good job Eric...!! Wish they would have mentioned PGP and how easy it was to get it... Cheers CC

1 0

Re: UPDATE: direct-marketing email address list
by Stanton McCandlish 17 Dec '03

17 Dec '03

Here's what you get if you send mail to J.S. McBride's posted address to query about the direct-marketing email address list: ______ begin forward ______

1 0

Jim McBride
by Anonymous 17 Dec '03

17 Dec '03

Got this in the mail today: -- cut -- Date: Wed, 03 Nov 1993 22:11:07 From: jim_mcbr(a)netmail.com Subject: Auto Reply To: <me> Thank you for your mail to Jim McBride at JS McBride & Company. Due to the volume of mail be handled by this account, this is an automatic reply. PLEASE READ CAREFULLY!! 1. JS McBride is NOT collecting demographic information on email addresses. Due to the controversy surrounding this practice, we have discarded the product demographics we collected. We are however still collecting email addresses and user names. 2. The information collected (name and email address) will be offered in a printed white pages directory and in a white pages server on the net. 3. You DO NOT need to ask to have your name removed. BEFORE your name is used in the directory, you will receive mail asking for your permission. If you reply to the inquiry, your information will be used. If you do not reply, your name will NOT be used. 4. Comments regarding the white pages should be sent to Tom Manning at JS McBride & Company. <tmanning(a)netmail.com> 5. Mail to Jim McBride should be sent to <jimm(a)netmail.com> 6. Information regarding the purchase of the white pages directory should be sent to <listinfo(a)netmail.com> or telephone us at 415-949-4295 Thank you for your time, Jim McBride -- David Sward sward+(a)cmu.edu Finger or email for PGP public key 3D567F Encryption is an envelope for your email; read alt.security.pgp for details. GCS: -d+ -p+(---) c++(++++) l+ u+ e+ m+()@ s+/++ n+@ h+ f !g w+@ t+@ r+ y?

2 1

ViaCrypt PGP has arrived
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

My copy of ViaCrypt PGP arrived yesterday (Nov 3). Since I worked late, I haven't had a chance to play with it yet. I looked through the manual. The commands look similar (if not identical) to "classic" PGP's, as far as I could tell at a glance. The bulk of the text for the manual was taken from the documentation that comes with PGP, except all occurances of "PGP" where replaced with "ViaCrypt PGP". The box looks pretty good. :-) Looks like they hired a real graphics designer. I suppose some of you are wondering why I'd fork over 100 bucks for something I could get for free. First of all, I can afford it. Second of all, I simply feel more comfortable using a licensed shinkwrapped software product than a quasi-legal freeware one. Call me a coward. I realize that by not compiling the code myself on my own machine I basically have to trust the ViaCrypt PGP implementation. So be it. If there is something wrong with ViaCrypt PGP I believe it will eventually be discovered. Somebody will no doubt disassemble it and look for backdoors. If someone finds one, ViaCrypt's reputation will be worthless. It's in ViaCrypts best interest not to put in any backdoors. Jim_"Rebel without a spine"_Miller(a)suite.com

1 0

unsubscribe
by crypto＠fizbin.fredd.com 17 Dec '03

17 Dec '03

Please unsubscribe me. Thanks! -- Red Rover crypto(a)nowhere.com

1 0