December 2003 - cypherpunks-legacy

a reference to STS
by hughes＠ah.com 17 Dec '03

17 Dec '03

Here's the reference for the STS paper. STS is the Station-to-Station protocol. _Authentication and Authenticated Key Exchanges_ by Diffie, Oorschot, Wiener _Designs, Codes and Cryptography 2_, pp 107-125 1992 Eric

1 0

Fwd: More on remailers
by Matthew J Ghio 17 Dec '03

17 Dec '03

Does anyone know what this is??? ---------- Return-path: <genie-postmaster(a)geis.com> Received: from po2.andrew.cmu.edu via trymail ID </afs/andrew.cmu.edu/usr12/mg5n/Mailbox/UhJJW=O00UdaEa=k5z>; Sun, 6 Feb 1994 15:52:27 -0500 (EST) Received: from relay2.geis.com (relay2.geis.com [192.77.188.3]) by po2.andrew.cmu.edu (8.6.4/8.6.4) with SMTP id PAA09729 for <mg5n+(a)andrew.cmu.edu>; Sun, 6 Feb 1994 15:51:36 -0500 From: genie-postmaster(a)geis.com Received: by relay2.geis.com (1.37.109.4/15.6) id AA26116; Sun, 6 Feb 94 20:51:28 GMT Message-Id: <9402062051.AA26116(a)relay2.geis.com> Date: Fri, 4 Feb 94 00:51:00 BST To: mg5n+(a)andrew.cmu.edu Subject: More on remailers Original Msg Id: Not Found genie-postmaster response to your message Subject: More on remailers System: QUIK-COMM Date: Fri 4-Feb-94 0:51 Status: 5 Message picked up by receiving system and delivered to all recipients with NO exceptions. ----------

1 0

NIST - PKP settlements not over yet
by Stanton McCandlish 17 Dec '03

17 Dec '03

