December 2003 - cypherpunks-legacy

<none specified>
by Anonymous 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I wonder if 'Net-cash' is any good? Try sending e-mail to netbank-info(a)agents.com with the words netbank-intro on the first line of body. It says: The NetBank ...is based on "payment coupons" that may be traded via electronic mail ... NetCash is easily obtained by using the NetBank's "Check Cashing by FAX" service. Customers may purchase NetCash by writing a personal check and faxing it to the NetCash Distribution Center. Travelers on the Infobahn may carry NetCash and cash checks while online. and lots more. Does not look too anymous, however, and there is no mention of PGP in the documents I got. But do check it out. When you get the info, they give you 5 cents worth of NetCash, BTW. They also have other stuff: For information on related topics, please send e-mail to "netbank-info(a)agents.com" with the following keyword(s) in the message: Keyword Topic netbank-faq Answers to frequently asked questions buying-netcash How to buy NetCash from the NetBank netbank-merchant Opening a NetBank Merchant account shareware-info Using the NetBank to collect shareware fees boardwatch-story Reprint of NetCash story from Boardwatch Magazine story-update Enhancements since the Boardwatch story was published - --- [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 iQBFAwUBLzNURyoZzwIn1bdtAQFwJwF+KeI9ErF2N04Y1+XwX4B6teBDlIudSuip uNhn0k80uoru/vIWb//WMiMCBFHT+Bww =39YD -----END PGP SIGNATURE-----

1 0

Forward: Teleco/Cabe REg. & Free speech
by Harry S. Hawk 17 Dec '03

17 Dec '03

TELECOM REFORM, REPUBLICAN-STYLE Sen. Larry Pressler (R-SD) has proposed a telecommunications reform plan that would drop all cable TV rate regulations; allow local phone and cable competition and cross-ownership in one year; ease foreign ownership restrictions; and allow local phone companies to compete in long distance in three years. A formal counter proposal is expected from the Democrats February 14, and it's expected that there will be objections to most of the provisions outlined in Pressler's bill. (Investor's Business Daily 2/2/95 A4) (((cut here))) For those that don't know I have my Master's in Interactive Telecommunications, and have long looked at cable and teleco from several angles including freemarket and cypherpunk viewpoints. While there is a lack of detail here, I strongly endorse anything that lets cable and phone companies compete. They have largely the same customer base (although telco's have a larger % of the base), but the cable companies are in a better opportunity to over PCS, higher-bandwidth networking, and video on demand. What we have to watch out for is FCC regulation. It is well excepted that the FCC can censor commercial speech (cig. ads), and individual speech (the 7 dirty words), in the "public" interest. Cable and Teleco are FCC regulated. If they provide the network of the future, as opposed to UUnet-Microsoft (for example), we might have to be careful.. The "model" of interactivity most "thinking" people endorse is one that is two way. The FCC does really monitor what you say on the phone (although who knows about the NSA ;)... If you can in the brave new Telco/Cable future send as well as receive.. and send in broadcast-like mode... are you subject to content approval from the FCC? We should strongly endorse this move by. Sen. Pressler as it will get us broadband to many homes in 5 to 7 years, but we have to remain concerned about our freedom to speak not matter if that is one on one, or to a large group! /hawk -- Harry S. Hawk habs(a)panix.com Product Marketing Manager PowerMail, Inc. Producers of MailWeir(tm) & PowerServ(tm)

2 1

NYC CPUNKS MEET NEXT SAT
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: <none specified>
by rah＠shipwright.com 17 Dec '03

17 Dec '03

At 5:19 AM 2/4/95, Anonymous wrote: >I wonder if 'Net-cash' is any good? Probably the best discussion of the available transaction processing/settlement mechanisms is by Jason Solinsky. It's called "An Introduction to Electronic Commerce", and though he probably hasn't updated it since he wrote it a few months ago, he discusses NetCash there... http://nearnet.gnn.com/gnn/meta/finance/feat/sol.html Take a bow, Jason. Cheers, Bob Hettinga ----------------- Robert Hettinga (rah(a)shipwright.com) "There is no difference between someone Shipwright Development Corporation who eats too little and sees Heaven and 44 Farquhar Street someone who drinks too much and sees Boston, MA 02331 USA snakes." -- Bertrand Russell (617) 323-7923

1 0

signature validation on secure edit messages
by tjb＠acpub.duke.edu 17 Dec '03

17 Dec '03

Jeez. I really don't know why the heck this always happens to me, my digsigs not validating. You can finger me at tjbryce(a)amherst.edu to retrieve a message with a valid signature. I always write the message in eudora, copy it, sign it in MacPGP as TEXT with attached signature, then go back and paste it over the old message. Then I go back to MacPGP and check the signature on the clipboard to be sure - no problems. But after getting mailed, it doesn't work. Damn. Tom

