December 2003 - cypherpunks-legacy

IMPORTANT: BUG IN 68K IDEA ASSEMBLER DISTRIBUTED IN SECURE EDIT
by tjb＠acpub.duke.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- IMPORTANT NOTE: If you are going to use the IDEA 68k assembler distributed with Secure Edit b0.5, please take note of the following bug: You have to change @Mulzero3: neg.w d7 <--- addq.w #1,d5 sub.w -2(a1),d5 bra.s @Muldone3 to: @Mulzero3: neg.w d5 <--- addq.w #1,d5 sub.w -2(a1),d5 bra.s @Muldone3 I have not yet received any reports of data being fouled up by this, and before tonight personally had encrypted and decrypted megabytes without error, but note that I HAVE FOUND EXAMPLES OF IT FOULING UP A BLOCK OF DATA. IT IS DANGEROUS TO USE THIS CODE IN ITS PRESENT FORM. Please make note of this if you are going to use this 68k code. Currently, I do not believe this code is being used anywhere except Secure Edit b0.5, although it was certainly about to be used. I will immediately upload a corrected version of Secure Edit and source. Sorry about the screw up. Tom -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLzMbp1uwJA7oL8O9AQGk0wP/YF8VQ2jDtW63Wb7fteImBvYCfMi7NnTf tXMBV6U5iIKf+iBoED34gnwJyLAdEplpMa6P1yJUIMjNXly1/I+SzQoMFGVXuuKV m0h+idXI1mXTVG+gnmdpGMw9/6/u72DcaYCZRHveL8tuMesO5UdgQEDjvy+zX7+c 0cAvyXQaArg= =ubXB -----END PGP SIGNATURE-----

1 0

FIXED SEC. EDIT, SEC. EDIT SOURCE, UPGRADE PATCH
by tjb＠acpub.duke.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I have uploaded a fixed version of both secure edit and source code to ripem.msu.edu in the directory pub/crypt/mac. I have also uploaded a 35k patch that will update your b0.5 to b0.6. There are also some other minor bugfixes rolled into this b0.6 update. Again, sincere apologies for the bug (it was my fault), and I earnestly hope no data was compromised by it. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLzMx/1uwJA7oL8O9AQHHegP9FPCkO2fVO54Vm3kDTsJH+1SW5Iui3wTS F4BvZ0CSzJTw8K15oYOVnVbYcqofoOe5DvmR4ex1kK7zPObicfwLeIQbcvnRbBuI 0xpk+ymOMgOzjd9ySusXNuTCuwomQHXD4jTuyEsU+QrT6FEkmUJjA+TtctAZu7JX nbZGDtOD/18= =xKnR -----END PGP SIGNATURE-----

1 0

<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

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

17 Dec '03

> paid for by digital cash. Such a means of exchanging print, audio, > video, or any software might be virtually impossible to censor. Would it > be possible to build such a network using current cable systems? It is a reasonable bet that all data into the home will come on cable systems which means they require encrytion anyway.. there are bridged, not point-to-point... And other traffic like mobile voice and data will use some RF technology... which also requires encryption... Existing cable systems are now running 1 gigahertz of bandwidth and I had presentations from TW staff indicating 2 gigahertz is easily reachable.. Figure 2 gigahertz of bandwidth (split between analog and digital services) in each neighborhood and a ATM switch pulling those signals back to the "head-end/central office" via fiber, and you have the cable system of the future.. (e.g, for the next 5 to 20 years).. /hawk

1 0

Re: Why encrypt intra-remailernet.
by lcottrell＠popmail.ucsd.edu 17 Dec '03

17 Dec '03

> 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. I was not under the impression that Chaum e-cash was free from the need to keep a list of spent cash. Do you meant that it would be the bank, not the remailer, that would keep the database? > >> 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 Messages are not identifiable as "part n of m" except at the last hop. If you are a remailer, then they are only visible as such to you. In transit they appear as any other message. Yes, there is a polite way to send to a remailer's bit bucket with some remailers. Ghio remailers will trash any message sent which requests remailing to "null". Remailer@nately is a Ghio remailer. I can't remember if I implemented that in Mixmaster. If not, I will. -------------------------------------------------- Lance Cottrell who does not speak for CASS/UCSD loki(a)nately.ucsd.edu PGP 2.6 key available by finger or server. Encrypted mail welcome. Home page http://nately.ucsd.edu/~loki/ Check out my essay on the next generation remailer Mixmaster on the WWW page. For anon remailer info, mail remailer(a)nately.ucsd.edu Subject: remailer-help "Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come." --Nietzsche

