December 2003 - cypherpunks-legacy

Another Request
by lefty＠apple.com 17 Dec '03

17 Dec '03

Can anyone give me a pointer to where I might find information about Kerberos? -- Lefty (lefty(a)apple.com) C:.M:.C:., D:.O:.D:.

2 1

A Request
by lefty＠apple.com 17 Dec '03

17 Dec '03

A few weeks ago, an ad from Microsoft looking for a staff cryptographic expert was posted. If anyone saved a copy, can they please forward it to me? -- Lefty (lefty(a)apple.com) C:.M:.C:., D:.O:.D:.

1 0

REMAIL: ping, script
by Karl Lui Barrus 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I've been catching up on past messages; I see there was some interest in scripts for pinging remailers, and some questions about how many there are, etc. Here is the data file and script I use to ping non-special remailers. Note: remailer #12 will only remail if you attach "digital cash", remailer #20 batches until midnight, remailer #21 requires encryption. Save this as "remailer.data" - ----------8< cut here >8---------- 01:n:remailer@chaos.bsu.edu 02:n:nowhere@bsu-cs.bsu.edu 03:n:hh@cicada.berkeley.edu 04:n:hh@pmantis.berkeley.edu 05:n:hh@soda.berkeley.edu 06:n:00x@uclink.berkeley.edu 07:y:hal@alumni.caltech.edu 08:y:ebrandt@jarthur.claremont.edu 09:y:catalyst@netcom.com 10:y:sameer@netcom.com 11:y:remailer@rebma.mn.org 12:y:elee6ue@rosebud.ee.uh.edu 13:y:elee7h5@rosebud.ee.uh.edu 14:y:hfinney@shell.portal.com 15:y:sameer@soda.berkeley.edu 16:y:remail@tamsun.tamu.edu 17:y:remail@tamaix.tamu.edu 18:y:remailer@utter.dis.org 19:y:remailer@entropy.linet.org 20:y:elee9sf@menudo.uh.edu 21:s:remail@extropia.wimsey.com - ----------8< cut here >8---------- and then the script - ----------8< cut here >8---------- #!/usr/local/bin/perl #ping the anonymous remailers #Karl L. Barrus <klbarrus(a)owlnet.rice.edu> open (IN, "remailer.data") || die "Can't open remailer.data\n"; while (<IN>) { ($num, $rest) = split(/:/, $_, 2); $remailers{$num} = $rest; } close (IN); #ping all remailers except special ones foreach $i (sort keys(%remailers)) { ($mode, $name) = split(/:/, $remailers{$i}); print "remail via $name" if $mode ne "s"; open (MAIL, "| /usr/lib/sendmail " . $name); print MAIL "To: " . $name; print MAIL "From: nobody\n"; print MAIL "Subject: test " . $i . "\n"; print MAIL "Request-Remailing-To: klbarrus(a)owlnet.rice.edu\n"; print MAIL "\ntesting :-)\n"; close (MAIL); sleep 5; } - ----------8< cut here >8---------- -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLU8EUIOA7OpLWtYzAQFbjAQAhMj765Rd7r4BgRkXnRKmSRuJRphyNz/6 3Q7N4v+rQME44ZtiufDkxEyxj/M7s+bMXRqP+2n+gXVSaAgXq/g2CFrVisyvL70P 6RS//XHaoThJHRPp9x0/p9fO2MMeqOct0YXtYWi2C9LlU8B9/smjm7/Qg6q65tgk D3FgR6YAlZI= =bl8B -----END PGP SIGNATURE-----

2 1

fwd: Canadian gov't eavesdropping
by Eli Brandt 17 Dec '03

17 Dec '03

> Date: Tue, 1 Feb 1994 20:21:46 -0500 [...] > HIGH-TECH SNOOP GADGET. A super-secret branch of the Canadian Security > Intelligence Service has awarded three contracts to a Montreal firm to make > equipment that can quickly isolate key words and phrases from millions of > airborne phone, fax, radio signals and other transmissions. The hardware > has the "Orwellian potential to sweep through ... and keep records of all > conversations," said one CSIS critic. (CTV National News, 01/31/94 11:00 > pm). Dunno how feasible this kind of keyword recognition presently is, but here's another reason to encrypt. > EDUPAGE. To subscribe to Edupage send e-mail to listproc(a)educom.edu, > containing the following text: SUB EDUPAGE yourfirstname yourlastname. To Eli ebrandt(a)jarthur.claremont.edu

1 0

Re: 2-way anonymous via SASE
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

