December 2003 - cypherpunks-legacy

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

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

Fundamental Question?
by Anthony Ortenzi 17 Dec '03

17 Dec '03

Although I understand the need for remailers for anonymity, is it not true that the whole idea of encryption (good encryption, that is) is that no matter who gets the encrypted text, it really doesn't matter? Does this not mean that something like USENET is *perfect* for this? -Anthony

4 4

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

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: "bad" government
by alt＠iquest.net 17 Dec '03

17 Dec '03

>> If strong government resulted in liberty and freedom, then the >> most intrusive, all-encompassing governments would result in >> its citizens having the most liberty. Is this the case? I would >> look at the (former) Soviet Union, Iran, Cuba, East Germany, etc., >> for your answer. >Unrestricted individual freedom leads to unrestricted freedom of >`private' corporations. Private corporations uncurbed by society's law are >autarkies: internally totalitarian, externally predatory, as amoral as >amoebas. > >Is this the shape of the future you seek? 'Tis better to err on the side of liberty. To suggest otherwise would indicate that the origin and true meaning of "rights" or "liberty" is not understood. You can NOT restrict someone's rights simply because they MIGHT harm another (prior restraint). If they do cause actual harm to someone, they should be brought to justice. To place restrictions on someone based on the possibility that may may cause harm introduces restrictions based solely on the authorities' opinions (political philosophy, religion, race, etc). That that the shape of the future YOU seek? ************************************************************ * Just your basic signature block * * * * Al Thompson * * Fidonet 1:231/110 * * alt(a)iquest.net * ************************************************************

2 1

Frothing remailers - an immodest proposal
by Nathan Zook 17 Dec '03

17 Dec '03

kevin(a)elvis.wicat.com: >Be gentle, though - it's my first time. Here? You jest. ;) >It seems to me that the current remailer web suffers a fundamental flaw. >It is simply too static. When a remailer disappears, service is >disrupted and messages are lost. Humans have to statically route their >messages through the web either by hand or using relatively primitive >tools such as the chain script (not to belittle the useful work that has >been done, but it is by no means idiot proof yet). Basically, the >current web of mailers shows nothing of the dynamic nature that has kept >the internet alive and has offered us a decent chance at truly anonymous >communications, nor is it easy to use to its full potential. > >Consider a more dynamic web of remailers. I envision remailers that >actively advertise their presence on the web so that all active >remailers are aware of all other active remailers. This advertising is >to have very low latency so that a new mailer can be known to the web >within minutes (I will address the implementation of this later). Thus, >remailers can constantly be appearing and disappearing without impact on >the web as a whole (I refer to this dynamic web of remailers as a >"froth"). Imagine also that remailers are allowed to dynamically perform >the routing functions that are currently done statically offline (for >reasons I will discuss shortly). > Some version of this discussion came up a few months ago, and I passed on it then, but I think I've heard enough to comment now: The remailers are based on an inherently different model than the InterNet. Some of these differences, in fact, are crucial. 1) The InterNet is based on mutual cooperation/mutual trust. Cypherpunks trust no one that they don't have to. This is not just a result of our twisted psyche. If we could trust everyone, we wouldn't _need_ remailers. Since we don't even know who is whom out there, we avoid extending trust. 2) The InterNet is concerned first about reliability, and not at all about privacy. The remailers are concerned first about privacy, and can leave reliability to the users, if need be. There is nothing to prevent Alice and Bob agreeing to send each other ACK statements, and retransmitting messages if they don't get the ACK. There has been some mention of remailers doing the same with each other, in an attempt to improve net-wide reliability. BTW, with T1, sending ACKs is not unreasonable between remailers. 3) From 1) and 2). The remailers are heading towards mandatory PGP, possibly nested. All InterNet messages are world-readable--although this may be changing as the model breaks down. Again, this has to do with the intrinsic diffences. >The use of such transient routers implies allowing dynamic routing. If >any given remailer may go down or move at any point, it is impractical >to expect users to keep track of which are up at the moment and create >static routes in the current manner. The only reasonable solution I have >come up with is to allow the remailers themselves to choose routing, >given that they have full knowledge of the current state of the froth. Here we have the real head of the problem, as Hal so asutely points out: in your model, if the first remailer is bad, the message is compromised. If user encrypt to all remailers, they might as well encrypt directly to mole(a)snakeoil.nsa.gov. If they don't, they severly limit who can pick out their messages. In particular, they bypass transient remailers. But that isn't all. If the remailers pick the route, they are in a no better state than the users. Since the flushing attack requires remailers to operate on ticks, with carryover, an hour delay per remailer is almost minimal, untill traffic really picks up. So if some message routes through four remailers, a minimum of four hour delay results. In your case, this could easily move between in/out of service modes. > Think about the proposed extension to MixMaster to >allow separate parts of a multi-part message to be routed separately, >and consider whether you really want to have to do this by hand. I >strongly suspect that most messages are currently routed via boilerplate >scripts, which has to make the job of traffic analysis much easier for >our good friend Eve. Stupid is as stupid does. >By the way, a brief rant on a related topic; people speak of not >trusting remailers any further than necessary, while I am clearly >suggesting granting more authority and trust to the remailers. This >notion of not assigning trust is simply nonsense. When you send a piece >of mail to a remailer, encrypted or not, you are assigning complete >trust in that remailer to keep you anonymous and not to forward your >mail to the NSA immediately. NOT TRUE. With proper use of encryption, you are trusting your first remailer only to not reveal that you sent a message, and not to correlate that message to the one it sends out. With rational use of garbage running two deep, you can even suffer this loss without significant harm. >This does lead to a related problem, however; if we allow remailers to >pop up at random and join in the froth, how do we know that Deitweiller >won't set up a number of black hole remailers that take your mail and >throw it away, disrupting the froth, or forward it to nphard(a)nsa.gov? How indeed? The reason we chain is because we _don't_ really trust our first remailer--or any other. >Fortunately, we already have the PGP web of trust model in place and can >use it to good effect in this case. Remailers should simply not route >mail through any remailer whose public key is not trusted unless >explicitly ordered otherwise. This ring remailers to the user--with an exception list for those not "live". Nathan

1 0

The FNORDWALL CHIP.
by Robert Rothenburg Walking-Owl 17 Dec '03

17 Dec '03

> ----- Transcript of session follows ----- > ... while talking to toad.com.: > >>> RCPT To:<cyberpunks(a)toad.com> > <<< 550 <cyberpunks(a)toad.com>... User unknown > 550 <cyberpunks(a)toad.com>... User unknown Talk about lame. I accidentally CC'd this to "cyberpunks". *sigh* [ More header snipped! ] > > > > > THE FIREWALL CHIP! U'RE PHONE ALWAYS OFFHOOK? > > Fnorjd! > > > > > 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? > > I believe there is a way to get regular analog phones to go "off hook" > by sending the right kind of signal down the wire. Apparently not that > reliable if you've got multiple extentions. I think some newer phone > systems and/or newer phones don't work that well for the method, though > I never tried it myself. > > > > This problem demands a hardware solution. How about an adapter module > > between microphone & the rest of phone? > > How about disconnecting the phone when uneeded? Or, filter the calls through > an answering machine (which may also defeat such a method described above). > > [ Snip! ] > > > > 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. > > I don't think it will be a necessity. I can think of several alternatives > that don't require trusting an "outlaw industry". > > Rob > > > --VAA00527.791777197/abel.ic.sunysb.edu-- > >

1 0