December 2003 - cypherpunks-legacy

HTML/remailer testing
by nobody＠VIS.ColoState.EDU 17 Dec '03

17 Dec '03

This message is from an experimental anonymous remailer. For information, send mail to nate(a)vis.colostate.edu ----------------------------------------- Test Message for Nates Remailer Home Page -----------------------------------------

1 0

re: The Packwood Memorial Diary Server
by dave_taffs＠rainbow.mentorg.com 17 Dec '03

17 Dec '03

Jim Miller writes: >If true, I guess the next question becomes: How can you offer a service >to the Internet, but make it impossible for a Bad Guy to physically locate >you? >Perhaps the server shouldn't stay in any one location for very long. >Bring it up and post an Internet address. Operate for a few days, then >shut it down and move to some new location, with a new Internet address. You can use the Internet itself as a storage device. I've seen articles about how you can use the ether between here and the moon as a storage device, sending (e.g. optical or radio) information up to the moon, bouncing it off, receiving the echo, and then resending it. It takes a few seconds I think, which allows a fair amount of storage, depending on the bandwidth. So, for example, you have a bunch of net.sites that receive stuff and send it back. Of course, you have to wait for it to come around again to your neck of the Net-u-verse to read it again, but then you don't have to pay for as much disk storage, as all your friends on the 'net will let you use what they have in their store-and-forward mechanisms. The disadvantage is that it relies on a form of security by obscurity; once people figger out what you are doing, they may get pissed off. If you use it wisely however, and just gradually increase the bandwidth over time, eventually you may be able to get everybody else to pay for the disk space to keep _your_ data, without anybody being the wiser. The Internet as a (w)hole must have enormous capacity at this very minute. -- O_O 01234567 dave_taffs(a)mentorg.com | . . ^ "Kolmogorov-Chaitin measures of complexity are | (_:_) MGC != me very exciting." -- Tim May on 12/02/93 |

1 0

remailer?
by dwomack＠runner.utsa.edu 17 Dec '03

17 Dec '03

Nice as remailers are, I wonder if it might be better to simply create a "message drop". Various anon ID's would be created, with suitable passwords. If Sam wishes to mail to Joe, he sends to the account. It sits for up to a week before auto-deletion; prior to that time Joe can check his account for messages, retrieve as appropriate, leave other messages, and leave. The primary 'phone number would be in one location, with the remailer at a different physical location connected via non-toll call forwarding. Hence, no LD toll records of the calls to the device. Individuals would place calls, so their records might "give them away"; but there would be no return calls from the device. Finally, if someone wanted to use methods other than PGP this would seem to support such methods. Any thoughts, or am I hopelessly clueless? Regards, Dave

3 2

Re: clipper pin-compat - Not really
by freeman＠MasPar.COM 17 Dec '03

17 Dec '03

Also useful would be a Clipper in-circuit emulator -- a pin-compatible head connected by cable to the computer of your choice, where you could do whatever you wanted to the data, in software of your choice. I suspect that such a device is relatively easy to construct. It could even have a real Clipper inside it (possibly the one you took out of your 'phone), for use when you wanted to pretend to be doing what the powers that be wanted you to do. -- Jay Freeman

1 0

Remailer Noise Traffic
by W. Kinney 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Is there some reason why lots of 'punks _aren't_ running a simple script that will, say, fire a message to one's self through a chain of remailers every time you log on or at random intervals or something? This may be an imerfect solution to the problem of traffic analysis, but it's so uncomplicated that there seems no reason not to do it. And if there were fifty or a hundred people or so making a practice of this, it seems to be agreed that the remailers would be a great deal more secure than they are now. This is a nice little opportunity for everybody to help out the remailer operators. God knows, this list seems to be capable of generating sufficient noise -- all we have to do is harness it :-). The question is, how much traffic is _too_ much? Recommendations from remailer people? -- Will -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLUZCnffv4TpIg2PxAQFYLgP8DihQb+OXI8kqYcjmt/KI/1XZ39CzSa/r 8Af74o33GUPjGLjtayWTqWFRZbjHMMhr9xH6bgtjUz2AxhrANoeZRHm9J7pkJchN oKwDryooOexlyO88quriQsMv8trlh7UEtWf1Ig4shSgVpJUMPDkad6LHVYk3fnFn 7Un2p6cYUKU= =e6+8 -----END PGP SIGNATURE-----