Jon Boone writes: > Now, what is this SASE? Apparently it is either a) a > fully-specified return-path (presumably a chain of > anonymous ids at various remailers), b) a next-hop > address (anonymousid at the next remailer that "knows" > where to send the message), or c) some combination of the > previous two. > > Is there another possibility that I have missed? > The SASE's that I've been describing are not type a, b, or c. "b" is closest, except the next-hop address is not an "anonymousid at the next remailer", rather, it is simply the e-mail address of the next remailer to send to. The SASE is structured somewhat like a message enclosed in a bunch of nested digital envelopes. If you don't understand "message enclosed in a bunch of nested digital envelopes" then you will have a hard time understanding SASE's (at least the type of SASE's I'm describing). ** Using Nested Envelopes for sending anonymous e-mail (simplified) ** Say Bob wants to send a message to Ted, routing the message through R1 and R2, and finally to Ted. First of all, Bob needs to know the e-mail address of R1, R2, and Ted. Bob also needs to know the public-key of R1, and R2. He will probably also want to know the public-key of Ted, but that is not required. [Notice that I did *not* say the Bob needed to have an anonymous account id at each of the remailers. There are different types of remailers. Some provide anonymous accounts, others simple forward e-mail. In the description below, I am referring to remailers that just forward e-mail.] To send to Ted, Bob constructs the following: (not considering SASE's yet) R1_PK(R2-addr, R2_PK(Ted-addr, Ted_PK(message))) where: XX_PK(stuff) stuff encrypted with XX's public-key XX-addr e-mail address of XX Bob sends this mess to R1. >From R1's point of view, R1 receives R1_PK(stuff1) R1 decrypts "stuff1" and gets: R2-addr, R2_PK(stuff2) R1, strips off "R2-addr" and e-mails R2_PK(stuff2) to "R2-addr". R2 receives R2_PK(stuff2) R2 decrypts "stuff2" and gets Ted-addr, Ted_PK(message) R2 strips off "Ted-addr" and e-mails Ted_PK(message) to "Ted-addr". Ted receives Ted_PK(message) Ted decrypts it, and gets Bob's message. As you can see, you need to use a special type of remailer to get this to work. Not all remailers support the "decrypt, strip, and re-send" operation. You seem to be familiar with the type of remailer that sets up an anonymizing "account" (e.g. an12345(a)anon.penet.fi) These "Penet-style" remailers give you an easy mechanism for doing 2-way anonymous communication. Ted can use ordinary e-mail commands to send a reply addressed to "an12345(a)anon.penet.fi". The "decrypt, strip, and re-send" remailers do not provide a trivial way to send reply messages. The SASE mechanism is an attempt to extend these types of remailers so Ted can reply to whomever sent him the anonymous message (Ted doesn't know anything about the original sender, not even a anonymous id. Ted only knows that R2 forwarded a message to him). Jim_Miller(a)suite.com

1 0

Re: 2-way anonymous via SASE
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

I finally got around to downloading and reading the remailer stuff from the cypherpunks ftp site*. I could have saved myself some embarrassment if I had read it before posting my "original" SASE idea. The file pub/cypherpunks/remailer/hals.instructions describes a mechanism that is basically a simplified SASE. Oh well... Jim_Miller(a)suite.com --------- *ftp soda.berkeley.edu

1 0

New Remailer Up.
by nobody＠qwerty.org 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Greetings. New remailer: qwerty(a)netcom.com. No logs. Only a "counter" that works by appending the word "R" or "ER" to a text file so I can get an idea if anyone is using it. However, I'm sure the Netcom and other site's mail logs will be enough to track serious abusers of anonymity down, without my help. This remailer is dedicated to honest people who desire PRIVACY. (The extra "-" and "space" characters at the beginning of some lines are an artifact of my signing this with PGP). Accepts standard, :: Request-Remailing-To: address (space) message or standard, :: Encrypted:PGP (blank line) - -----BEGIN PGP MESSAGE----- Version: 2.3 Blah blah blah. - -----END PGP MESSAGE----- (blank line) Optional message here. in which the first two lines of the decrypted message contains, :: Request-Remailing-To: address (blank line) Spelling mistakes will land mail in my mail box where I will emotionlessly delete them. Leaving out the blank lines may cause messages to dissapear. Public key for Qwerty Remailer <qwerty(a)netcom.com>, - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3 mQCNAi1NtgAAAAEEALD07N5RllpklGhOQaiYtRupb+8Jm1M34ya8rxmcNUCVndcb JgH9EW1Z2VvkJ3vTcEOOBK9jM/HCIGDqBbQZR8VOLbLNOD7VQIzTpyTOmZJCMSZG bqZtRtP6KDtMcTx1SgHq9LiRNz5YUyB3WOV963y8W/x00QS4yGkgCDZkVQXZAAUR tCNRd2VydHkgUmVtYWlsZXIgPHF3ZXJ0eUBuZXRjb20uY29tPokAlQIFEC1OzEgE sxus60J9UQEB224D/jUcYRnXmIj9nt4Y7sjGYTmO+v7b9W+rsxYLn6+hCGmx5iQJ zPr3ggvm8ylBZnNp3WUxssDlb9GyiK801vzm6HDXWd/yCeGXHX7YB2DDFd5WrK70 /XGTMGv3gvNnExIM+UVv5tl8y/YXOfeLWWGttD6a60MkUNxAOGT9qBsUTqJNiQCV AgUQLU3TdWkgCDZkVQXZAQH1ygP/TCY7T0PdNVRUVbEpN9YsbxFKhFT/7+hZTySr Md0j2GrObjcRc7aa0c9lEZrtKpaDCJkgF+7k20z1eQpw7zD/dO+ZsSqni62TLGYa pdTsAiYbev90Nb+1S2ST36KvIgJSmQS6zvgpToTRpGwYhJhqTZhTo8Z2U5ufb+SF TsNMd0Q= =BXnK - -----END PGP PUBLIC KEY BLOCK----- See the PGP FAQ for how to use encrypted remailers. Send mail to na38138(a)anon.penet.fi with subject "Bomb me!" for Gary Edstrom's PGP FAQ and my "Here's How to MacPGP!" guide. That's NA (not AN), thirty-eight, one-thirty-eight. Thanks to Hal Finney for sending me updated perl scripts and a working copy of UNIX PGP2.3a. I am looking into ViaCrypt UNIX PGP 2.4 as well. Send mail regarding the remailer to qwerty(a)netcom.com. -Xenon -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLU77FgSzG6zrQn1RAQHlvgQAj2S4bYB+5dEDubfzk8etdBOSbehxfF/o B8ycAHgbHjs0SI9HEb0Xm9RJP+ZLtFfD8J7KgOWe0cJlWdy8NKwJxh55Uqn6yiQn IHB2M9x51nXD3ySCIH8f2USXuHYj8qiInzvQwP6naNiC0vU9E+4ab02Th+IbC8zL n9Jthe+vTf8= =MEvY -----END PGP SIGNATURE-----

3 2

SuperPing1.2
by nobody＠qwerty.org 17 Dec '03

17 Dec '03

This may not be elegant, but it works well in my account. It checks the entire Cypherpunk remailer network connections and is user friendly. -Xenon #!/usr/bin/perl # Change this to reflect where your system has perl. # SuperPing version 1.2: Ping Cyperpunk remailer connections. # Now pings in both directions, as I have learned they are NOT equivalent. # Brought to you by Xenon <na38138(a)anon.penet.fi>. # Thanks to Alan Barrett for teaching me some perl. # Warning: outputs ~40 e-mails at a time. May give "too many processes" # error towards the end if you haven't killed all of your stopped jobs. # Increase the sleep(sec) time if needed. # Be careful. If mail bounces between any two remailers in either # direction, "Mr. Remailer Operator" will obtain a full mailbox! # To test the program, comment out all the remailers in the list and add # YOUR address at least three times to the list of "remailers". # You MUST make a file called .PingFile that contains: #:: #Request-Remailing-To: your.address # #Ping! # #-----Begin Test----- #Test #-----End Test----- # Will also function as a convenient method to shut down all remailers at # once by making .PingFile 500K instead of 1K. Not recommended if you # value your life ;-). # List of remailers (not complete). Make any line a comment to remove that # line's remailer. cicada and pmantis are not meant for heavy traffic so I # have removed them. Soda is commented for no particular reason. @Rm = ( "catalyst(a)netcom.com", "remailer(a)dis.org", "ebrandt(a)jarthur.claremont.edu", "remailer(a)merde.dis.org", "qwerty(a)netcom.com", "elee7h5(a)rosebud.ee.uh.edu", "hfinney(a)shell.portal.com", #"hh(a)soda.berkeley.edu", ); #Nicknames for output and subject lines. @Nick = ( "catalyst", "dis.org", "jarthur", "merde", "qwerty", "rosebud", "shell", #"soda", ); # Select a marking character for this SuperPing session. @Mark = ("A","B","C","D","E","F","G","H","I","J","K","L","M","N","O", "P","Q","R","S","T","U","V","W","X","Y","Z"); srand(time); $M = $Mark[rand(26)]; # Strings, since lines got too long below. # Obviously this could be written better using sendmail but I'm writing # perl code without KNOWING any perl. $A = "(echo \"::\" ; echo \"Request-Remailing-To: "; $B = " ; echo \"\" ; cat .PingFile) | mail -s \"$M."; # Send a "Ping!" between all combinations of two remailers, in both # directions. $Num is a count that ends up in the Subject line. Each number # is used twice, with a < and > telling which direction the mail went. Change # "system" to "print" to see the Unix commands being produced. foreach $Sec (0..$#Rm) { foreach $First ($Sec+1..$#Rm) { $Num++ ; $C = " $Nick[$First] > $Nick[$Sec]\" " ; system "$A$Rm[$Sec]\"$B$Num$C$Rm[$First]"; print "$M.$Num $Nick[$First] > $Nick[$Sec]\n"; sleep(1) ; $C = " $Nick[$First] < $Nick[$Sec]\" " ; system "$A$Rm[$First]\"$B$Num$C$Rm[$Sec]"; print "$M.$Num $Nick[$First] < $Nick[$Sec]\n"; sleep(1) ; } } # Output (with only catalyst, qwerty and rosebud checked) looks like this: # S.1 qwerty > catalyst # S.1 qwerty < catalyst # S.2 rosebud > catalyst # S.2 rosebud < catalyst # S.3 rosebud > qwerty # S.3 rosebud < qwerty # These are printed out as the program progresses and they also appear as # the Subject of each piece of mail. # alias g '(grep Subject: /usr/spool/mail/n/name | sort -t. +1 -n) | more' # will make the command "g" give a list of received pings, in order. /n/name # is your part of the mail spool. You should also check that the received # pings really came from the second remailer instead of getting short # circuited by the first remailer. # Sample output mail as received by a remailer: # #From: Your name <your.address> #Message-Id: <numbers(a)your.site> #To: qwerty(a)netcom.com #Subject: S.1 qwerty > catalyst #Status: R # #:: #Request-Remailing-To: catalyst(a)netcom.com # #:: #Request-Remailing-To: your.address # #Ping! # #-----Begin Test----- #Test #-----End Test-----

1 0

NxM DES
by ritter＠cactus.org 17 Dec '03

17 Dec '03

Ritter Software Engineering 2609 Choctaw Trail Austin, Texas 78745 (512) 892-0494, ritter(a)cactus.org Strong Block Ciphers from Weak Ones: NxM DES A New Class of DES Operating Modes Terry Ritter January 31, 1994 Introduction Many security vendors are now preparing a new generation of software and hardware products. Given the well-known criticism of DES, and the government's unwillingness to publish their new Skipjack algorithm, much attention has been focused on triple-DES as a replacement for DES. But triple-DES requires three times the processing of normal DES, and retains the same small block size which must be increasingly vulnerable to improved dictionary attacks. Thus it is reasonable to seek alternatives to triple-DES, and compare them with respect to keyspace, processing requirements, and block size. Vendors should be cautioned that triple-DES is not the only, nor necessarily the best, alternative to DES. They should consider delaying implementation of alternatives until a consensus develops on exactly what the replacement should be. New ciphering algorithms are often challenged to "prove" they are stronger than DES. Since it is impossible to measure the "strength" of a cipher (and there has been no absolute proof of strength for any practical cipher), new cipher algorithms are often considered curiosities. On the other hand, DES itself is well-known and accepted (despite having no proof of strength), so there seems to be great interest in the possibility of forming from DES a stronger cipher. Triple-DES is one approach at forming that stronger cipher, and is what we could call a 1x3 DES structure: one DES block wide by three DES cipherings deep. Naturally, we expect software for any three-level ciphering to operate at about one-third the speed of normal DES. There is an alternative approach which offers a larger keyspace, reduced processing, and larger block sizes (which, nevertheless, can often be used without data-expansion beyond that of normal DES). I call that approach "NxM DES," of which 2x2 DES is perhaps the easiest nontrivial example: 2x2 DES Instead of repeatedly enciphering a single 8-byte block, consider using multiple DES cipherings to form a 16-byte block operation and thereby improve plaintext block statistics. 2x2 DES will be two DES blocks wide by two DES cipherings deep. First, encipher two data blocks with DES, each under a different key. Exchange half the data in the first and second blocks. Then encipher the resulting blocks again, using two more keys: Let us denote a DES enciphering by: ciphertext := DESe( plaintext, key ) . We want to encipher two DES-size blocks, call them A and B, and end up with ciphertext blocks G and H: C := DESe( A, k1 ); D := DESe( B, k2 ); E := C[0..3],D[4..7]; F := D[0..3],C[4..7]; G := DESe( E, k3 ); H := DESe( F, k4 ); The byte-index notation on the second line is intended to convey the exchange of the rightmost four bytes of the first two DES ciphertexts. The exchange is a permutation, costless in hardware, and simple and cheap in software. This particular permutation is also a self-inverse, so that the same permutation can be used for both enciphering and deciphering. If we give each two-bytes of data a symbol and denote the original data as: 0123 4567 then after the permutation we have: 0167 4523 . For example, A: 01A1D6D039776742 B: 5CD54CA83DEF57DA k1: 7CA110454A1A6E57 k2: 0131D9619DC1376E C: 690F5B0D9A26939B D: 7A389D10354BD271 E: 690f5b0d354bd271 F: 7a389d109a26939b k3: 07A1133E4A0B2686 k4: 3849674C2602319E G: b4de11d10c55c267 H: 64f1a0b723d360a7 . Deciphering is similar to enciphering, except that the last-stage keys are used first, and we use DES deciphering instead of enciphering: E := DESd( G, k3 ); F := DESd( H, k4 ); C := E[0..3],F[4..7]; D := E[0..3],F[4..7]; A := DESd( C, k1 ); B := DESd( D, k2 ); Thus, 2x2 DES enciphers DES blocks A and B to DES blocks G and H in four DES cipherings. This is faster than triple DES, because twice as much data are enciphered in each block: 2x2 DES has a cost similar to double-DES. But 2x2 DES is potentially stronger than triple-DES, because each of the resulting ciphertext bits is a function of 128 plaintext bits (instead of 64), as well as three DES keys. (Although four keys are used in 2x2 DES, only three keys affect each output block, a 168-bit keyspace.) 2x2 DES does have a larger block size, so, when used alone, last-block padding overhead increases from four bytes (on average) to eight; a four-byte data expansion. Naturally, when used alone in CBC mode, the initialization vector (IV) will also be larger, 16 bytes instead of 8. This 12-byte overall increase in overhead should be weighed against the stronger 16-byte block size, since strength is the reason for moving away from normal DES in the first place. 4x2 DES In a manner similar to 2x2 DES, we can consider enciphering four DES blocks of plaintext, sharing data between them, and then enciphering the resulting four blocks again. 4x2 DES has a larger keyspace than 2x2 DES, yet retains the same ciphering cost. 4x2 DES does have some additional last-block and IV overhead, in return for a greater keyspace and larger block-size strength. Each 4x2 ciphering requires eight DES keys: E[0..7] := DESe( A, k1 ); F[0..7] := DESe( B, k2 ); G[0..7] := DESe( C, k3 ); H[0..7] := DESe( D, k4 ); (swap right-hand half of the data in {E,F} and {G,H}) I := E[0..3],F[4..7] J := F[0..3],E[4..7] K := G[0..3],H[4..7] L := H[0..3],G[4..7] (swap the middle half of the data in {I,L} and {J,K}) M := I[0..1],L[2..5],I[6..7] N := J[0..1],K[2..5],J[6..7] O := K[0..1],J[2..5],K[6..7] P := L[0..1],I[2..5],L[6..7] Q := DESe( M, k5 ); R := DESe( N, k6 ); S := DESe( O, k7 ); T := DESe( P, k8 ); The intermediate permutation involves four 32-bit exchange operations, an expense still trivial compared to the DES ciphering operations. (In a hardware implementation, the byte-swaps are the connections always needed between stages, just connected differently, with no added expense at all.) This permutation is also a self-inverse. If we denote each two-bytes of the data symbolically: 0123 4567 89ab cdef then after the permutation, we have: 0da7 49e3 852f c16b . Alternately, if we denote the data prior to permutation as: 0000 1111 2222 3333 then after the permutation we have: 0321 1230 2103 3012 , showing that each permuted block contains exactly two bytes from each of the four original DES blocks. Each 8-byte output block in 4x2 DES is a function of 32 bytes of input plaintext, as well as five DES keys, a 280-bit keyspace. For example, A: 01A1D6D039776742 B: 5CD54CA83DEF57DA C: 0248D43806F67172 D: 51454B582DDF440A k1: 7CA110454A1A6E57 k2: 0131D9619DC1376E k3: 07A1133E4A0B2686 k4: 3849674C2602319E E: 690F5B0D9A26939B F: 7A389D10354BD271 G: 868EBB51CAB4599A H: 7178876E01F19B2A M: 690f876ecab4d271 N: 7a38bb5101f1939b O: 868e9d109a269b2a P: 71785b0d354b599a k5: 04B915BA43FEB5B6 k6: 0113B970FD34F2CE k7: 0170F175468FB5E6 k8: 43297FAD38E373FE Q: 89af722f592664c4 R: 012d483a04db300f S: dd60060ad098e3e0 T: a3832dc4ff5c99ad . Again, 4x2 DES deciphering is similar, except that we use the last- stage keys first, and DES deciphering instead of enciphering. NxM DES 8x2 DES would have a 64-byte block and 16 DES keys, yet should still be considerably faster than triple-DES. Even larger blocks are possible, but would seem to require exchange operations on non-byte boundaries (to assure that each permuted block contains bits from each stage-one ciphertext block), so 16x2 DES and larger structures may have a larger software permutation cost. Nevertheless, the Nx2 approach gives us a way to increase the keyspace while generally retaining processing costs similar to double-DES. DES structures with additional ciphering levels, such as 2x3 DES or 4x3 DES, are also available, at a processing cost similar to triple- DES, but with the increased strength of a larger block size. A 2x3 DES structure would have a 280-bit keyspace similar to 4x2 DES, but with 50 percent higher processing costs. A 4x3 DES structure could be appropriate for some applications, but would have a huge 504-bit keyspace which would require us to create, transport and store the associated 84-byte key set. Large Blocks in Existing Systems It should be possible to adapt many existing systems to use larger blocks without further data expansion. Consider an 82-byte message, which would normally be structured as eleven 8-byte DES blocks, for a total of 88 bytes: An NxM DES alternative might use two 4x2 DES blocks, one 2x2 DES block, and one 1x3 DES block, for 32+32+16+8 or 88 bytes, exactly the same as normal DES. A 63-byte message (normally 8 DES blocks) would use just two 4x2 DES blocks for a total of 64 bytes, also the same as normal DES. If larger blocks are always used until smaller blocks would be more efficient, there is exactly one way to structure any given amount of data, and the resulting length is sufficient to reproduce the multiple-size blocking structure. The overhead of these blocking manipulations remains insignificant when compared to the DES ciphering operations. We could call this sort of use of multi-size blocking "NxM+ DES," and 4x2+2x2+1x3 DES (which we could call "4x2+ DES") would seem to be a very practical system. Clearly, in CBC mode, 4x2 DES will require a larger IV than normal DES. Perhaps the IV could be transferred as part of the key-exchange; there is obviously no way to avoid using larger keys if we want a stronger cipher, whatever approach we use. Smaller blocks at the end of a data area could just take the left-most part of the preceding block as their chain value. Similarly, a 2x2 DES block might use the left-most two DES keys at both levels of a 4x2 DES block (k1,k2,k5,k6), while a 1x3 DES block might just use the first three keys of the 2x2 DES block. Overall, 4x2+ DES might be a simple firmware upgrade for existing DES hardware. Summary Because the DES cipher is well known, there is interest in creating a stronger cipher which builds on normal DES as a base. By introducing a larger block width in addition to repeated cipherings, additional complexity can be obtained with a moderate increase in processing. This approach is unusual in that various levels of strength can be obtained at virtually the same processing cost, a cost comparable to double-DES and substantially less than triple-DES. Furthermore, the larger data blocks can be used even in systems which would not support data expansion beyond that inherent in normal DES. Consequently, the NxM DES approach would seem to have significant practical advantages over either double-DES or triple-DES as a replacement for DES. NxM DES is a product of my own research. I am not aware that this approach has been previously published.

1 0

Anonymous mail service up for alpha testing
by Sameer 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I've written a small anonymous mail service, and it's now available for testing. There's no security, and I'll be keeping logs, so don't think that it's secure, in any way. It's also running on a PPP link which isn't connected all the time, so it's rather flaky. (I'll set it up as a real service once I get a real link-- if anyone else wants to do it, they're welcome to use my code.) How to get an anonymous account: Send mail to admin(a)infinity.hip.berkeley.edu -- include in the message a login, a "Full Name", a choice of remailer, and an encrypted return address block encrypted with that remailer's public key. I'll set it up. How the anonymous account works: Someone will send mail to login(a)infinity.hip.berkeley.edu. Then the system looks up in a table which remailer is associated with that login. It then sends out mail to that remailer, starting with the contents of the encrypted return address block, then a "##" and then all of the message to login@infinity, with "Received" lines taken out. Thus once the message gets to the last remailer of the chain in the encrypted return block, the ## pasts the identifying information of the person mailing to login(a)infinity.hip in the header of the message. (It *should* do that...) If the person mailing to the infinity address would like anonymity he/she should use an anon-mailer on his/her end. The encrypted-return address you send me should look like: :: Encrypted: PGP - -----BEGIN PGP MESSAGE----- etc. Make sure you include that ::/Encrypted or the remailer which gets it won't know that it's PGP encrypted. Remember, this is just setup for testing. Don't use it for real applications. - -Sameer -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLU9jrni7eNFdXppdAQH/FwP/b9pllDYnW6L4x0y1dVnC6km9TQ9lTw2x U/ea87JnguYSHYRxOk6lZoBBx5ZH/A48OCHJztzWHaSP2Tq69Oro4FTrtRcpTjbf ti8L97x9+Xvx1A6/Vkw1nuS5MRJ8SoPUV4bDKFdf80Ykhik5bk8b0WOUew1uF6dq QJzyDsKDFQU= =2EIr -----END PGP SIGNATURE-----

3 2

Re: New Remailer Up.
by qwerty＠netcom.com 17 Dec '03

17 Dec '03

...and, to mail to an anon.penet.fi address, you must change the an1234 to na1234 (not anonymous), for I have a password/anon.penet.fi address for this account but I don't wish to either 1) give it out so anyone could then change it, or 2) have Julf remove it, so anyone could remail to anon.penet.fi but a few could also forge mail from qwerty to set a password. -Xenon

1 0

Re: Remailer Tearline Conventins
by edgar＠spectrx.saigon.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Someone (not me) asked about remailer tearline conventions to eliminate automatic sigs: Though this subject came up some months ago, I never noticed any final decision. Is there now an accepted tearline convention for the generic cypherpunks remailers? The mail handler here and at most of my other accounts automagically adds the host address and/or my address to all outgoing mail, which is...well..._counterproductive_ when sending mail to a remailer. The extropia remailer by accepting encrypted messages avoids this problem, but most of the other remailers seem to have no provisions for excluding extraneous text and address footers. Was there ever a "8<----(cut here)" arrangement agreed upon and incorporated into the remailers? I'm the one who brought this up "months ago" and the short answer to your question is "no." One remailer Hall Remailer <nowhere(a)bsu-cs.bsu.edu> added a "cut line" of --ignore-- [no indentation in actual use]. I tested this when Hall first announced it and it seems to work. You would be advised to test it yourself before relying on it. Unfortunately the Hall Remailer is one of the remailers that does not support encryption. AFIK, this "cut line" code was never propagated to any other Cypherpunks remailers. At the time I brought this up, the attitude of most remailer operators (Chael Hall and Miron Cuperman notably excepted) was that anyone who couldn't figure out how and remember to turn off their auto sig didn't deserve any privacy. I recommend that you always use the wimsey (extropia) remailer as the first (or only) leg of a remailer chain. It is also the only Cypherpunks remailer outside the USA (it's in Canada) which will make tracing msgs a little more difficult for USA authorities. -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLU5FJt4nNf3ah8DHAQECYQP/f2LDs7Tq1PfrH4PQBOR0Iu1XIrCDztZB dVapPFSjfF2Y20ljWqHsMK7xjUpfLpaXluFogav9DpGgey/zrO48MJJf8gFBGsJA 7gsOUl3Yc3VDPWvWI18zN4MgYeeEfRoTXIToWSeiadJmiEMq5m0hqs1bjZwOmmSr rewqGMxMUeI= =U43w -----END PGP SIGNATURE----- -- edgar(a)spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Cupertino, Ca

1 0

Re: SuperPing1.2
by nobody＠qwerty.org 17 Dec '03

17 Dec '03

If it wasn't obvious, SuperPing is the sort of utility that only needs to be run say once a day by ONE person out there. Since I did it today, and I haven't reported any down links, you can be rest assured the network is fully connected, at least the remailers listed in the code. -Xenon

1 0

Re: Remailer Tearline ConventiOns.
by nobody＠qwerty.org 17 Dec '03

17 Dec '03

Edgar wrote, "I recommend that you always use the wimsey (extropia) remailer as the first (or only) leg of a remailer chain." I'm not too familiar with extropia these days. Does it have a direct internet connection? What is its characteristics? I'm trying to make up a more useful list of remailers, with details, since different users do have different needs for remailers. Thanks. -Xenon

1 0

WWW Anonymous Remailer Software release
by nate＠VIS.ColoState.EDU 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I have modified my WWW Anonymous remailer interface and put it up for ftp on vangogh.vis.colostate.edu in /pub/nate/remailer There is a README in there which should explain how to set it up, but if I missed anything, please tell me. The remailer no longer needs you to tell it that you're using the remailers, it just knows. Hope you like it, - -nate - -- +-----------------------------------------------------------------------+ | Nate Sammons <nate(a)VIS.ColoState.Edu> <nate(a)yuma.ANCS.ColoState.Edu> | | Colorado State University Computer Visualization Laboratory | | Data Visualization/Interrogation, Modeling, Animation, Rendering | +-----------------------------------------------------------------------+

1 0

On return addresses
by hughes＠ah.com 17 Dec '03

17 Dec '03

I've been troubled for many months by an invariant in all forms of return address schemes: The outside world contains sufficient _persistent_ information to find a real adress. There are lots of clever schemes to split this information up so as to require reassembly between many parties, but the information is still out of one's control. (I use 'reassembly' rather than 'collusion' since the latter indicates an intent; see my rant of a few days ago.) The fundamental problem seems impenetrable. So how do we solve it? By abandoning return addresses and using mail spool facilities. Consider the following service. 1. I have a machine and I'll sell you an address on it, say "onyma(a)privacy.net". This address is _not_ an account, merely an address. Your mail is password or public key protected. 2. When mail come in for you, it sits in a spool. This service comes with a spool of a certain size and an allowance for checking your mail at a certain rate, with overages at extra cost for both. (This is to bound known promised capacity of the machine by a sufficient amount of money to pay for it.) 3. Your mail sits in the spool until you access it with, say, a POP client like Eudora. Just point the client at a different address to pick up mail. The server can further support a number of protocols for getting the mail, including a mail server command of "send me a mailbox file of my waiting mail". The main advantage is that the only _persistent_ information out in the world is the address itself and the authenticator (password or public key). The address is already public and the authenticator is arbitrary, so no identity information is persistent. A complete chain could still be forged between sender and receiving pseudonym, but we now have some amount of forward secrecy. If in fact an intermediate link does discard connection information, it is gone forever. With any kind of SASE, however, the information therein, however encrypted, still contains a full path back. Now consider two ways of getting your mail out of this service, supposing you don't trust the service with your identity. A IP redirector can be with POP service to conceal origin from the mail service. An IP redirector is a remailer for packets, with a bidirectional link set up when the service starts and removed when it goes away. Matt Blaze has a name for this--'packet laundry'--which is a wonderful but politically unfortunate term. The IP redirectors can be chained just like remailers. With a mail server, the command to 'send me my mailbox' can be sent to a remailer address with an encrypted remailing block prepended. In this case, however, the encrypted remailer block is provided with the mail command that requests the mailbox and it is not by design stored persistently. (By design. It could, of course, actually be stored.) The address on the other side of the first remailer hop could be another mail spooing service, in addition. The elimination of persistent identifying information for return paths is a worthwhile design objective. I propose that we start thinking about it more thoroughly. Eric

1 0

Archiving on Inet
by Jim choate 17 Dec '03

17 Dec '03

I would like to ask all subscribers who are not addressing the issues of this question to please move their responces to private mail. I have no interest in exploring your personalities or views of others personalities. If a global network is to survive there must be a commen understanding of what is public domain and what is private or commercial. At the present time this is completely new ground. The fact is that the copyright laws of the US are of little interest to a net user in Moscow, Russia or Pretoria, S. Africa. If as a cpunk you don't feel that a anonymous regulatory agency can protect your privacy why do you feel they can protect your intellectual property? The issue has direct bearing on both intellectual property and the wide spread use of cryptographic techniques. As a active cpunk it seems to me that your first motivation after producing the actual code is to creat a atmosphere where it can be used for the betterment of all. To create a useable global community (what I am striving for) it seems to me that entries on that network must be public domain by default. Otherwise every country who joins, and by reduction every potential user, will have to agree on how to recompense each and every user who desires to be paid for their submissions. This, to me, leads incontrovertibly to the conclusion of a beurocratic nightmare that will not significanly assist anyone other than the regulatory agencies. The only other answer that seems even close to working (and I consider this a stretch of the imagination) is one where everyone is given access for free and the governments regulate the traffic completely and pat for it with tax dollars. As to the issue as it applies to community bbs'es. I run such a system and am in the process of getting it on the net. As part of this project I have 2 other systems that I will be providing feeds for. These systems are all run by individuals who have these boxes sitting in their den. By insisting on a priori copyright of all material it is my opinion that you are creating a situation which will prevent the growth of such systems. Now if we don't have regulatory agencies and the sites are indipendant (and I assume self supporting) how can we expect some Joe or Jill to put up a system to help the people in their neighborhood if they have to keep looking over thier shoulders for the copyright police? The answer is they won't put up such systems and we all loose. By providing strong crypto tools for business and individuals to protect their intellectual and commercial property we are creating an open door atmosphere which motivates people to join the network for their own enjoyment and edification. This to me is more important than keeping the present view (as applied to non-networked environments) of copyright. It is time that we as uses of Internet set a precedence before the legislators set one for us that will in the long run only assist those already in power by strangthening the need for regulatory agencies. I strongly suggest that you all consider this idea from the global and long term view. I think you will find that the view "information wants to be free' is the way to go. To this end I propose that organizations such as EFF and cpunks take the position of a priori public domain status of network submissions. Also that all individuals who wish to retain intellectual or commercial rights either use strong crypto w/ e-mail distribution of keys or a change be implimented in message headers such that sites who don't wish to carry such material can filter it, along with this should be a requirement that any such non- crptographicly secure material must contain a fair use policy at the beginning of each and every document. It is time we quite letting big brother tell us what we can do with our ideas and how to distribute them.

1 0

Re: New Remailer Up.
by nobody＠qwerty.org 17 Dec '03

17 Dec '03

Jon Boone wrote, " Is the sendmail (I assume you are using sendmail for SMTP services) daemon set up so that it *doesn't* log to /usr/spool/mqueue/syslog [or any other syslog facility]? Otherwise, it may well be possible to track the usage of the remailer through browsing the syslog logs. This is one of the problems (it seems to me) with using a remailer and *not* having root access. Unless you can convince your sysadmin to remove the syslog mechanism that sendmail uses, you may be exposing your users (presumably by accident)." No, fortunately for other users, I do not have root access on Netcom ;-). So who is going to be doing this browsing? Other Netcom users can't read the mqueue: qwerty: cd /usr/spool qwerty: ls cron lpd.lock news news4 uucp locks mail news2 rwho uucppublic lpd mqueue news3 secretmail uumaps qwerty: cd mqueue mqueue: Permission denied qwerty: ls -la total 480 drwxr-sr-x 15 bin 512 Feb 2 01:38 . drwxr-xr-x 13 root 512 Feb 2 01:38 .. drwxr-sr-x 4 root 512 Feb 2 01:38 cron drwxr-sr-x 2 uucp 512 Feb 2 08:30 locks drwxrwsr-x 2 daemon 512 Feb 2 03:47 lpd -rw-r--r-- 1 root 4 Feb 2 01:38 lpd.lock drwxrwsrwt 4 root 430080 Feb 2 08:37 mail drwxr-s--- 2 root 18944 Feb 2 08:37 mqueue drwxr-xr-x284 netnews 12288 Feb 2 05:29 news drwxr-sr-x 2 netnews 512 Aug 28 17:03 news2 drwxr-sr-x 2 netnews 512 Aug 28 17:03 news3 drwxr-sr-x 2 netnews 512 Jan 16 19:56 news4 drwxr-sr-x 2 root 512 Jan 31 14:40 rwho drwxrwsrwx 2 bin 512 Nov 3 08:49 secretmail drwxr-sr-x 11 uucp 512 Feb 2 01:38 uucp lrwxrwxrwx 1 root 20 Nov 26 15:48 uucppublic -> /usr/hack/uucppublic drwxrwxr-x 5 netnews 12288 Feb 2 05:48 uumaps "Is the sendmail (I assume you are using sendmail for SMTP services) daemon set up so that it *doesn't* log to /usr/spool/mqueue/syslog [or any other syslog facility]? Otherwise, it may well be possible to track the usage of the remailer through browsing the syslog logs." I'm using Hal's remailer, so ask him the details of what I have running. How many of those private sites with remailers having root, keep NO personal logs? Any? I would like to compile a more detailed listing of the details about each remailer's capabilities, situation, and policy statements. If someone sends anonymous mail through my mailer victimizing someone in a criminal manner, and law enforcement convinces Netcom to check the logs, then more power to them. If someone sends mail discussing large doses of vitamin C, when vitamin supplementys are banned a year from now, and the FDA wants to arrest them, and Netcom allows them to see the mqueue then that would be unfortunate indeed. I am running a remailer. Here is the situation. What more can I offer? I would ask people to look at the various remailers and ask in a street smart practical manner what the pros and cons of each one is. What, exactly, does the mqueue record? How long does it get saved? I needed remailers to maintain some simple privacy by distancing myself from the character Xenon. No 5AM fone calls and letters from people asking me to send them PGP.... I figured if I was going to become the largest volume user of the remailers, I should become a remailer myself. The other option was to use the Netcom account to directly mail out what I am sending to people, but that wasn't as fun of an idea. -Xenon