1 0

There is another NetCash
by Hal 17 Dec '03

17 Dec '03

From: rah(a)shipwright.com (Robert Hettinga) > At 5:19 AM 2/4/95, Anonymous wrote: > >I wonder if 'Net-cash' is any good? > > Probably the best discussion of the available transaction > processing/settlement mechanisms is by Jason Solinsky. It's called "An > Introduction to Electronic Commerce", and though he probably hasn't updated > it since he wrote it a few months ago, he discusses NetCash there... People interested in NetCash should be aware of a potentially confusing name re-use. NetCash is also the name of a payment system designed by people associated with the Information Sciences Institute (affiliated, I think, with USC). A reference is: <URL: ftp://PROSPERO.ISI.EDU/pub/netcheque/information/netcash-cccs93.ps.Z > Despite the names, neither one is cash in the cryptographic sense: neither uses blinding. If you didn't want the bank to be able to create a database of every transaction you make, everything you spend and with whom, you would need to have some anonymous connection with the bank and exchange your netcash through that connection. This would be cumbersome IMO. Some payment system is probably better than none, but I hate to see the name "cash" expropriated by these non-cash systems. Hal

1 0

PGP padding scripts (again)
by Hal 17 Dec '03

17 Dec '03

Sorry for the bandwidth waste, but my anonymous correspondent was not able to ftp these scripts. I also got another request for the scripts. So here again is my post with a pair of perl scripts which will insert padding pretty much undetectably into a .pgp file. The one limitation is the quality of Perl's random number generator. 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

2 1

finney's perl scripts
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

hal , gotta question regarding your perl scripts . i ran em thru sh and d/l'd em , and here are the results of my tests . first , i pgp'd a file in binary format , then ran " perl pgppadt.pl test.pgp 10 " . the error i got was " Couldn't create test.pgp.pad " . so i renamed the file to " test " and tried again with good results ! i got " Input file test has size 732 bytes 10 bytes pgppad returns code -3 " . then , iran " perl pgppad.pl test 10 " and after the bit about perl running under dos/4gw protected mode , i get dropped to my command prompt . i took a look at the file , and it's size wasn't any different , so i renamed the file to test.pgp and ran it again and got the same results . so i guess i'm wonderin' if it added the padding , or what might be the problem ? for your info , i'm using perl 4.0.

1 0

Vinge on PKE ?
by lwp＠garnet.msen.com 17 Dec '03

17 Dec '03

Apologies if I repeat a question which has already been answered. My only gateway onto the Net is very expensive, and I miss many important postings. Some time ago it was asked why Vernor Vinge made passing reference to humans' naivete in trusting public key encryption, and some posters were seeking to contact professor Vinge for clarification. Has any further explanation been discovered for his distrust of PKE?

5 5

Re: Why encrypt intra-remailernet.
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

> Date: Sun, 29 Jan 1995 17:56:34 -0800 > From: Hal <hfinney(a)shell.portal.com> > > Of course it was Chaum himself in his 1981 paper (which I think is > available from the CP FTP site) who described the duplicate-message > attack. I don't see that inter-remailing encryption helps much, > because the attacker can still notice that whenever they inject > message A, _something_ goes to Bob. The real solution, as Chaum > pointed out, is that the remailer must reject duplicate messages, > even when separated by days. Doing this without keeping a database > of all messages ever sent is left as an exercise. Perhaps the postage could integrally contain the request-remailing- to field. Supose the postage were <e-money, to-address> encrypted to the remailer. Then replayers would want to copy the to-address into a new piece of postage. But, we assume, they can't figgure out what it is because they don't have the key for the remailer. If the remailer issued it's own non-blinded stamps, the remailer would have to keep a list of canceled stamps. (For as long as that series of stamps remains valid.) If the remailer used Chaumiam e-cash no logs would need to be kept at all. > Another aspect worth mentioning is that message splitting can make > the kinds of statistical correlations that Wei Dai was looking at > more of a danger. [...] Ideally you'd want to dribble them out at > some standard rate, a rate at which you always send a message > whether you have something to send or not. But this may introduce > unacceptable latency. If everybody ran a second level remailer, and if they always forwarded something (of very nearly the same size) when they recieved an encrypted message, then without compromising the users machine it would be imposible to say when a message was delivered. Some of the messages forwarded would need to be junk. Is there a polite way to send mail to a remailer, and ask it to junk the mail? Some of the messages forwarded would have to be 'part n of m' messages. Noyb

1 0