- cypherpunks-legacy - lists.cpunks.org

Re: Frothing remailers - an immodest proposal
by kevin＠elvis.wicat.com 17 Dec '03

17 Dec '03

>Without quoting the entire message, I think I better solution, in terms of >ease to implement as well as conserving bandwidth would be to have a >sophisticated remailer script-language. > >For instance, the script language could tell the remailer to check if a >site is on-line (perhaps within certain GMT hours or dates) and use the >next site if not available, or to randomly choose from a list of sites >the active ones, etc. Aye, there lies the rub. How exactly does one determine if a site is active or generate a current list of active sites? It is not enough to ping the site or even to successfulyl deliver mail to it: the fact that something is alive and running sendmail does not make it a remailer. Likewise, a remailer cannot select an alternate site on behalf of the user if the routing is chosen by the user, as each "envelope" is encrypted specifically for a given remailer. I suppose one could develop client software that built several redundant "envelopes" for alternate mailers, but that would get out of hand pretty quickly, both in terms of the effort of generating a secure message and in term of the size of a message. Scripting is useful (hell, the ::Request-Remailing lines are effectively a script) but not until there is data to operate on. >Maybe even have it work with a data haven? Mail the message to a data haven >and send another message to a remailer chain to pull the message from the >data haven and post the data (not flaws in this: don't want remailers getting >files from people's accounts and posting them to usenet etc.). Not a bad idea, actually. -- Kevin

1 0

Re: Frothing remailers - an immodest proposal
by kevin＠elvis.wicat.com 17 Dec '03

17 Dec '03