1 0

Mixmaster client release
by lcottrell＠popmail.ucsd.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I have put a SPARC executable for the Mixmaster client on my home page. It is easy to install, just run one script. Please send me any comments. -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBLzSSA1Vkk3dax7hlAQGhyAP8DkA2AetIpCHfFhnUDP8qiKdPJ3ish36V ZFA/W3Gx+6Glzj+5ri7fnug6N3ENyLJ3eoUfWVWjJ6uK5yMczMQB6wX4m3Afhrwz xUw9WCKwbP0cktnLnMvbufDxyLTsGxA6yvWaRdCRVcqP4eyAVN4SiHCftE8EbI6Y Pg+3SYtjDf4= =5lAa -----END PGP SIGNATURE----- -------------------------------------------------- Lance Cottrell who does not speak for CASS/UCSD loki(a)nately.ucsd.edu PGP 2.6 key available by finger or server. Encrypted mail welcome. Home page http://nately.ucsd.edu/~loki/ Check out my essay on the next generation remailer Mixmaster on the WWW page. For anon remailer info, mail remailer(a)nately.ucsd.edu Subject: remailer-help "Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come." --Nietzsche

1 0

The SKRONK protocols (version 0.6)
by strick at The Yak 17 Dec '03

17 Dec '03

======================================================================== The SKRONK protocols version 0.6 ======================================================================== Henry Strickland <strick(a)yak.net> Sun Feb 5 1995 This is a working document, subject to change. Please comment on it! Skronk is a user-level C library that re-implements the usual "posix i/o" (unix man 2) functions and "berkeley socket" functions with a set of functions that can use enhanced or alternate ("skronked") protocols for TCP connections. (Typical enhancements could be authentication and/or encryption of the connection.) A simple negotiation protocol allows the clients and servers to agree on what enhancements are desired or required. Skronk is designed so that your common unix network clients and servers (telnet, sendmail, ftp, nntp, X11, etc.) can be merely relinked with the skronk library (libskronk.a) without changing the source code for the programs. As a matter of configuration and policy, skronked clients and servers may choose either to interoperate with normal (non-skronked) client and servers or to forbid normal connections. In order to not interfere with non-skronked programs, skronked connections take place an alternate TCP server port numbers. /* "Skronk" is a musical term, for a new-york-ish free-jazz * massively saxaphonish kind of music, e.g. John Zorn */ ---- THE UDP PROTOCOL BEGINS HERE ---- THE SKRONK MAP DAEMON A skronk map daemon is a UDP service that tells what skronked services are available from a site, and what alternate TCP server port numbers they use. The skronk map daemon receives "skronk map request" packets and returns "skronk map reply" packets that list pairs of port numbers, mapping normal server port numbers to corresponding skronked port numbers. The skronk map reply packet is sent to the same IP address and host port that the request was received from. If there is no map reply in a certain time, after a couple of map request resends, the skronk map client should assume that skronked services are not currently available on that host. SKRONK MAP REQUEST PACKET See "struct skronk_map_request" below. The comment will say something like "finger skronk(a)yak.net for info", to explain what is going on to network administrators who see these packets for the first time probing their hosts. SKRONK MAP REPLY PACKET See "struct skronk_map_reply" below. The "serial" field should match the serial field of the map request packet. Replies be cached, using the "ttl" time-to-live field for a timeout. If the request packet cannot be replied to (perhaps because the action was not understood, or the version was wrong), a reply with action SKRONK_MAP_NACK should be returned. If the magic field of the request is wrong, do not reply. (The magic number should be changed if the first five fields are changed; otherwise, version and opcode may be changed to implement new protocols.) Skronk map clients should also recognize as a reply the relevant ICMP packets indicating that there is no skronk map daemon. Version numbers 128 through 255 will not be assigned and are available for experimentation. Action codes 128 through 255 will not be assigned and are available for experimentation. Initial prototypes use UDP port 333 for the skronk map service, until a number is officially allocated. -------------------------------- /* unsigned long = 4 octets, "network" order */ /* unsigned short = 2 octets, "network" order */ /* char = 1 octet, ASCII encoding, NUL terminated */ struct skronk_map_request { unsigned long magic; /* SKRONK_MAGIC */ unsigned long serial; unsigned short version; /* SKRONK_VERSION */ unsigned short action; /* SKRONK_MAP_REQUEST */ unsigned long reserved; /* (corresponds to ttl) */ char comment[1]; /* variable length, NTBS */ /* after NUL, remained of packet ignored */ }; #define SKRONK_MAGIC 0x1F1206FB /* tail(md5("SKRONK_MAGIC\n")) */ #define SKRONK_VERSION 0x0101 /* major 1 minor 1 */ #define SKRONK_MAP_REQUEST 63 /* '?' */ #define SKRONK_MAP_RESPONSE 46 /* '.' */ #define SKRONK_MAP_NACK 33 /* '!' */ #define SKRONK_DEFAULT_TTL 3600 /* one hour */ #define SKRONK_NUM_TRIES 3 /* try three packets */ #define SKRONK_WAIT_TIME 3 /* wait three seconds */ struct skronk_map_reply { unsigned long magic; /* SKRONK_MAGIC */ unsigned long serial; /* matches map request serial */ unsigned short version; /* SKRONK_VERSION */ unsigned short action; /* SKRONK_MAP_REPLY or _NACK */ unsigned long ttl; /* cache time to live, in seconds */ unsigned short map[1]; /* variable length, 0 terminate */ /* after 0, remainder of packet ignored */ }; -------------------------------- EXAMPLE SKRONK MAP REQUEST AND REPLY Map Request Packet: ip header: UDP protocol 128.32.43.52 source_ip_address 199.170.88.5 destination_ip_address udp header: 1066 source_port skronk destination_port (number not assigned yet) body: 0x1F1206FB skronk_magic 2001 skronk_serial 1 version '?' action (SKRONK_MAP_REQUEST) "finger comment (for paranoid net admins) skronk(a)yak.net for info" Map Request Reply: ip header: UDP protocol 199.170.88.5 source_ip_address 128.32.43.52 destination_ip_address udp header: skronk source_port (number not assigned yet) 1066 destination_port body: 0x1F1206FB skronk_magic 2001 skronk_serial (copied from request) 1 version '.' action (SKRONK_MAP_REPLY) 3600 ttl (one hour) map list: 23, 423, /* skronked TELNET on port 423 */ 25, 425, /* skronked SMTP on port 425 */ 70, 470, /* skronked GOPHER on port 470 */ 80, 480, /* skronked HTTP on port 480 */ 514, 914, /* skronked shell on port 914 */ 750, 350, /* skronked shell on port 350 */ 6000, 6400, /* skronked X11 on port 6400 */ 0 /* zero marks end of list */ /* ... assume other services cannot be skronked */ /* * Notice the skronked ports on this host (199.170.88.5) * have been allocated by the system administrator * using a simple (but arbitrary) rule: * * add 400 to the normal number, unless this has * problems (like it would bring a less-than-1024 * port number to be greater-than-1024), in which * case subtract 400. * * I propose this rule as a default, since it does not seem * to collide with common port numbers, but because we * have and always use the skronk map daemon, each site * could pick different numbers. */ ---- THE UDP PROTOCOL ENDS HERE ---- SKRONK PER-CONNECTION NEGOTIATION /* * The current skronk prototype temporarily works on * a simpler negotiation scheme, but below is the * intended scheme. */ /* * Good questions: * 1. Would telnet-style negotiations be better? * * I conclude not: * -- this offers options to be combined at once * -- this does fewer passes from server to client * -- this uses ASCII names rather than numbers * for options, which allows liberal * experimentation with "x-" names. * * 2. Do we need some escape-character & character-stuffing * to re-open negotiations? * * Maybe... but flow of control probably never returns * to the skronk layers with any such requests, so let's * let some escape-octet (with escape-octet-stuffing) * option for return-to-negotiation be a negotiated * option that can be added later. */ The skronk library does a negotiation at the beginning of each TCP connection, after "connect()" and "accept()" rendezvous, before returning flow of control to the application. This negotiation is transparent to the application, but may be configured with skronk configuration files or environment variables. These negotiations should not be confused with other negotiations specific to the program, such as TELNET negotiations, which would occur later, once control is returned to the application. /* * I should first define 'negotiation line', 'acceptance line', * and 'disconnect' to describe the following... */ When the connection is made, the server writes a line of 10 to 999 octets, composed of ASCII characters, terminating with CRLF, to the client. This line must begin with the eight characters 'S' 'K' 'R' SPACE h t o SPACE where h, t, and o are three decimal digits '0'-'9' (hundreds, tens, and ones places), with leading a zero in the hundreds place if required, specifying the length of this line, counting the CRLF at the end. Thus the minimum length of the line is 10. The reason for putting the length of the line in the front is so that the client can first read 8 characters, and then read the rest of the line, but not try to read any characters beyond that size. After the "SKR hto " follow zero or more words of the regexp form [A-Za-z0-9+][A-Za-z0-9/.+-]* separated by one or more SPACE characters. Case matters. These words specify protocols, and should registered with strick(a)yak.net, or begin with "x-" for experimental protocols. By sending this line, the server volunteers to server this protocol skronked with any of the listed protocols. The server should list the protocols in order of preference, its favored protocols first. The client reads this line, chooses one (or more) protocols, and responds with a similar line, listing only the protocol(s) that it chooses to use, in a specific "stacking" order, from the first protocol applied to the last. For instance, if it chooses "gzip" compression followed by "des" encryption, it should list them in the order "gzip des". Some protocols choices may not be compatible, and some protocol choices may not have stacking order; this will have to be described when the protocols are defined. If the client does not like any of the choices offered, it may hang up the connection, instead of replying with a line. If the server accepts the protocol the client chose, it responds with 8 characters 'S' 'K' 'R' SPACE 'O' 'K' CR LF If not, it may either disconnect the connection, or it may send another initial negotiation line, which should be different from the initial line offered (probably with fewer options for the client to choose). If the negotiation is accepted, what happens next depends on the accepted protocols, and on the actions of the rest of the program. Typically a selected protocol may have to do some more negotiation or trading of data before control is returned to the application. And later reads and writes from the application to the skronked socket may be intercepted and frobbed. PRIMORDIAL PROTOCOLS For stream encryption: /* needs work */ A simple initial protocol named "dh/idea.1". Use Diffee-Hellman key exchange from RSAREF 2.0. Let the server declare the R_DH_PARAMS, and the size of things. Use IDEA encryption in CFB mode from PGP 2.6. No authentication -- susceptible to man-in-the-middle attacks at connection time. For authentication: /* needs lots of work */ A simple initial protocol named "auth-pgp.1" Use PGP public keys and certificates to create a web of trust and thereby authenticate hosts. Can be combined with "dh/idea.1" or used separately. (This probably requires having secret key pass phrases on multiuser machines, so it's one small step forward.) -------------------------------- END $Header: /x/nepal/x/yak/strick/work/skronk-write/RCS/skronk.proto,v 1.3 95/02/05 01:18:49 strick Exp Locker: strick $