4 3

digital cash, once again
by Matt Thomlinson 17 Dec '03

17 Dec '03

What P Nave just said about beginning to give cash credit to those who receive bogus messages as a dead-letter dropoff point makes sense. If I were a subscriber to the dead-letter club, I'd receive a stipend monthly by each remailer operator for use of my account as a dead letter office. In turn, we could begin using these credits to enact some pay-per-send remailers. The remailers with dead-letter club participants would enjoy a greater amount of business (perhaps) because of their greater amount of traffic -> security through volume. Matt Thomlinson Say no to the Wiretap Chip! University of Washington, Seattle, Washington. Internet: phantom(a)u.washington.edu phone: (206) 548-9804 PGP 2.2 key available via email or finger phantom(a)hardy.u.washington.edu

1 0

Info?
by Paul McKeever 17 Dec '03

17 Dec '03

Hello, Do you guys have any electronic brochures or how-to guides? Regards, Paul

1 0

NEEDED: Remailer list
by nobody＠eli-remailer 17 Dec '03

17 Dec '03

Does anyone keep a list of operational remailers and their PGP keys? I am new to using remailers, and I only know of a couple that I can use. I am enclosing both my PGP key and some response information that can be used to reply to this post. To make a reply to this post, you should: o Encrypt your reply with my public key o Make a text file by concatenating the response information with your encrypted reply (the response information should preceed the reply). o Mail the whole thing to the remailer at: ebrandt(a)jarthur.clarement.edu Here is my public key: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAi1IP1QAAAEEAL0TpnNwrh/YLWxgPip1InVclRgJ9yUy6QqC4c/vaBbCEhPa x1zeupCWpHanK4c7i0JiwntS4m5a0cXQ5qoX5am5+Hw+yJVSpdbuk0PCfQmNIH4q CQs7JXELqu2YwFRBx/Qr23oKstSxQnRl9g6mJCmleEcuA0cab9twNfqELCYpAAUR tBlibGFuayA8YmxhbmtAbm93aGVyZS5jb20+ =s4dh -----END PGP PUBLIC KEY BLOCK----- And here is the response information: ---(Begin response information)--- :: Encrypted: PGP -----BEGIN PGP MESSAGE----- Version: 2.3a hEwCpNUZLrF9FUsBAf9Dtq1jBDAT42Jj+XPVDwiDf88FG1hZBILWNtDQ4b13Qt7j 1Hd1FcXX8NiPFFKFgt6Y7bi+xGGg7yMowlNfMw1vpgAAAW13PygtTOl3VgX2442B hFyVNnzYpOBJ+E1z56RUsVujOIjyXIIZVWmfnrO5PaOIsSKWRSaHfWEIM9nVJaNm xgsahPw5PlJaV1+em7VEjLSeyb5NNUyOm6Rq4Fptye0o3kBVpsDRPX5LBkE4XJlU Q1fZZaGg+VLZ+e9jwiwu86j+S15imv8YHZeFxoMKD1pmfZAKqzUPdpiH4sq2UmAz OOAI4e+Vh41GmLV9qr5hdMk9A8vi6vrqOUr3ouDLdQ8+RQsvbUUHT2RtGrWyql6d mdR9QpuhgSdas3Hxre15RSVreCWozlh9Q1HGCAExu6H+DcVTLHfmNqyFZjkUmHIM /mpd1Sf331MytdIYjvIv8OaKrwiQaAKFpOyo8iigTpI1bIAUDaW+BC2JpXJv5vIq MaAPV8zsqNywNtexLGvg32v2JELGoHNegycUwDYnKCwmWEtr9acEJ3HOQ4OWnb2W dUr/Dd5akY6L+07AWFKa6w== =Geng -----END PGP MESSAGE----- ---(End response information)---