2 1

RE: fwd: Canadian gov't eavesdropping
by Mike Markley 17 Dec '03

17 Dec '03

| From: Eli Brandt <netmail!ebrandt(a)jarthur.Claremont.EDU> | To: cypherpunks list <cypherpunks(a)toad.com> | Subject: fwd: Canadian gov't eavesdropping | Date: Tuesday, February 01, 1994 7:26PM | | Received: from relay2.UU.NET by netmail.microsoft.com with SMTP (5.65/25-eef) | id AA07450; Tue, 1 Feb 94 19:59:09 -0800 | Received: from toad.com by relay2.UU.NET with SMTP | (5.61/UUNET-internet-primary) id AAwbln22133; Tue, 1 Feb 94 22:55:33 -0500 | Received: by toad.com id AA05602; Tue, 1 Feb 94 19:30:49 PST | Received: by toad.com id AA05533; Tue, 1 Feb 94 19:26:28 PST | Return-Path: <ebrandt(a)jarthur.Claremont.EDU> | Received: from jarthur.Claremont.EDU ([134.173.42.1]) by | toad.com id AA05527; Tue, 1 Feb 94 19:26:21 PST | Message-Id: <9402020326.AA05527(a)toad.com> | In-Reply-To: <94Feb1.201622est.83288(2)(a)ivory.educom.edu>; | from "E-D-U-P-A-G-E" at Feb 1, 94 8:21 pm | X-Arcane-Subliminal-Header: fooquayleglorkpsilocybinrkbapinkyogsothothquux | X-Mailer: ELM [version 2.3 PL11] | | > Date: Tue, 1 Feb 1994 20:21:46 -0500 | [...] | > HIGH-TECH SNOOP GADGET. A super-secret branch of the Canadian Security | > Intelligence Service has awarded three contracts to a Montreal firm to make | > equipment that can quickly isolate key words and phrases from millions of | > airborne phone, fax, radio signals and other transmissions. The hardware | > has the "Orwellian potential to sweep through ... and keep records of all | > conversations," said one CSIS critic. (CTV National News, 01/31/94 11:00 | > pm). | | Dunno how feasible this kind of keyword recognition presently is, | but here's another reason to encrypt. I'd be curious to see how they are going to do voice recognition on random conversations. Unless I am very sadly out of date you need to teach the pattern matcher individual voices. | | > EDUPAGE. To subscribe to Edupage send e-mail to listproc(a)educom.edu, | > containing the following text: SUB EDUPAGE yourfirstname yourlastname. To | | Eli ebrandt(a)jarthur.claremont.edu | | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Mike Markley || The opinions here do not represent the mmarkley(a)microsoft.com || opinions of my employer. Attempts to || associate the two are pointless. "I want to look at life, In the available light" - Neil Peart -