6 10

NYT on Tera and UUNet
by John Young 17 Dec '03

17 Dec '03

John Markoff writes today on Tera Computer's supercomputer prayers. For email copy (13k) send blank message to <jya(a)pipeline.com> with subject: TER_nup And, Laurie Flynn writes on UUNet's tender tap by Microsoft. For copy (13k), same, with subject: UUN_zzz

1 0

Here we go again...
by Johnathan Corgan 17 Dec '03

17 Dec '03

+---------------------------------------------------------+ ##### # # # # # ##### #### ##### # ## ## # # # # # # # # # ### # # # # # # # # # ### #### # # # # # ####### ####### # # # # # ##### # # # # # # ##### ##### # # # +---------------------------------------------------------+ -> EMA ALERT <- News For and About the Members of the ELECTRONIC MESSAGING ASSOCIATION ============================================================ February 3, 1995 -- Number 18 <----------------------------------------------------------> ***** SPECIAL ALERT ***** - Congress to consider making all system operators liable for messaging content. Bill would force employers to monitor message content. ACTION NEEDED NOW! <----------------------------------------------------------> UNREASONABLE NETWORK POLICING PROPOSED Yesterday, Senator Jim Exon (D-NE) introduced S.314, the Communications Decency Act of 1995, in the United States Senate. In an effort to stamp out digital pornography, it makes all telecommunications providers doing business in the United States (from the telephone companies all the way down to offices that use LANs) liable for the content of anything sent over their networks. To avoid the possibility of tens of thousands of dollars in fines and up to two years in jail, business owners would be forced to police their networks and monitor in advance all messages sent over them. WITHOUT ACTION - COULD BE LAW IN MONTHS This bill is substantially the same as the one he put forward last year. He will offer it as an amendment to the pending telecommunications deregulation legislation in the U.S. Senate, which is expected to be enacted by July. Last year, his amendment was adopted even though many thought it hastily drafted and poorly thought out. Fortunately, the telecommunications deregulation legislation died. This year, a more conservative U.S. Congress may be even more reluctant to challenge a "morality" amendment; and its legislative vehicle, the telecommunications deregulation legislation, stands a much better chance of passage this year. ACTION NEEDED NOW Action by the business community is needed now. Please notify your corporate government affairs office and/or your legal counsel. This measure could be adopted as an amendment to the telecommunications bill IN A MATTER OF WEEKS (or potentially added to any legislation pending on the U.S. Senate floor), if business does not mobilize against it. S.314 will not stop digital pornography, but it could devastate the messaging business. If you are interested in further information or are able to participate in lobbying efforts over the next few weeks, contact Sarah Reardon at EMA (see below). ------------------------------------------------------------ EMA ALERT is published and copyrighted (1995) by the Electronic Messaging Association. Permission to reproduce and/or redistribute with attribution is hereby given to all EMA members. For more information about anything in EMA ALERT, contact EMA via e-mail - use either X.400 (S=info; O=ema; A=mci; C=us) or Internet (info(a)ema.org) address, facsimile (1-703-524-5558), or telephone (1-703-524-5550). Any EMA staff member can be addressed directly via e-mail by using, for X.400, G=<firstname>; S=<lastname>; O=ema; A=mci; C=us, and, for Internet, <firstinitial><lastname>@ema.org. EMA's postal address is 1655 N. Fort Myer Dr. #850, Arlington, VA 22209 USA. == Johnathan Corgan "Violence is the last refuge of the incompetent." jcorgan(a)aeinet.com -Isaac Asimov