1 0

REMAIL: Cover traffic
by Hal 17 Dec '03

17 Dec '03

Several people have suggested that cover traffic is more valuable than I had suggested in helping prevent tracing of messages through remailers. I drew up some diagrams to show what I mean. Suppose we have remailers R1 through R6 exchanging dummy messages all the time that are introduced into the remailer network by cover traffic sources C1 through C3: C1 C2 C3 | | | | | | | | | | | | V V V R1<------->R2<------->R3<--------->R4<-------->R5<-------->R6 Now user U1 sends to user U2 through some remailers in this network: C1 C2 C3 U1 | | | | | | | | | | | | | | | | V V V V R1<------->R2<------->R3<--------->R4<-------->R5<-------->R6 | | | | V U2 As you can see, it doesn't exactly take Sherlock Holmes to figure out who is talking to whom. If the "true" traffic through the network is light and latencies low, someone monitoring the whole network can track messages in this way. Now, suppose we also had U3 send to U4. Then there is some benefit: C1 C2 C3 U1 U3 | | | | | | | | | | | | | | | | | | | | V V V V V R1<------->R2<------->R3<--------->R4<-------->R5<-------->R6 | | | | | | | | V V U2 U4 An observer may be able to deduce that U1 and U3 are sending to U2 and U4, but they can't tell which is sending to which. So the cover traffic had some effect. But consider: you can get the same result from a SINGLE batching remailer: U1 U3 \ / \ / \ / R1 / \ / \ / \ U2 U4 Here we also have U1 and U3 sending to U2 and U4, without being able to tell which is which. It has also been suggested that "bit-bucket" addresses, people who would receive messages from the network and discard them, would help. Here is how cover traffic might look with bit-bucket addresses B1 through B3: C1 C2 C3 | | | | | | | | | | | | V V V R1<------->R2<------->R3<--------->R4<-------->R5<-------->R6 | | | | | | | | | | | | V V V B1 B2 B3 Here again, though, if true message traffic is light, and U1 sends to U2, we will have: C1 C2 C3 U1 | | | | | | | | | | | | | | | | V V V V R1<------->R2<------->R3<--------->R4<-------->R5<-------->R6 | | | | | | | | | | | | | | | | V V V V B1 B2 U2 B3 Again, the changes in the background pattern of communication reveal the true messages. The only way this cover traffic will work is if there are a very large number of traffic generators, (C's) and a large number of bit-bucket addresses (B's). Even then it will mostly serve to cover messages which are from C's to B's. And you still have the problem that the B addresses may become well known (people have to find out about them somehow), making this analysis easier. It has also been suggested that in pointing out these difficulties I am overlooking the fact that at least the cover traffic makes the eavesdropper's task more difficult, as he now must monitor the whole network. But I think he has to monitor the whole network anyway. If I send a chain-encrypted remailed message through half a dozen remailers (even without cover traffic), the observer must watch that message going into and out of each of those remailers in order to see where it finally goes. Looking at only one remailer will not help. So, since the eavesdropper must monitor the whole network in order to follow messages even without cover traffic, I think it is fair to point out that adding cover traffic doesn't help much against an eavesdropper who can monitor the whole network. The real solution, as suggested by the diagrams, is to have a large volume of true remailed messages in the network - messages which go to a wide variety of people. Individual users can protect themselves to some extent by serving as cover-traffic generators and bit-bucket receivers; but this does not protect other users who are not able to perform these functions. Hal

1 0

Remailers needed NOW. Help.
by an48138＠anon.penet.fi 17 Dec '03

17 Dec '03

------------------------------------------------------------------------- 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