4 3

remailers
by werner＠mc.ab.com 17 Dec '03

17 Dec '03

Hi, Can a remailer be used to post to an arbitrary Usenet group? Is the above a stupid question?

1 0

Re: remailers
by nobody＠qwerty.org 17 Dec '03

17 Dec '03

werner asked, "Can a remailer be used to post to an arbitrary Usenet group?" newsgroup(a)news.cs.indiana.edu posts things quickly via e-mail. When I use anon.penet.fi for Usenet, I often use this, since it is quite a bit faster than using anon.penet.fi's posting feature. "Is the above a stupid question?" Is this a stupid answer? Both are in various FAQs. -Xenon

1 0

system logging
by pgpkeys＠wasabi.io.com 17 Dec '03

17 Dec '03

> Greetings. > > New remailer: qwerty(a)netcom.com. > > No logs. Only a "counter" that works by appending the word "R" or "ER" to a > text file so I can get an idea if anyone is using it. However, I'm sure the > Netcom and other site's mail logs will be enough to track serious abusers > of anonymity down, without my help. This remailer is dedicated to honest > people who desire PRIVACY. People should be aware that whether Niko makes personal logs on his qwerty account or not, the public logs on netcom show more than enough info to trivially track people down. By the way it's very bad practice to forge From: lines, especially with completely non-existant site names like qwerty.org...perhaps you should ask netcom to register it for you. Or if they charge real money for it, your postmaster at columbia.edu might do it for free if you asked him nicely.