2 1

HIR_hear Crypto Hearing Transcript
by John Young 17 Dec '03

17 Dec '03

Thanks to Declan we've digitized the declassified 64-page transcript of the House International Relations Committee closed hearing on the SAFE bill, dated July 21, 1997, at which FBI's Freeh, NSA's Crowell and BXA's Reinsch made statements on crypto policy, described the administration's dreams for worldwide GAK and noddled about how to shame unpatriotic industries -- Microsoft is cited as a prime disobedient, while Netscape, Reinsch smarms, has joined up. This is Rep. Gilman's committee, and the discussion aptly outlines the grounds for his "first amendment" to SAFE recently posted here. Our Web site is kaput this morning so for now we can only offer the 99K file by e-mail, HTML formatted. If you want a copy send us e-mail with the subject: HIR_hear We'll include a parallel 18 July letter to Members of Congress on the same topic from AG Reno and seven top federal law enforcers, also provided by Well-connected Declan. If your mail can't handle a 99K file, someday, maybe this weekend, the two docs will be on our site at, respectively: http://jya.com/hir-hear.htm http://jya.com/crypto-law8.htm Coda: Gilman represents, if you didn't know, my rathole of the U.S. financial market. The transcript shows that he loved the G-men, wink-winked at them throughout the hearing, eyeing the propects for helpful legislation. Reinsch brags that BXA and the banks are preparing an onslaught on the undisciplined world market, working with world leaders, as ever, caching real-time gold for select wise marketers, bribing with gov-biz deals across the political spectrum. Sez all the industry holdouts on GAK will come around when they see the Big Corps caving. Reinsch asserted that Microsoft is power behind Goodlatte's bill. Goodlatte didn't deny, just said MS is one of a horde. Hmm.

