December 2003 - cypherpunks-legacy

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

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: Frothing remailers, the advertising and pinging problems
by xpat%vm1.spcs.uma.thurman.edu＠vm1.spcs.umn.edu 17 Dec '03

17 Dec '03

jrochkin(a)cs.oberlin.edu (Jonathan Rochkind) wrote: > ++Mail ping. Non-IP, simple, slow. ++ > A mail ping simply consists of sending a message to a remailer with a > Request-Resending-To: yourself. When you get it back, you know the > remailer is alive. > This has the advantage that it's hard for the remailer > to trick you, even if it is an evil NSA remailer that wants you > to believe it is alive, even though it really throws messages in > in the trash. It can't differentuate between your "ping" > (to be returned) and a normal message (to be thrown in the trash). Sure it can. if (message_origin==request-resending-to) forward_message; To get around this you would have to chain, thereby relying on an additional remailer. Of course your origin and resend addresses could become are different through net.sorcery, but to rely on existing (and most likely transient) security loopholes are unsound foundations to construct a persistent reliable remailer net. Of course, clever Evil Remailer (tm) operatives might have their machines work *most* of the time, and have more than one, so that the entire network of remailers *seems* unreliable, or subtlely mangle encrypted messages so that the ball drops somewhere else. ---------------------------------------------------------------------- P M Dierking | "Emptiness is consistent with everything" --Nagarjuna

1 0

Re: Remailer encryption module
by Hal 17 Dec '03

17 Dec '03

From: "Perry E. Metzger" <perry(a)imsi.com> > Eric Hughes says: > > > > Once we get a data format, implementations will follow. > > > > The obvious data format is MIME's "Security Multiparts". > > Perry For those wishing to follow this debate, here is a URL for this document: <URL:http://info.internet.isi.edu/in-drafts/files/draft-ietf-pem-sigenc-03.t…> I had trouble finding it since the filename does not contain "mime" or "security". Hal

1 0

info
by Luis Agustin Perez 17 Dec '03

17 Dec '03

I recently read an atricle in HT magazine called cyberbucks. I was wondering if you could send me some information on the topic of the article. thanx

1 0

MX'ing and jpunix.com
by John A. Perry 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- JPUNIX.COM (soon to be alias.net) offers a MX service for individuals that want to run an anonymous remailer but don't want the domain they are operating from to be immediately apparent. By making application to perry(a)jpunix.com, a remailer operator will be granted a DNS MX record pointing to the domain address of the requestor's choice and will appear to reside in the jpunix.com (alias.net) domain. Additional masking can be provided by having the MX record point to myriad.pc.cc.cmu.edu. What good does this do? I have an agreement with myriad.pc.cc.cmu.edu (Matt Ghio) where myriad will take the MX-pointed record and additionally alias it through the smail daemon on myriad. This function adds the unique benefit where determining the actual location of the remailer in question will be foiled when using nslookup. Since an additional alias is performed the result of an nslookup will always point to myriad. The actual location of the remailer remains hidden inside the alias on myriad. Lastly, Matt has the EXPN function of his sendmail daemon disabled so the identity of the remailer can't be determined by alias expansion. Future modifications to this scheme include adding an addition step whereby the MX-alias process will cause a version of Raph Levien's premail to post-process the message to add one or more random remailer paths the the overall path that the message travels. This step in still in the planning stages and has not been implemented yet. If you have and questions, or want to set up an MX record, send email to: perry(a)jpunix.com or ghio(a)myriad.pc.cc.cmu.edu John Perry < perry(a)jpunix.com> -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLzFN6lOTpEThrthvAQHfAAQAkzoGHz7iaJKHMzB5GEQr8OvEwhDY0F9s lCZUJhTw3KV2hVWDoUtZNPwiSf4vcsDhGx0CDQrDUon2vXC0mOHj4zBbDhhuUD5l /NCPOmtWKFSnWiny2JbD0esNIuxIaWfa/tVTkDoDq/zPtsG0awmHTpGMSeIkkxvy II1mDwnZ9n0= =2jQD -----END PGP SIGNATURE-----

2 1

Remailer Unreliability
by nobody＠myriad.pc.cc.cmu.edu 17 Dec '03

17 Dec '03

What if it was possible to specify an alternate remailer? In the case that a remailer went down, you could specify an alternate. For example: :: Anon-To: remailer(a)foo.com Alternate-To: remailer(a)bar.com :: Encrypted: PGP ---pgp msg--- If foo.com was down, the message would be delivered to bar.com instead. The PGP message would have to be readable to both of them, so it would decrease security, but reliability would be better, especially for reply blocks. Comments?

3 2

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

Remailing in safe-tcl
by Hal 17 Dec '03

17 Dec '03

Suppose someone runs safe-tcl to process incoming mail, and supports the "delivery-time" mode, where incoming mail programs are executed as soon as they arrive. (Support for this mode doesn't really exist yet, but I am putting together a simple script to enable it.) Here then is an example of how a self-remailing message might look: [Other headers] Content-Type: multipart/enabled-mail; boundary="----- =_791623442" Content-ID: <2269.791623082.4@cryo> ------- =_791623442 Content-Type: application/Safe-Tcl; version="7.3"; evaluation-time=delivery Content-ID: <2269.791623082.2@cryo> # Get the other sub-part of this message and send it to the desired address SafeTcl_sendmessage -to hfinney(a)shell.portal.com \ -subject {Remailed message} -body [SafeTcl_getbodyprop 1.2 all] ------- =_791623442 Content-Type: text/plain Content-ID: <2269.791623082.3@cryo> This is the body of the message, which will get remailed. It could be a PGP message if the server supported automatic decryption of incoming PGP mail. Then it could have nested remailing instructions in it. ------- =_791623442-- This is a MIME format message with two sub-parts. The first is the script which gets run on delivery, and the second is the "payload", the message to be remailed. The script is a simple one-liner which sends the second subpart to my email address. Safe-Tcl does allow (rather vaguely) for automatic decryption of incoming mail, as well as authentication (so you might allow messages signed by certain people to get access to some special functions). There is a rudimentary mechanism for communication between scripts and server, and (I think) among scripts themselves, with SafeTcl_getconfigdata and SafeTcl_setconfigdata. These let you put in {key, value} pairs that other scripts can read. I don't see any straightforward way for a script to suspend itself and re-activate on some future event (such as the arrival of another message). Maybe it could put its whole self into the config database as a {key, value} pair and rely on future messages to pull it out and execute it. But that doesn't seem too great. There is a lot of interest in this notion of mail messages as scripted agents which go zipping about the network gathering data which they send home. I am optimistic that we will be able to get remailing capabilities out of this infrastructure largely for free. Hal

1 0

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