1 0

Re: fwd Canadian gov't eavesdropping
by nobody＠qwerty.org 17 Dec '03

17 Dec '03

Mike Markley say, "I'd be curious to see how they are going to do voice recognition on random conversations. Unless I am very sadly out of date you need to teach the pattern matcher individual voices." But of course they will just collect voice samples from everyone soon, and use them to IDENTIFY you. It'll probably be put on our US national health care cards. Ever since I started worrying about leaving DNA on postage stamps, I've started to think what can be done will be done. -Xenon

1 0

Josh Quittner's Newsday column on Cypherpunks
by gnu 17 Dec '03

17 Dec '03

Date: Wed, 02 Feb 1994 10:41:42 est From: "josh quittner" <quit(a)newsday.com> To: gnu(a)cygnus.com Subject: newsday column Hiya John: Here's the little column I did for my newspaper on the cypherpunks meeting I sat in on last month. Thought you might be interested. I know it's laymanlike, but if you want, you have my permission to distribute it to your list. I told Eric I'd send him a copy, but I left his email address at home, so if you'd be good enough, would you either pass this on to him or email me his address so I can? Thanks. Hope all is well with you. Be glad you're not freezing your ass off back here. Regards, -jq PUBLICATION DATE Tuesday. February 1, 1994 EDITION NASSAU AND SUFFOLK SECTION DISCOVERY PAGE 53 OTHER EDITIONS 59 C HEADLINE Life In Cyberspace COMPUTERS IN THE ^90s Coding Up a Bit of Privacy BYLINE Joshua Quittner DATELINE MOUNTAIN VIEW, Calif. LENGTH 91 Lines MOUNTAIN VIEW, Calif. THIS MUST BE HOW the Founding Fathers looked when they hacked out the Constitution: A roomful of young men, mostly - frazzled hair, eager eyes, wild beards, arms flailing and fingers jabbing the air, reaching for big ideas. You can't help but feel it; urgency tempers their voices. The earnest men plan and argue in this corporate conference room as the last sun rays of a winter Saturday afternoon fade in through a skylight. Time is running out for the Cypherpunks. There is much work to be done before the information highway arrives. The information highway - that 500-channel shopping mall / cineplex championed by cable and telephone companies - is a noxious concept to the people in this room. They are not technophobes or Luddites, these Cypherpunks. Instead, they are a collection of clever computer programers, engineers and wire heads from some of the nation's best-known Silicon Valley software houses and hardware shops. This is their central question: In a future world where all information is centralized on a network, where all information is tracked by the bit, where every purchase you make and every communication can be monitored by corporate America, how does privacy survive? If you go to a bookstore now and buy a book, you can pay in cash. No one knows your name or what you purchased. "What happens to cash transactions on the information highway?" they ask. The Cypherpunks believe that they can preserve your privacy through good cyphers, or codes. But they must hurry, must get their codes out and their networks up and running. "The whole information highway thing is now part of the public eye," explains Eric Hughes, a founder of the Cypherpunk movement. "If we don't change it now, it'll be impossible later." The Cypherpunks know what technology is capable of. We visit them today because they represent one edge of the national debate on the structure of the information highway. And as we all know, extreme positions help define the middle. Many of the Cypherpunks have been heavy Internet users for years and hope to preserve the communal spirit of that freewheeling world of interconnected computer networks. They dread the coming commercial network of televisions and computers, saying it will displace the Internet and destroy many of the freedoms they now enjoy. So the Cypherpunks, with the kind of zeal they professionally bring to marathon, 72-hour sessions hacking computer code, are plotting to keep free networks alive. That's "free" in the sense of unfettered, unmonitored, uncensored. One way they're going about it is by spreading easy-to-use, cheap cryptography. Cryptography is the science of keeping two-way communication private. Computers, it turns out, are revolutionary cryptographic tools, able to encode and decode files quickly. For the first time, virtually unbreakable codes are now possible, thanks to computers. The Cypherpunks post cryptographic software on the Internet where anyone can access it, and can encode their communications, including electronic mail, pictures and video. But the U.S. government is concerned, as governments always are, about the spread of powerful cryptography (terrorists could use it, kidnapers could use it, drug dealers could use it, all of them on cellular phones that encode conversations). It currently is pushing its own commercial cryptographic standard, through a special chip known as the Clipper. The chip is reviled by Cypherpunks and other civil libertarians because it provides a back door that law-enforcement agencies could enter, with the proper warrants, for surveillance. By getting good, unbreakable cryptography out there now, the Cypherpunks hope, whatever the government finally decides will be moot. Software has a wonderful property, the Cypherpunks are fond of saying: Once it's created, it can never be destroyed. It can be copied infinitely, from computer to computer, spreading like a secret. Come what may, unbreakable Cypherpunk code, and Cypherpunk networks, will be out there forever, they hope. But just to be safe, the Cypherpunks are toying with different network-related plans to create an economy of "digicash" - network money that, like the dollars in your pocket, isn't tied to a user's credit cards or other personal identification. Digicash will help pay for Cypherpunk networks and will allow people to purchase goods without revealing their identity. "I'm starting a bank, and it's not going to be a U.S. bank," Hughes says. He's standing at the whiteboard now. A strawberry-blond ponytail dangles down his back and he grasps a magic marker in his hand. "We have several long-term strategies, one of which is the elimination of central banks." He tells the assembled crowd what they already know. Heads nod. Some people take notes. Hughes is a self-employed programer in Berkeley. His hand flies across the whiteboard, sketching out a schematic diagram, showing how his bank will operate. The bank will store depositers^ money (he's thinking a $200 minimum deposit) and disburse payments to anyone - all over the Internet. It will be based abroad, maybe in Mexico. A Cypherpunk network bank is one way to pay for a network of truly encrypted, private communications, you see. "Is this going to lead the way to portable laptop ATM machines?" someone asks in the back. People snicker. "Have you thought about its name?" someone else asks. "First Bank of Cyberspace!" yells one person. "First Internet Bank!" yells another. "The Nth National Bank!" Laughter. Billy goat beards bob. There is much work to be done. --end of story-- -- josh quittner vox: 516-843-2806 fax: 516-843-2873 quit(a)newsday.com

1 0

unsubscribe wjm@mit.edu
by wjm＠MIT.EDU 17 Dec '03

17 Dec '03

unsubscribe wjm(a)mit.edu

1 0