1 0

No Subject
by Syed Yusuf 17 Dec '03

17 Dec '03

Does anyone have a an list of a current remailers? /sy/

1 0

BROKEN REMAILERS
by nobody＠tower.techwood.org 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I have tested remailers and their PGP keys over some time now and this is what I have found: MIXMASTER is a great, fast and reliable remailer but you can't PGP with it. REMAILER(a)NATELY.UCSD.EDU is just as fast and reliable (same guy) and you can use PGP, but a few weeks ago it started acting really funny: It will forward any ATTACHED files, but it will only read the first commandline of a PGP block that has been pgp'ed with Nately's public key. In other words, if you wrap layers of chained remailers inside each other, you will now have to have NATELY as the *last* link in your chain as it will otherwise discard the rest of the block. Alternatively you can have the chain as a series of attached files. USURA is really quick too and has lately been reliable. But it has always suffered from the same problem as Nately, namely that it will truncate all of the remaining lines in a PGP message encrypted with its own public key, this making it impossible to chain effectively. It will read the first command only. It DOES forward all attached files, however (by which I mean text that have been tagged on OUTSIDE of the pgp block encrypted to Usura). EXTROPIA and VOX suffer from the exact *opposite* problem. They forward the entire inner remains of a pgp block untouched after having only read the first commands to them. But they both ignore and discard all text outside that first initial pgp block encrypted with their public keys. This means that you cannot send a message with multiple pgp's through either of them: because any attached parts get thrown away. As a practical application, it means that you can't use either of these two as part of your nym(a)alpha.c2.org setup, sadly... BTW, with VOX you will have to add the ::Encrypted: PGP bit whereas you don't have to do that with Extropia (or with alias(a)alpha.c2.org for that matter). REBMA is ideal in that it does not touch your message: You can use *both* attached files and "wheels within wheels" where you have layers of pgp'ed remailer instructions hidden inside one another. The main problem with REBMA is that she has been down a bit lately and even when she is not down, you have to wait ages: 1 or 2 days, sometimes even more. The best remailer, IMO, is HAL(a)ALUMNI.CALTECH.EDU which operates in tandem with HFINNEY(a)SHELL.PORTAL.COM: Both are fast and very reliable. Moreover, neither will throw away attached messages (like Vox and Extropia do) nor throw away the other loops of an inner-encrypted pgp reply block (like Usura and now, lately, unfortunately, also Nately do). Very versatile! I used to like JPUNIX too. Now it seems HOMER(a)RAHUL.NET is a winner, I don't know if he will stay reliable, but he sure is fast. In terms of PGP, he is just as good as HAL/HFINNEY. Likewise, TOWER: Both work! The DESERT remailer is sometimes fast, sometimes slow. I have a feel it waits until it can send out stuff in batches. So sometimes you have to wait a day or so. It works with Anon-To: last I checked, if I recall correctly. That's the extent of my playing around. I would appreciate corrections and help, especially information with some of the remailers I have not mentioned here. I have not played with Q or with FLAME, for instance. |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| .Signature field left blank (or it wouldn't be anonymous, would it?) |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| - --- [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 iQBFAwUBLzUR0CoZzwIn1bdtAQGoHQF/ep/uxpNHaCX4JUoETqULLax8Q0vu6VrY Jh1P/ey2QrWi1TKWky3/SJ967S+xoqg0 =gEZ3 -----END PGP SIGNATURE-----

1 0

BROKEN REMAILERS
by Nobody＠eniac.ac.siue.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Here's a bug report on some remailers that won't work in a nested chain when it is encrypted. First, a look at how a chain is supposed to work. Three good ones, chained like: 1) Tower->Alumni->Homer. OK 2) Homer->Tower->Alumni. OK 3) Homer->Alumni->Tower. OK This was in a test of the new Tower remailer. In other words, it doesn't matter if Tower is at the beginning, middle or end of a chain. The message will reach its intended destination. (In fact, quite fast). But some other remailers fuck up when they become part of a nested, encrypted chain. One of those? The Syrinx remailer. Here are the test results: 1) Syrinx->alumni->Homer. NO 2) Homer->syrinx->alumni. NO 3) Homer->alumni->syrinx. OK The third one came back to be in under an hour. No reply from number 1 and 2. I don't know why it doesn't work but it doesn't! Maybe one explanation is that as Syrinx gets a messages it sees the :: Encrypted: PGP and then decodes it using its key (as it should), but then in the decrypted message it sees another :: Encrypted: PGP and attempts to decode it again using its key (again), fails (of course) and aborts. This to me is the only explanation as to this strange behaviour. It is a serious problem and I do think that it should be brought to the attention of everybody. Now I haven't tested all of the remailers so I don't really know which one also will fail the test. In that test I choose Homer and Alumni because I know that these 2 are reliable and don't care in what order they are in a chain, I also always send the same test message it reads: This is a test line1 line2 line3 line4 Sent <TIME and DATE> to #1->#2->#3 So its easy to do. And when I get a reply I know which one (1, 2 or 3) worked, since the path is in the message. Now I know that syrinx doesn't work. So I add it to my list of those remailers that failed the test. Also on this list are: * Nately and * Usura as they both share the same properties as Syrinx: The chained message gets home ONLY is Syrinx / Usura / Nately is the _last_ link of the chain. (Nately *used* to be as good as Homer, Tower, Hal and Portal, but not anymore. Around Christmas, it changed its performance. Maybe the operator tinkered - don't what what he did, but he made it worse.) Two other remailers failing our tests, but for other reasons, are: * Extropia and * Vox. Neither forwards attached files. In other words, anything outside of the original encrypted block gets sent on. This makes both of them useless for reply blocks, for instance. - -- anon - --- [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 iQBFAwUBLzUSGCoZzwIn1bdtAQH3IgF9FIUMOTd6rsihkaXUCKn4w14qTtOEfjcD sXFPB/62K6NQZCuHTUPBDa30jh2c8sJY =6tBU -----END PGP SIGNATURE-----

1 0

Zimmermann charges dropped?
by tcmay＠netcom.com 17 Dec '03

17 Dec '03

Apologies if this has been discussed and I somehow missed it. I just got back from Monte Carlo last night and have briefly scanned the 500+ accumulated messages, not seeing this item mentioned. Drew Taubman (sp?), the new Executive Director of the EFF, told me that in recent days the grand jury meeting in the PRZ case did in fact decide to go forward with the indictment. However, says Drew, the judge in the case dismissed the charges after looking at them, apparently in about an hour or so. He cited the absence of relevant law in the case (as I understand it, the argument being that there is no law against what PRZ did, i.e., "make code available" in such a way that _others_ might then access it and perhaps then illegally export it (assuming such export might be later proved to be illegal). Drew went on to tell me that the judge said there would need to be a relevant law on this, and that Senator Leahy and his staff (recall their involvement in the Digital Telephony Bill) are already at work drafting such legislation. I haven't seen mention of this, so I thought I'd mention it here. I could of course try to get confirmation first from Phil, but he is notoriously hard to reach in e-mail, ironically, and this seems sufficiently important to mention to the list. And if you can't trust the EFF, who _can_ you trust? (Don't answer that.) --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. Cypherpunks list: majordomo(a)toad.com with body message of only: subscribe cypherpunks. FAQ available at ftp.netcom.com in pub/tc/tcmay

1 1

Re: Zimmermann charges dropped?
by Michael Sattler 17 Dec '03

17 Dec '03

At 12:59 2/5/95, Timothy C. May wrote: >I could of course try to get confirmation first from Phil, but he is >notoriously hard to reach in e-mail... Especially when he (and presumably his attorney Phil Dubois) are on the road, as he is this week. I'm trying to reach PRZ at his hotel to confirm this. -----------------------------------------------------------------------+ Michael Sattler <msattler(a)jungle.com> San Francisco, California | Digital Jungle Consulting Services http://www.jungle.com/msattler/ | | And so these men of Indostan/ disputed long and loud/ each in his own | opinion/ exceeding stiff and strong/ though each was partly right/ and | all were in the wrong! - John Godfrey Saxe |

1 0

Re: BROKEN REMAILERS
by Alex de Joode 17 Dec '03

17 Dec '03

In article <199502051758.MAA02142(a)bb.hks.net> nobody stated: : I have tested remailers and their PGP keys over some time now and this is : what I have found: : USURA is really quick too and has lately been reliable. But it has always : suffered from the same problem as Nately, namely that it will truncate all : of the remaining lines in a PGP message encrypted with its own public key, : this making it impossible to chain effectively. It will read the first : command only. It DOES forward all attached files, however (by which I : mean text that have been tagged on OUTSIDE of the pgp block encrypted : to Usura). I did some testing myself and the format below did work for me: (I encrypt using " pgp -eat ") -> To: remailer(a)xs4all.nl :: Encypted: PGP ----BEGIN PGP MESSAGE---- :: Anon-To: usura(a)replay.com :: Encrypted: PGP ----BEGIN PGP MESSAGE---- :: Anon-To: usura(a)dds.nl test of chained message ----END PGP MESSAGE---- ----END PGP MESSAGE---- THIS IS OUTSIDE THE PGP MESSAGE <- This drops a message in my dds.nl mailbox stating: -> test of chained message THIS IS OUTSIDE THE PGP MESSAGE <- Hope this helps, -- Alex de Joode usura(a)replay.com http://www.xs4all.nl/~usura PARTIE PIEPEL MOEF JOR FIET !!!

1 0