>1. Broadcasting every couple of minutes isn't necessary and is undesirable >due to the real limitations of the Internet. A remailer could broadcast >its location with a time-out on the location without a constant stream >of availability announcements. In your position for example, you'd >broadcast a message at 5 pm with a 16 hour valid time. True, but this has two basic assumptions that I disagree with: first, that we can guarantee delivery of a broadcast message to all interested sites; and second, that remailers never go down for unexpected reasons. When the day comes that both networks and software are perfect, this method will be reliable. Of course, you are also right that broadcasting is undesirable; that is why I am pondering a way to minimize the impact. >2. This is actually unnecessary for your situation: All you need to do is >advertise your location as a "real" remailer and then have a cron job that >kill sendmail at 5pm on your remailer machine (assuming you have a spare >machine that doesn't need to run sendmail). The mail network is flexible >enough that things will Just Work. Mail won't go through instantly during >the day, of course, but that just helps to muddy up the mix. But, if my understanding of remailer operation is correct, this has two potential problems: first, I will still receive mail during the day, causing a bandwidth concern (I know, it's probably not a problem right now, particularly since users will probably choose to avoid a remailer with a possible 16 hour delay); and second, the machine delivering mail to me simply has to trust that a remailer will in fact pop up on this machine to process the stored mail. There is no way of determining that mail is not simply going into a black hole. And even if I try to be nice when the mailer goes down permanently and tell everyone not to route mail through it any more, that news still has to travel via word of mouth to all users of the web. > >3. Broadcasting over live IP isn't all that great a model. Ideally, >you'll use a mechanism that doesn't require instant communication among >hosts. I favor USENET for this: messages have a naturally long life- >time and the network is self-adjusting. If a direct route is temporarily >unavailable, an indirect one will often manifest itself. I also favor >using USENET store-and-forward for the messages themselves for the same >reasons: traffic analysis is impossible inside the web and direct routes >are not necessary. I am not happy with my proposed advertising methods, and was quietly hoping for some guidance from internet gurus in this point (the irc suggestion in particular is a pretty shaky straw man). However, see my earlier message (on some other thread) about Usenet propagation times. Propagation times in days do not seem to be rare (post to misc.test and see when the last reply comes back). While this is better than word-of-mouth propagation, it does not offer the very low latency I was looking for. >4. Using a PGP-style web-of-trust is important. In the ideal situation, >one human in an extended web can certify individual remailers and all other >remailers close enough on the same web of trust would pick up the message >immediately. It strikes me as critical; right now, a user has to choose to trust a set of remailers, given no assistance other than a list of "reliable" ones. Given an extended web of trust between remailers, the user can choose to trust one remailer (I have no idea how to make this process more palatable) and immediately gain the security of a large web of remailers (maybe you are right about that instant gratification thing...) Kevin

1 0

Re: Fundamental Question?
by cactus＠seabsd.hks.net 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- In article <9502012323.AA00271(a)toad.com>, <kevin(a)elvis.wicat.com> wrote: >Consider the incoming directory on my local news host: ... Strictly speaking, you've really only demonstrated that there are a lot of poorly connected sites on the USENET. The primary characteristic that really needs to be considered is the time for news to reach one remailer site from another. My experience is that new propogation is fast enough that close to real-time conversations happen all the time. I take part in them on the newsgroups I still read and observe them all the time. I don't have a ready explanation for why my experience differs so much from yours. The worst-connected site I've ever read from was 9 mo.s ago with a batched feed from uunet. Even then the vast majority of posts I saw were from the day just ending. What are other people seeing as news delays? - -- Todd Masco | "life without caution/ the only worth living / love for a man/ cactus(a)hks.net | love for a woman/ love for the facts/ protectless" - A Rich Cactus' Homepage - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLzAmeSoZzwIn1bdtAQHHiwGAxL13i5YYjZxREU1XwnAp81+XWgir7H92 enbDeqFQwjddTeEgHX+fKZWoZJBe4wy6 =pmE5 -----END PGP SIGNATURE-----

1 0

Re: Frothing remailers - an immodest proposal
by kevin＠elvis.wicat.com 17 Dec '03

17 Dec '03

[deletia] >Now, dynamic rerouting is good for better delivery, but is bad for the >trust in silence. Trust in externally unverifiable properties is >_not_ transferrable. Just because I believe that my regular remailer >is OK does not mean you do. The creation of these links of trust is >not something that can be automated solely by the remailer operators. >The end users of the remailers are the endpoints of this trust >relationship. The end users must be involved, either directly or >through some (legal) agent, in the manipulation of these relationships. First, I must admit to being somewhat out of my depth here; this seems to be becoming a philosophical problem. With that shameful admission out of the way, let me bull ahead regardless. It seems to me that I can choose to trust in the fact that *your* trust in other remailers is well founded. This then becomes a third category of trust for a given remailer: trust that it will deliver (verifiable); trust that it will be silent (unverifiable); and trust that its operator has good judgement in choosing who to trust (unverifiable). These latter two are, and should be, the end users responsibility. Now, as I have mentioned in an earlier message (I'm being far too verbose today) I am proposing that dynamic routing be optional, though the default behavior, for reasons mentioned there. Thus, if I, as user, choose to allow dynamic routing (through omission - I must admit, I am becoming less fond of the notion of this as default behavior - it begins to smack of the heresy of "implied consent") I am expressing the third flavor of trust, just as by using the remailer at all, I am expressing the second variety. Of course, I still have to trust that a remailer will honor my routing requests. However, I believe this falls fair and square into the second category (trust in silence) >Any solution which tries to do this independent of the end user is >broken, by definition. -- Kevin ( I have no joke here, I just like saying "I trust a remailer if it is trusted by an entity I trust to trust remailers".)

1 0

NYC area C'Punks meet 2/11/95
by mjwohler＠netcom.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Attn.: New York City area Cypherpunks NYC C'punks meeting: Sat Feb 11, 3:00 P.M., at the home of Linn & Barbara Stanton 315 West 106 Street Apt 2A (Between West End Ave & Riverside Drive) 212-316-1958. Once again the gracious Stanton's invite local area Cpunks to their lovely home which is smoke free and feline friendly. The agenda is still open and suggestions can be made to mjwohler(a)netcom.com or phone Marc Wohler @ 212-362-0690. Let me know if you plan to attend. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLy+PL2eikzgqLB7pAQGHigP9HW1Py30O2fcZH/f1SAOToOBZYVZMiB9c buGQrujaicGVJlvGb1Le/OjJ872JB69BQD1MMsemABSYi4swL15w9qj1rhoTAHIg yTRDFJD16g1lqqLvEJZ0RijOh1dXLaUg8HNue0JoSAbARkQed8I3+mklP4C4saYn qW2Fa/kDuZY= =Rl9C -----END PGP SIGNATURE-----

1 0

Re: Adding padding to PGP files
by Hal 17 Dec '03

17 Dec '03

From: Nobody(a)eniac.ac.siue.edu (Anonymous) > > Date: Thu, 2 Feb 1995 08:48:49 -0800 > > From: Hal <hfinney(a)shell.portal.com> > > > > It only works on binary ".pgp" public-key encrypted files (not ascii armored > > files). So there would be some work needed to make it a really useful tool. > > > > Hal > > I just tried adding random characters at the end of a pgp ascii > armoured message. I had to cut out the checksum, but pgp was able to > decrypt the message just fine. So a very simple program (ideally with > a strong source of random numbers) should be able to pad ascii > armoured files. Unfortunately, this approach is easy but doesn't really succeed in adding undetectable padding. The PGP message, once the ascii armor is stripped away, has a byte count in it. Anyone can de-armor the message and see that this byte count does not match the size of the file. So you also need to bump this byte count to match the added bytes. That's all my perl script does that I posted. Hal

1 0

A simple idea
by Jon Lasser 17 Dec '03

17 Dec '03

Maybe this has been discussed before, but if so I wasn't around for it and would like to know: What if: (assuming trusted remailers, but still worried about traffic analysis of those remailers): One mailed a message to one remailer. This remailer held onto all messages until some predestined hour or kilobyte size or whatever, and then forwarded ALL its messages to this other remailer, in one packet (.TARred and PGPed separately, say), but NOT IN THE ORDER RECIEVED? While this wouldn't solve all the problems (to some extent, the sizes of files might be correlated, but this could probably be foiled by other means), wouldn't it at least foil the easy to/from traffic analysis that is (I believe) the greatest threat? Jon ============================================================================== Jon Lasser <jlasser(a)goucher.edu> This is an advanced .signature virus -- please attach to your .signature and add your last initial to the list: l ------------------------------------------------------------------------------

1 0

The FIREWALL CHIP. U're phone always offhook?
by Gary Jeffers 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- THE FIREWALL CHIP! U'RE PHONE ALWAYS OFFHOOK? We have potential bugging devices in all our houses - The telephone! Of course, when it is onhook, the microphone does not transmit... or does it? Would the phone have to be rewired to render it always "offhook" or would it be an operation at the central phone company? If the present models would have to be rewired, then how about future models? Much function is done thru chips & so could many of the models on the current market be remote programmable? See the latest issue of Mondo 2000. This problem demands a hardware solution. How about an adapter module between microphone & the rest of phone? THE FIREWALL CHIP The Clipper chip architecture was secret! Cypherpunks demand source code with their security software! How about a demand for the "visable" chip. That is - a chip with a known architecture - that can be tested for integrity & is a general computer chip for doing software operations & for doing i/o with electronic devices? With our property being loaded up with sophisticated "trust me" electronics, it may be necessary to have a general electronic "FIREWALL CHIP". The FIREWALL CHIP could have its applications software supplied by various companies which would specialize in fields for detecting electronic intrusion. Some specializing in phone audio, others in vision telephones, cell phone tracking, & many others to be considered. The FIREWALL CHIP will be a future necessity. It & its software suppliers will probably constitute an outlaw industry. PUSH EM BACK! PUSH EM BACK! WWWAAAYYY BBBAAACCCK! BBBEEEAAATTTT STATE! Gary Jeffers - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLzFxYCoZzwIn1bdtAQG0ewF/RUMJZU1qXc+31XVQLfetSZst4j+S55/i tq6j/JN5t3rjXa873mY5lT4cHCFBukfv =NSeZ -----END PGP SIGNATURE-----

3 2

Adding padding to PGP files
by Hal 17 Dec '03

17 Dec '03

Here are a couple of perl scripts I wrote last year to add padding to PGP encrypted files. The usage would be: perl pgppadt.pl filename bytestoadd The output file is filename.pad. It only works on binary ".pgp" public-key encrypted files (not ascii armored files). So there would be some work needed to make it a really useful tool. It would also be better to use a strong source of random numbers. I think Carl Ellison recently posted some tools that could help with this. The two files are pgppad.pl, which does the work, and pgppadt.pl, a very simple test driver to show how to use it. They are in a shar archive. Hal ---------------cut here---------------- #!/bin/sh # to extract, remove the header and type "sh filename" if `test ! -s ./pgppad.pl` then echo "writing ./pgppad.pl" cat > ./pgppad.pl << '\End\Of\Shar\' # Perl module to allow padding and some other manipulation of PGP # files. # # Include this with the statement: # require 'pgppad.pl' # # 10/16/93 # Hal Finney # Read a PGP Cipher Type Byte and the following length. # One argument: file to read from # Returns several things, in this order: # CTB, with the length information removed, as a number. # Length of following packet. # Name of this kind of packet, made up, see list below. # Packed CTB/length packet, suitable for writing out. # Returns an empty string on error. sub read_ctb { local($file) = @_; local($ctb, $length, $name, $rctb, $rlength, $lengthlength); if (read ($file, $rctb, 1) != 1) { # Raw ctb return ""; } $ctb = unpack ("C", $rctb); if ($ctb < 128) { return ""; # Must have high bit set } $lengthlength = $ctb % 4; $ctb -= $lengthlength; if ($lengthlength == 0) { $lengthlength = 1; } elsif ($lengthlength == 1) { $lengthlength = 2; } elsif ($lengthlength == 2) { $lengthlength = 4; } else { $lengthlength = 0; $length = -1; # Unknown length } if (read ($file, $rlength, $lengthlength) != $lengthlength) { return ""; } if ($lengthlength==1) { $length = unpack("C", $rlength); } elsif ($lengthlength==2) { $length = unpack("n", $rlength); } elsif ($lengthlength==4) { $length = unpack("N", $rlength); } $rctb = pack ("C a".$lengthlength, $rctb, $rlength); # Packed data if ($ctb==0x84) { $name = "pubkey header"; } elsif ($ctb==0x88) { $name = "signature"; } elsif ($ctb==0x8c) { $name = "message digest"; } elsif ($ctb==0x94) { $name = "secret key"; } elsif ($ctb==0x98) { $name = "public key"; } elsif ($ctb==0xa0) { $name = "compressed"; } elsif ($ctb==0xa4) { $name = "conventional encrypted"; } elsif ($ctb==0xa8) { $name = "plaintext"; } elsif ($ctb==0xb0) { $name = "trust"; } elsif ($ctb==0xb4) { $name = "user id"; } elsif ($ctb==0xb8) { $name = "comment"; } else { return ""; } return ($ctb, $length, $name, $rctb); } # Write a CTB and length field out. # 3 arguments: file handle, ctb value, and length in bytes. # No return value. # Length gets output as 1, 2, or 4 bytes, the smallest in which it # will fit. # If length is negative we output no length field, but an "indefinite # length" code is added to ctb. sub write_ctb { local($file, $ctb, $length) = @_; local($rctb); $ctb = $ctb - ($ctb % 4); # Be sure 2 low bits are clear if ($length < 0) { $rctb = pack ("C", $ctb+3); # Packed data } elsif ($length > 65535) { $rctb = pack ("C N", $ctb+2, $length); # Packed data } elsif ($length > 255) { $rctb = pack ("C n", $ctb+1, $length); # Packed data } else { $rctb = pack ("C C", $ctb+0, $length); # Packed data } print $file $rctb; } # This entry point always outputs a 4-byte count. Length must be > 0. # Otherwise like write_ctb. sub write_ctb_4 { local($file, $ctb, $length) = @_; local($rctb); $ctb = $ctb - ($ctb % 4); # Be sure 2 low bits are clear if ($length < 0) { die ("write_ctb_4 called with negative length\n"); } $rctb = pack ("C N", $ctb+2, $length); # Packed data print $file $rctb; } # Pad a PGP public-key-encrypted file to the specified length. # Arguments: input file handle; output file handle; new size. # Returns negative value on error. See the code for what the # different values mean. # Returns 0 on success. sub pgppad { local($infile, $outfile, $size) = @_; local($ctb, $length, $name, $rctb, $insize, $buf); # Read ctb & length of pubkey header ($ctb, $len, $name, $rctb) = &read_ctb($infile); if ($ctb == 0) { return -1; # Error } if ($name ne "pubkey header") { return -2; # Error } if ($len < 0) { return -3; # Error } $insize = length($rctb) + $len; # Read packet of pubkey header if (read ($infile, $data, $len) != $len) { return -3; } # Write out pubkey header, unchanged &write_ctb($outfile, $ctb, $len); print $outfile $data; # Read ctb and length of conventional packet ($ctb, $len, $name, $rctb) = &read_ctb($infile); if ($ctb == 0) { return -4; # Error } if ($name ne "conventional encrypted") { return -5; # Error } # Calculate size of outgoing conventional packet. # Assume rctb won't change size; it may grow by 1 or 2 in some # rather rare cases, in which case we'll be a byte or two too big. $size -= $insize + length($rctb); if ($size < $len) { return -6; # Error } # Output CTB with new length &write_ctb_4($outfile, $ctb, $size); # Copy remainder of input file while (read ($infile, $buf, 32768)) { print $outfile $buf; } # Note that this random number generator is probably not # cryptographically strong. srand (time|$$); while ($len < $size) { print $outfile pack ("C", int(rand(256))); ++$len; } return 0; # Success } 1; # Non-zero return for 'require' \End\Of\Shar\ else echo "will not over write ./pgppad.pl" fi if `test ! -s ./pgppadt.pl` then echo "writing ./pgppadt.pl" cat > ./pgppadt.pl << '\End\Of\Shar\' # Test program for pgppad.pl, showing how to use it. require 'pgppad.pl'; open (IN, $ARGV[0]) || die ("Couldn't open $ARGV[0]\n"); open (OUT, ">$ARGV[0].pad") || die ("Couldn't create $ARGV[0].pad\n"); $padding = $ARGV[1]; @stat = stat(IN); $size = $stat[7]; print "Input file $ARGV[0] has size $size bytes\n"; print "Output file $ARGV[0].pad will have size ".$size+$padding." bytes\n"; if (($code = &pgppad (IN, OUT, $size+$padding)) < 0) { die ("pgppad returns code $code\n"); } close (IN); close (OUT); print ("Done\n"); \End\Of\Shar\ else echo "will not over write ./pgppadt.pl" fi echo "Finished archive 1 of 1" exit

3 2

Re: Why encrypt intra-remailernet.
by Nathan Zook 17 Dec '03

17 Dec '03

>We had some concerns here a while back that someone was trying to exploit >such a feature to create an exponentially-growing message that would >totally overload the remailers. A message of the form: > >:: >Request-Remailing-To: <list of remailers here> > >:: >Request-Remailing-To: <list of remailers here> > ><repeat about 20 times> > >was sent. If all remailers had observed and honored the multiple >requests, there would have been uncounted trillions of messages flying >about. So I would caution anyone considering implementing this feature. > >Hal Was this Detweiller's "exponentially growing message"? Note that requiring pgp wrappers kills this... Nathan

2 1