[from Gregory Aharonian's Internet Patent News Service] A hostile response to a tentative agreement to settle a patent dispute over the proposed Digital Signature Standard has forced the National Institute of Standards and Technology to return to negotiations. Last summer, NIST officials thought they finally settled the DSS public key patent dispute by granting Public Key Partners (PKP) of Sunnyvale, California, an exclusive worldwide license for the Digital Signature Algorithm (DSA) on which the DSS is built. In exchange for sublicensing rights, the PKP group agreed to endorse NIST's DSS proposal. But F. Lynn McNulty, associate director for computer security with NIST's Computer System Laboratory, said a majority of potential DSS users balked at the deal. NIST published the settlement terms for comment, and McNulty said all but 10 of the 270 comments were critical. [as many of you may remember, EFF coordinated the transmission of these comments to NIST, who did not widely announce the request for comment at all. The uncharitable might call that an attempt to sweep the matter under the rug. The naive might call it an oversight. At any rate almost all of the comments NIST received were routed via EFF, who were happy to publicize it "for" NIST.] Many DSS critics have argued that another algorithm promulgated by RSA Data Security (Redwood City, CA), is a de facto industry digital signature standard and that it would cost too much to comply with a separate government standard. Now NIST is attempting to hammer out a new settlement based on the comments, McNulty said. "The real hang-up continues to be the patent issue", McNulty said. "We're still trying to resolve it". Scientists at CSL designed the CSS to serve as a standard agency tool for verifying the senders and contents of messages transmitted electronically. CSL also prescribed the public key Digital Signature Algorithm (DSA). But PKP, which holds the rights to public key patents on behalf of Stanford University, MIT, and most recently, German professor Claus Schnorr, charged that CSL's proposed algorithm infringed upon these patents. NIST originally sponsored DSA research, and agencies are exempt from any licensing fees. PKP, however, has maintained that vendors that incorporate the standard into their products should pay royalties. [Government Computer News 1/24/94, 58] -- Stanton McCandlish * mech(a)eff.org * Electronic Frontier Found. OnlineActivist F O R M O R E I N F O, E - M A I L T O: I N F O @ E F F . O R G O P E N P L A T F O R M O N L I N E R I G H T S V I R T U A L C U L T U R E C R Y P T O

1 0

Re: remailer delays
by qwerty-remailer＠netcom.com 17 Dec '03

17 Dec '03

It's half done :-) ! Unfortunately the NSA run remailers haven't been handing out info, but this should help people know which blanks are still blanks ;-). God I hate these little sideways smileys! oooooooooooooooooooooooooooooooooooooooooooooo ooo$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ooo $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ o$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$o $$$$$ $$$" "$$$$$" "$ $ $ "$ $$$$$" "$ "$ $$$ $$$$" "$$ $$oo$$$$$ $$oo$ $$$$ $$$$ " $$$$$ $$ $ " $$$ o$$$$ $ $$o "$$$$$o "$ $$ $ $$$$$ $$ $ $$$o $$$$ o $""$$ $$$$$""$$ $ $$$$ $$$$ o $$$$$ $$ $ o $$$$ $$$$ $$$ $o o$$$$$o o$ $ $ $o $$$$$o o$ $o $$$$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$$""""""""""""""""""""""""""""""""""""""$$$$$$$$$$$$""""""""""""$$$$ $$$$ "$$$$$$$$$$" o$$$$ $$$$ "$$$$$$$$" o$$$$$ $$$$ $$$$$$$$ $$$$$$ $$$$$$$$$$$$$ $$$$$$$$$ $$$$$$ $$$$$$$ $$$$$$$$$$$$$ $$$$$$$$$$ $$$$ $$$$$$$$ $$$$$$$$$$$$$ $$$$$$$$$$$ "$$" $$$$$$$$$ $$$$$$$$$$$$$ $$$$$$$$$$$o "" o$$$$$$$$$ $$$$$$$$$$$$$ $$$$$$$$$$$$o o$$$$$$$$$$ $$$$$$$$$$$$$ $$$$$$$$$$$$$o o$$$$$$$$$$$ $$$$$$$$$$$$$ $$$$$$$$$$$$$$o o$$$$$$$$$$$$ "$$$$$$$$$$$$ $$$$$$$$$$$$$$$ $$$$$$$$$$$$" $$$$$$$$$$$$ $$$$$$$$$$$$$$$$ $$$$$$$$$$$$$ $$$$$$$$$$$$ $$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$ "$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$" $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ """$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$""" """""""""""""""""""""""""""""""""""""""""""""" Xenon's Full Disclosure Remailer List. Remailer Fast? OpLog SysLog Subj Batch RD NL CPU Phys PGP BitB ...and? --------- ------ ----- ------ ---- ----- -- -- --- ---- --- ---- ---------- bsu-cs + ? ?/? + ? ? ? ? ? 23a - catalyst + N? SM/MQ - - ? - PA M 23a - choas + ? ?/? + ? ? ? ? ? - - cicada ++ ? ?/? - - - - ? ? - - colostate ++ ? SM/MQ ? - ? ? Un M ? - dis.org -/-- ? ?/? - ? ? ? ? ? 23a - extropia +/- ? SM + - - - Pr M 23a - jarthur +/-- St SM/MQ - -/+ ? ? Un ? 23a - menudo -- N SM - t1 "?" Y Un H 23a - merde -/-- ? ?/? - ? ? ? ? ? - - penet.fi -- St SM - t? 24 + Pr H - - pmantis ++ ? ?/? - ? - - ? ? - - qwerty + C SM/MQ - - - - PA M 23a + rosebud ++/- N MQ - - - N Un M 23a - remba -- ? ?/? ? ? ? ? ? ? 23a - shell ++/+/- St ?/? - ? ? ? ? ? 23a - soda ++/- St+? ?/? - ? ? ? ? ? - Subj: Strips Subject header? NL: Non-linear remailing? 123->231. RD: Random delay added (max, in hours)? Batch: Batched remailing? t2 means twice daily. n5 means after 5 messages. CPU: Pr = private. PA = account on public access machine. Un = university. Phys: Physical security of the CPU, especially at night. H/M/L. BitB: BitBucket feature? Fast?: ++ <5 min + 5-10 min. - ~10-30 min delay -- Pinging isn't practical due to long delays. Probably reliable though. +/- Sometimes +, sometimes -. Normal internet mail delays are common, and are not equivalent in the two directions between any two remailers. Mail still gets through. OpLog: F: full copies of all mail is archived. My large volume mailing should help put a stop to this. St: Stats logs of when mail was remailed. St+: Stats logs of when and where mail was remailed. St-: simple counter. N: operator keeps no logs. C: Simple counter. SysLog: SM: sendmail logs of when and where mail was exchanged. Root access needed. MQ: mailqueue accessible by anyone on the site. Could make logs. I have chosen nicknames based on a string common to both the outgoing address and to the address you see on an incoming message from the remailer. bsu-cs nowhere(a)bsu-cs.bsu.edu catalyst catalyst(a)netcom.com chaos remailer(a)chaos.bsu.edu cicada hh(a)cicada.berkeley.edu colostate nate(a)vis.colostate.edu dis.org remailer(a)dis.org extropia remail(a)extropia.wimsey.com jarthur ebrandt(a)jarthur.claremont.edu menudo nobody(a)Menudo.UH.EDU merde remailer(a)merde.dis.org penet.fi anon.penet.fi pmantis hh(a)pmantis.berkeley.edu qwerty qwerty(a)netcom.com rosebud elee7h5(a)rosebud.ee.uh.edu (elee6ue(a)rosebud.ee.uh.edu) shell hfinney(a)shell.portal.com soda hh(a)soda.berkeley.edu Discontinued remailers still on some lists out there: phantom(a)mead.u.washington.edu remail(a)tamaix.tamu.edu sameer(a)netcom.com sameer(a)berkeley.edu (spelling?) cdodhner(a)indirect.com remailer(a)entropy.linet.org?? 00x(a)uclink.berkeley.edu? remail(a)tamaix.tamu.edu? Background on each remailer: bsu-cs: Run by Chael Hall. Machine: ?? Problems policy: ?? Contact ?? Software: ?? Security: ?? Comments: History: ?? catalyst: Run by Scott Collins. Machine: personal dial-up account on Netcom. Problems policy: Outgoing address blocking, with proof of ID. Contact catalyst(a)netcom.com. Software: Customized Hal's ? Security: Netcom keeps sendmail logs, which root(a)netcom.com can read. Any Netcom user could also compile his own sendmail logs, by constantly logging mail as it arrives and leaves. Comments: History: ?? chaos: Run by Chael Hall. Machine: ?? Problems policy: ?? Contact ?? Software: ?? Security: Comments: finger remailer.help(a)chaos.bsu.edu for info using any remailer. ?? gopher chaos.bsu.edu for a collection of info about Cypherpunks. Comments: History: ?? cicada: Run by Eric Hollander. Machine: ??? Problems policy: ?? Contact ?? Software: ?? Security: Tread lightly. Being "phased out". colostate: Run by ?? Machine: ??? Problems policy: ?? Contact ?? Software: ?? Security: ?? dis.org: Run by Peter Shipley. Machine: ?? Problems policy: ?? Contact ?? Software: ?? Security: ?? Comments: History: ?? extropia: Run by Miron Cuperman. Machine: ?? Problems policy: ?? Contact ?? Software: ?? Security: ?? Comments: Only accepts PGP remailing. ::/Encrypted:PGP header is optional. Privately owned, in Canada. Not directly connected (delays possible). History: ?? jarthur: Run by Eli Brandt. Machine: Sequent Symmetry. Problems policy: Destination blocking is available w/ sufficient ID. Contact ebrandt(a)jarthur.claremont.edu. Software: The usual, tweaked for MMDF. Hal's. Security: jarthur keeps sendmail logs. Comments: Although jarthur doesn't batch, its connection often results in outgoing mail getting batched out anyway (1-3 hours delay). History: Set up late '92. PGP added mid '93. menudo: Run by Karl Barrus. Machine: University machine. Problems policy: see policy at gopher site. Contact klbarrus(a)owlnet.rice.edu or elee9sf(a)menudo.uh.edu. Software: Modified Hal's. Security: Stores messages and sends them out randomly at midnight. Pads messages to 1K with random stuff. (?) Comments: elee9sf@menudo accepts RIPEM encryption. elee6ue@rosebud requires "digital cash" (basically random strings I made). Errors on elee9sf@menudo are forwarded klbarrus(a)owlnet.rice.edu where they are deleted. I still get mail at that address which is why I have it forwarded and not just dropped. History: No comment. merde: Run by Peter Shipley. Maching: ?? Problems policy: ?? Contact ?? Software: ?? Security: ?? Comments: History: ?? penet.fi: Run by Julf (Johan Helsingus). Machine: ?? Operator owned. Problems policy: Account revokation. Contact ??(a)anon.penet.fi. Software: custom. Security: Comments: By far the most popular remailer, dwarfing in a day what the entire Cypherpunk remailers combined carry in a month. Supports easy return addresses as well as non-anonymous mailing to someone's anonymous address (na1234... instead of an1234...). Your real address is kept on Julf's hard disk, but is fairly safe there, especially if you do not abuse your anonymity to harass someone. On a bad day your mail and especially Usenet posts may be delayed up to a day. Very reliable though. Sends error messages back to you for failed mail. Limited to 48K mail. History: ?? pmantis: Run by Eric Hollander. Machine: ?? Problems policy: ?? Contact ?? Software: ?? Security: Tread lightly. Being "phased out". Comments: History: ?? qwerty: Run by Xenon. Machine: dial-up account on Netcom. Problems policy: "What problems?". Contact qwerty(a)netcom.com. Software: Hal's remailer. Security: Netcom keeps sendmail logs, which root(a)netcom.com can read. Any Netcom user could also compile his own sendmail logs, by constantly logging mail as it arrives and leaves. Operator often logs in using telnet. Comments: You must use na1234(a)anon.penet.fi not an1234(a)anon.penet.fi. Finger qwerty(a)netcom.com for a blurb on the remailer and updates on its software. Request-Remailing-To: /dev/null is a bit bucket. whitehouse.gov gets blocked and fully logged. History: Up 2/94. Set up by Xenon who needed more remailers to use to send PGP info to people with, since anon.penet.fi was overloaded. rembe: Run by Bill (O'Hanlon?). Machine: ? Privately owned. Problems policy: ?? Contact ?? Software: ?? Security: ?? Comments: Not directly connected (delays?). History: Second oldest remailer. rosebud:(elee7h5@rosebud.ee.uh.edu) Run by Karl Barrus. Machine: University. Problems policy: See gopher site. Contact klbarrus(a)owlnet.rice.edu. Software: Hal's. Security: "syslog file can be read" Comments: Errors are "dropped". History: Third oldest remailer. rosebud: (elee6ue(a)rosebud.ee.uh.edu) Run by Karl Barrus. Machine: univerisity Problems policy: see gopher site. Contact klbarrus(a)owlnet.rice.edu. Software: standard scripts (Hal's) modified to accept cash strings. Security: "Syslog file can be read." Comments: Errors are "dropped". shell: Run by Hal Finney. Machine: ?? Problems policy: ?? Contact ?? Software: Hal's Remailer. Security: ?? Comments: whitehouse.gov blocked and fully logged. hal(a)alumni.caltech.edu forwards all mail to shell. History: ?? soda: Run by Eric Hollander. Run by: ?? Machine: ?? Problems policy: ?? Blocking of addresses. Mail sent to problem causer. Contact ?? Software: custom. ?? Security: Was keeping full logs till Xenon's bulk mailing venture. ?? Comments: History: ?? Remailer Public Keys: (I've got these).

1 0

FOR Xenon (what's his email?)
by nate＠VIS.ColoState.EDU 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Info on the nate(a)vis.colstate.edu remailer colostate: Run by Nate Sammons nate(a)vis.colostate.edu Machine: Sun 4/280 - direct ethernet connection to the Colorado State University backbone. Getewayed to CU/BOulder, and then into the Net backbone. Problems policy: No problems yet. Nobody at CSU really knows about it yet ;-) Contact Nate Sammons nate(a)vis.colostate.edu Software: Hal's Remailer software, modified Security: What do you want to know? - -nate BTW, thanks for the work! - -- +-----------------------------------------------------------------------+ | 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

PGP Tools & Magic Money Update
by nobody＠shell.portal.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- PGP Tools and Magic Money would not run on a big-endian machine. This did not surprise me, because I don't have one to test it on. I sent a new version to csn.org which fixes a bug in fifo_moven, and includes a #define to force the precision to maximum on a big-endian machine. This should make it work, but will slow it down. The new version, when it shows up, should be in the pgp_tools directory. Go to /mpj, read README.MPJ, and it will tell you how to get into the crypto section. Check the file dates to see if the new version is there yet. I sent them on 2/6. Is there anyone who would like to fix it so it will run properly? The files pgptools.c and ptd.c in the toolkit, and mm.c, s.c, and c.c in the Magic Money system, need to be changed. There is a function called rescale which has to be run on mpi's after set_precision is called. I have no way to test any changes, so I can't write this. Pr0duct Cypher -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVWRMcGoFIWXVYodAQHSCwQAhA8gZTKDEnzdFyC5UbB0HpvSe299w4F0 bmAA+vplPWNIuFx+RswN6UeCqr9v32tPHTopU4y8twWWJ6p+sA0laqfPVsubtuKK 0bJkasrhIYZDfh4X+RaXgiv50hrcqm87Str0asUOiv1sA7Mv9G5cTxQPwvm0Wiq1 BEjeR5cYn8M= =6VZI -----END PGP SIGNATURE-----

1 0

FOR Xenon (what's his email?)
by qwerty-remailer＠netcom.com 17 Dec '03

17 Dec '03

na38138(a)anon.penet.fi or faster, qwerty(a)netcom.com. -=Xenon=- P.S. I'm e-mailing you separately.

2 1

FOR Xenon (address?)
by qwerty-remailer＠netcom.com 17 Dec '03

17 Dec '03

Gee, someone must have snuck into my account and changed all the 48s to 38s. I stand corrected. na48138(a)anon.penet.fi. Mister 38138 must be rather confused due to the "Bomb me!"s he's been getting :-). I'll send him a note to tell him. Maybe I can convince HIM to take over this project even! -=Xenon=-

1 0

Attack on Magic Money and Chaum cash
by Hal 17 Dec '03

17 Dec '03

I think there may be a security weakness in Magic Money coins, and in Chaum's "online" cash system from the Chaum/Fiat/Naor paper. Magic Money coins are numbers of a particular form, RSA-signed by the bank. They look like Y^(1/e) where Y is the number and e is the bank's public exponent corresponding to the particular denomination of the coin. The structure of Y is a 0, a 1, a string of bytes of 0xff, then a defined 18-byte string of bytes, then 16 random bytes. This Y is generated by the user, and is then blinded by multiplying by some random r^e, and sent to the bank. The bank RSA-signs Y*r^e to get r*Y^(1/e), and the user divides by r to get Y^(1/e). This is the coin. The coin is checked by raising it to the power e, to get Y, then checking to see if it is of the proper form. Actually, the Magic Money code only checks the 18-byte special string (just above the 16 random bytes) to make sure it matches the exact byte sequence that is always supposed to be there. In addition the bank checks the 16 random bytes against a list of spent coins to make sure this coin hasn't been spent before. The other relevant point is that the bank has to sign everything you give to it (with payment) - it can't check the bit pattern for legality, since what it is signing is blinded. So you can really get the bank to sign anything. Yesterday I opined that this would be safe, but now I don't think so. The danger I would see is an attacker who gets the bank to sign 2, 3, 5, 7, 11, 13, 17, 19, .... The bank won't know it is signing these special numbers because they are blinded. If someone gets a lot of low primes signed he may be able to forge money, especially with the incomplete checks in the Magic Money program. The idea would be for him to try to factor a legal Y using just the primes he has. If he can find a factorization using only small primes of a number which holds the magic 18-byte sequence in the right place, he can multiply together the signed forms of the primes to produce a signed version of that number. This would be a successfully forged coin. So, the question is whether it would be feasible to collect enough signed small primes to be able to generate more valid coins than you have primes. (It costs you a coin each time you get the bank to sign something, so for this to be a money-making venture you want to get more out of it than you put into it!) I think there are a reasonable fraction of numbers factorable by only small primes. Since there are 2^128 possible money values (based on the 16 random bytes) there should be quite a lot which are factorable by only small primes. Magic Money could help by checking the high bytes as well as the magic 18; it would be take more time to factor 1024 bit numbers than 272 bit ones ((18+16)*8), and there would be fewer that are factorable by small primes. But the problem would still exist. The attacker can run a fast sieve to identify numbers which are factorable in his set. The same attack would apply to Chaum's online cash. His cash is of the form, (x,f(x)^(1/e)), where f() is a one-way function like MD5. To forge this you would again get signed forms of the small primes, then keep picking random x's, until you got a f(x) which could be factored by your set. Presto, you can create a fake coin. I don't know how this attack can be prevented. Hal

1 0

Re: Attack on Magic Money and Chaum cash
by Hal 17 Dec '03

17 Dec '03

A quick follow-up: I suppose a cut-and-choose protocol in the withdrawal would prevent this attack. Instead of sending in one blinded coin to be signed you'd send in 100 blinded candidates, then the bank would pick 99 and you'd reveal the r's for the others (remember, they are blinded with r^e) so the bank can verify they are of the proper form. The bank would then sign the one remaining one and return it to you. What a pain! I hope someone can come up with something better, or show that the attack doesn't work. Hal

1 0