December 2003 - cypherpunks-legacy

List of reliable remailers
by Raph Levien 17 Dec '03

17 Dec '03

I operate a remailer pinging service which collects detailed information about remailer features and reliability. To use it, just finger remailer-list(a)kiwi.cs.berkeley.edu There is also a Web version of the same information, plus lots of interesting links to remailer-related resources, at: http://www.cs.berkeley.edu/~raph/remailer-list.html This information is used by premail, a remailer chaining and PGP encrypting client for outgoing mail. For more information, see: http://www.c2.org/~raph/premail.html For the PGP public keys of the remailers, finger pgpkeys(a)kiwi.cs.berkeley.edu This is the current info: REMAILER LIST This is an automatically generated listing of remailers. The first part of the listing shows the remailers along with configuration options and special features for each of the remailers. The second part shows the 12-day history, and average latency and uptime for each remailer. You can also get this list by fingering remailer-list(a)kiwi.cs.berkeley.edu. $remailer{"extropia"} = "<remail(a)miron.vip.best.com> cpunk pgp special"; $remailer{"portal"} = "<hfinney(a)shell.portal.com> cpunk pgp hash"; $remailer{"alumni"} = "<hal(a)alumni.caltech.edu> cpunk pgp hash"; $remailer{"bsu-cs"} = "<nowhere(a)bsu-cs.bsu.edu> cpunk hash ksub"; $remailer{"c2"} = "<remail(a)c2.org> eric pgp hash reord"; $remailer{"penet"} = "<anon(a)anon.penet.fi> penet post"; $remailer{"hacktic"} = "<remailer(a)utopia.hacktic.nl> cpunk mix pgp hash latent cut post ek"; $remailer{"flame"} = "<remailer(a)flame.alias.net> cpunk mix pgp. hash latent cut post reord"; $remailer{"rahul"} = "<homer(a)rahul.net> cpunk pgp hash filter"; $remailer{"mix"} = "<mixmaster(a)remail.obscura.com> cpunk mix pgp hash latent cut ek ksub reord ?"; $remailer{"ford"} = "<remailer(a)bi-node.zerberus.de> cpunk pgp hash ksub ek"; $remailer{"vishnu"} = "<mixmaster(a)vishnu.alias.net> cpunk mix pgp hash latent cut ek ksub reord"; $remailer{"robo"} = "<robo(a)c2.org> cpunk hash mix"; $remailer{"replay"} = "<remailer(a)replay.com> cpunk mix pgp hash latent cut post ek"; $remailer{"spook"} = "<remailer(a)spook.alias.net> cpunk mix pgp hash latent cut ek reord"; $remailer{"rmadillo"} = "<remailer(a)armadillo.com> mix cpunk pgp hash latent cut ek"; $remailer{"ecafe"} = "<cpunk(a)remail.ecafe.org> cpunk mix"; $remailer{"wmono"} = "<wmono(a)valhalla.phoenix.net> cpunk mix pgp. hash latent cut"; $remailer{"shinobi"} = "<remailer(a)shinobi.alias.net> cpunk mix hash latent cut ek reord"; $remailer{"amnesia"} = "<amnesia(a)chardos.connix.com> cpunk mix pgp hash latent cut ksub"; $remailer{"gondolin"} = "<mix(a)remail.gondolin.org> cpunk mix pgp hash latent cut ek reord"; $remailer{"tjava"} = "<remailer(a)tjava.com> cpunk mix pgp hash latent cut"; $remailer{"pamphlet"} = "<pamphlet(a)idiom.com> cpunk pgp hash latent cut ?"; $remailer{'alpha'} = '<alias(a)alpha.c2.org> alpha pgp'; $remailer{'gondonym'} = '<alias(a)nym.gondolin.org> alpha pgp'; $remailer{'nymrod'} = '<nymrod(a)nym.alias.net> alpha pgp'; $remailer{'cubed'} = '<alias(a)alias.alias.net> alpha pgp'; $remailer{"lead"} = "<mix(a)zifi.genetics.utah.edu> cpunk pgp hash latent cut ek"; $remailer{"treehole"} = "<remailer(a)mockingbird.alias.net> cpunk pgp hash latent cut ek"; $remailer{"nemesis"} = "<remailer(a)meaning.com> cpunk pgp hash latent cut"; $remailer{"exon"} = "<remailer(a)remailer.nl.com> cpunk pgp hash latent cut ek"; $remailer{"vegas"} = "<remailer(a)vegas.gateway.com> cpunk pgp hash latent cut"; $remailer{"haystack"} = "<haystack(a)holy.cow.net> cpunk pgp hash latent cut ek"; $remailer{"ncognito"} = "<ncognito(a)gate.net> mix cpunk latent"; catalyst(a)netcom.com is _not_ a remailer. lmccarth(a)ducie.cs.umass.edu is _not_ a remailer. usura(a)replay.com is _not_ a remailer. Groups of remailers sharing a machine or operator: (c2 robo alpha) (gondolin gondonym) (flame hacktic replay) (alumni portal) (vishnu spook wmono nymrod) Use "premail -getkeys pgpkeys(a)kiwi.cs.berkeley.edu" to get PGP keys for the remailers. Fingering this address works too. Note: The remailer list now includes information for the alpha nymserver. Last update: Mon 1 Apr 96 6:48:11 PST remailer email address history latency uptime ----------------------------------------------------------------------- ecafe cpunk(a)remail.ecafe.org -*#*######## :48 100.00% haystack haystack(a)holy.cow.net *-##+*****+* 2:09 100.00% cubed alias(a)alias.alias.net ***+#** 19:29 99.99% pamphlet pamphlet(a)idiom.com ++++++++++-+ 1:22:18 99.99% nymrod nymrod(a)nym.alias.net +++--*+*+--* 38:14 99.98% nemesis remailer(a)meaning.com **++******** 17:30 99.97% flame remailer(a)flame.alias.net .---.------ 5:25:05 99.97% shinobi remailer(a)shinobi.alias.net #*########*# 1:07 99.97% hacktic remailer(a)utopia.hacktic.nl ****+******* 8:11 99.97% alpha alias(a)alpha.c2.org ++++-++++**+ 46:53 99.92% vegas remailer(a)vegas.gateway.com .-*.-#*#+### 4:28:59 99.89% ncognito ncognito(a)gate.net #*# ##***-## 6:36 99.72% mix mixmaster(a)remail.obscura.com -+-___.--*-* 15:11:14 99.69% spook remailer(a)spook.alias.net +***+*+**+** 19:46 99.66% gondolin mix(a)remail.gondolin.org __.--*----- 13:53:43 99.64% gondonym alias(a)nym.gondolin.org __.--*--+-- 13:48:57 99.64% exon remailer(a)remailer.nl.com --***++**-* 13:59 99.59% replay remailer(a)replay.com ++**++*+**+ 8:46 99.57% vishnu mixmaster(a)vishnu.alias.net ++- - ***--+ 2:46:31 99.26% treehole remailer(a)mockingbird.alias.net --+++-- -+++ 3:47:33 98.96% amnesia amnesia(a)chardos.connix.com -- --+--+++ 1:57:42 98.49% portal hfinney(a)shell.portal.com *#-#####*## 1:30 96.59% alumni hal(a)alumni.caltech.edu _* #+# -### 1:08:06 96.24% penet anon(a)anon.penet.fi .___ -__.. 47:32:06 95.78% c2 remail(a)c2.org *****.+-+++ 37:24 94.43% extropia remail(a)miron.vip.best.com --------- 6:03:31 83.40% lead mix(a)zifi.genetics.utah.edu *+++++ 34:15 34.40% tjava remailer(a)tjava.com #* ** 1:02 25.24% History key * # response in less than 5 minutes. * * response in less than 1 hour. * + response in less than 4 hours. * - response in less than 24 hours. * . response in more than 1 day. * _ response came back too late (more than 2 days). cpunk A major class of remailers. Supports Request-Remailing-To: field. eric A variant of the cpunk style. Uses Anon-Send-To: instead. penet The third class of remailers (at least for right now). Uses X-Anon-To: in the header. pgp Remailer supports encryption with PGP. A period after the keyword means that the short name, rather than the full email address, should be used as the encryption key ID. hash Supports ## pasting, so anything can be put into the headers of outgoing messages. ksub Remailer always kills subject header, even in non-pgp mode. nsub Remailer always preserves subject header, even in pgp mode. latent Supports Matt Ghio's Latent-Time: option. cut Supports Matt Ghio's Cutmarks: option. post Post to Usenet using Post-To: or Anon-Post-To: header. ek Encrypt responses in reply blocks using Encrypt-Key: header. special Accepts only pgp encrypted messages. mix Can accept messages in Mixmaster format. reord Attempts to foil traffic analysis by reordering messages. Note: I'm relying on the word of the remailer operator here, and haven't verified the reord info myself. mon Remailer has been known to monitor contents of private email. filter Remailer has been known to filter messages based on content. If not listed in conjunction with mon, then only messages destined for public forums are subject to filtering. Raph Levien

1 0

RE: Witch hunt
by Brian D Williams 17 Dec '03

17 Dec '03

>From: "Vladimir Z. Nuri" <vznuri(a)netcom.com> >Tim May == Rousseau??? hehehehehe. and I fail to comprehend how >anyone so universally despised as Detweiller could be considered >to have employed any "effective critical technique". maybe I >should send him some email, but alas I perceive that to be another >waste of time. Send HIM some E-mail? That's pretty funny Larry! What happened, someone sever your Corpus Callosum? Brian

1 0

gnutar + pgp filter mode
by William Hayward 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- The gnu tar archiver allows to use an arbitrary compression program (option --use-compress-program=PROG). This works well with pgp if a small wrapper is used: #!/bin/csh -fb if ("$1" == "-d") then exec pgp -d -f else exec pgp -e -f endif The only problem is that this doesn't work well for larger amounts of data, because pgp reads in all data before starting with its work. Perhaps a future release of pgp will have a real filter mode. Hadmut BTW: Does this "crypto-hook" cause export restrictions to apply on gtar ? -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMV/0tmc1jG5vDiNxAQFtAAP/TMuYeYf5q7k1Y8DrBjb6XFKYYFANH3RH FvThWq1BUgI+unH97EZkNkCzZJYT5qmLGk3+JLufCAw/o9YR7jKcldm2LNYJ96t2 BDcSGDF3qx/IUzQBa5NV+gUerNRVSwA3LzkTbXufOxYH0cB3KNcsx3B0bE1rEDa/ GCcJ1L6T+2s= =FMiZ -----END PGP SIGNATURE-----

1 0

"Dead beef" attack against PGP's key management
by Raph Levien 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- This post is signed by a forged key for Phil Zimmermann. I forged the key this morning. The key has the same user id and visible key id as an old key for Phil Zimmermann, which he has since revoked. I should stress that this attack does not in any way weaken the security of PGP's message formats. However, it does expose a problem in the user interface of its key management. Namely, it is fairly easy to forge a key that looks very similar to an existing key. In fact, the only way to distinguish between real and forged keys in general is by the fingerprint and keysize together. My purpose in posting this is to demonstrate that such forgeries are possible. The lesson is: please do not use the key id alone to identify keys. Another reason for the public posting of this forgery is to goad the PGP development team into improving the user interface in PGP 3.0, so as to make the detection of such a forgery much easier, if not routine. Derek Atkins has assured me that PGP 3.0 will include a cryptographic hash of the key, for use as a key id. If implemented properly, such a facility would address this attack. I am not the first to propose this attack. According to Derek Atkins, Paul Leyland first proposed the attack two years ago. Also, Greg Rose successfully mounted a similar attack six months ago, creating a key with user id 0xDEADBEEF, thereby giving rise to the name. The pseudocode for the attack is as follows: choose random 512 bit prime p choose random 480 odd x q = x * ((0xdeadbeef * (p * x) ^ -1) mod 2^32) do {q += 2^32} while q composite The above bit of pseudocode replaces the original selection of p and q, which are normally just random 512 bit primes. Without having done detailed analysis, I believe that the resulting forged keys are just as good as ordinary PGP keys. Further, the modified key generation is almost as fast as ordinary PGP key generation, and I think I could speed it up a bit more. The attack took me a few hours to design and code. Any good programmer familiar with PGP could duplicate it easily. One practical application of this attack is to implement a certain degree of "stealth." Since PGP includes the key id in encrypted messages, it is in most cases possible to identify the recipients of encrypted messages. However, if a lot of people generated keys with the same key id, then it would not be possible to tell from the encrypted message which one was the intended recipient. Here's the public key I forged, which can be used to check the signature of this message: Key for user ID: Philip R. Zimmermann <prz(a)acm.org> 1024-bit key, Key ID FF67F70B, created 1992/07/22 Also known as: Philip R. Zimmermann <prz(a)sage.cgd.ucar.edu> - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAyptNMAAAAEEALRhS3ZCFKLPNF/fZeluh/rNfpgZ5a0ddTBtxJ+1yLIkVurb HWFFBsrmnA4hU4MhlA8DS/f2gnS0v3zyQ78JOY1SBIJrLdaIPIrh0ZTAZXWoQWDe Qknm1ZgyLkIRJlt5aDLp+iLJ5sc+LSO5N/DtrL+Htc5MF0AVAWtzPhz/Z/cLAAUR tCJQaGlsaXAgUi4gWmltbWVybWFubiA8cHJ6QGFjbS5vcmc+iQCVAwUQMWAremtz Phz/Z/cLAQE//AP/bg9gMOuiBYkFCiyarJ/DIARWDf7e4bWFJloXAyPeBXCITDIw tuHRJ41yFqnlLmdcuVhXQf/xrH248JyWpHqqED6eOU/PnBHo9IR6H0Fts+O3I+vk tOYRjuTJy+6JV0s/8VN/Sgh8y6Jm2FGhhzhCp6KHNcTHpUud6iGScaEs/CG0LFBo aWxpcCBSLiBaaW1tZXJtYW5uIDxwcnpAc2FnZS5jZ2QudWNhci5lZHU+ =Z1mf - -----END PGP PUBLIC KEY BLOCK----- Raph Levien -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMWA2pGtzPhz/Z/cLAQELEQP/fam4tHS8TlMy7SFoUZvC0C4q0ID9Ze5W rY2D++df4UtAFDITGs4lQqzeq6YCqk51oT8gZAACK6D6UlFgr5roIbgwa74Fxso1 B5mquC9axlOlxZJI1PuK+NflBJqCokuQGtG95ER6vbm4n4RACW43In9SAatIvduN JfBSLYrAr14= =V5U6 -----END PGP SIGNATURE-----

1 0

Re: Electronic locksmiths are watching you (Belgium's ban onPGP)
by jim bell 17 Dec '03

17 Dec '03

At 02:56 PM 4/1/96 -0500, Black Unicorn wrote: > >Following my new policy on Jim Bell posts, the below represents my new >form of reply. These 'terse' replies should cut down on bandwidth and >still serve as some basic protection to the list readership as to the >mis and dis-information which eminates in quantity from Mr. Bell's >account. Those parties interested in a more detailed discussion, aside >of course Mr. Bell, should ask for clarification where they feel it >necessary and I will then expound on my points. What you _really_ ought to do is to cut down your responses to ZERO, especially on material that was not sent to you. Until you're willing to talk intelligently about what you believe, you're just wasting peoples' time. Jim Bell jimbell(a)pacifier.com

1 0

Re: "Random Sequence"
by rollo＠artvark.com 17 Dec '03

17 Dec '03

>At 07:25 AM 3/31/96 -0700, Rollo Silver wrote: >>The paper "On the Effective Definition of 'Random Sequence'", by Michael >>Levin, Marvin Minsky, and Roland Silver can be viewed (and downloaded, and >>printed) from my website <http://www.artvark.com/artvark>. > >Rollo, > > I read the paper and it's nice work -- but it departs from current >definitions of random sequences in that it assumes you specify the countable >set of machines trying to test for non-randomness first and then generate a >sequence to fool that set of machines. Current definitions of randomness >assume an infinite set of testing machines, often limited to polynomial time >and space, and a sequence generator that must defeat them all without >knowing anything about them. Such sequences are, in a sense, "more random" >than the ones your paper dealt with -- I believe. Did I miss something? * It's a bit anachronistic to say in 1996 that a paper written 30 years earlier "departs from current definitions of random sequences." The authors may have been brilliant, but they weren't prescient. <g> I can't imagine how a computer could be smart enough to defeat an infinite set of guessing machines without knowing ANYTHING about them. In fact, what's wrong with this argument: call the "fooling" machine Frank, and one of the "guessing" machine Gert. You say that Frank doesn't need to know anything about Gert. Let me suppose however that Gert DOES know about Frank. In that case, Gert can simulate Frank and "guess" his output, thus foiling Frank's attempts to fool Gert! Maybe it's the "polynomial time & space". That restricts the guesser-domain considerably, compared with our very weak requirement that the guessers can be any Turing machines whatever -- as long as the set of them is effectively calculable. BTW, is the set of ALL finite automata effectively calculable? I suspect maybe so. If so, by essentially the argument given in the paper, there is a computer (Turing machine) that can fool them ALL. I hope it's okay to cc this note to coderpunks. It's not about coding per se, but it may shed some light on what "randomness" means, and on "computable randomness", which sounds appropriate for coderpunks to me. ------------------------------------------------------------------------ Rollo Silver | The CDA means | Artvark / PO Box 219 505-586-0197 | lost jobs and | San Cristobal, NM 87564 USA rollo(a)artvark.com | dead teenagers | http://www.artvark.com/artvark/

1 0

Re: A MODEST PROPOSAL (fwd)
by Bill Stewart 17 Dec '03

17 Dec '03

This happens any time anybody signs up with an an######(a)anon.penet.fi address. Ideally, someone could, in their copious spare time, hack majordomo to automatically translate all subscription requests of that form to na######(a)anon.penet.fi ; as an alternative, if majordomo has some sort of subscription blocking list an*(a)anon.penet.fi belongs on it. At 07:35 PM 3/30/96 -0800, Sandy wrote: >has anyone had the sort of problem mentioned below? >From: E. ALLEN SMITH <EALLENSMITH(a)ocelot.Rutgers.EDU> >To: sandfort(a)crl.com >Subject: Re: A MODEST PROPOSAL >From: IN%"sandfort(a)crl.com" "Sandy Sandfort" 26-MAR-1996 16:57:18.92 >>Wilco. I'm collecting names for an addendum now. > Thanks. Incidentally, I recently had a problem with posting to >the cypherpunks list; it consisted of the message getting sent to anon.penet.fi >instead. This looks like someone trying to find out anon.penet.fi anon IDs; >however, it wouldn't work due to the password requirement. Have you heard >anything about this? #-- # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com, +1-415-442-2215 pager 408-787-1281 1995: Chat rooms, espresso, and Linux 1996: Exon, melatonin, and Java.

1 0

RE: Java flaw is in bytecode verifier
by Steve Gibbons 17 Dec '03

17 Dec '03

In Article: <199604020006.QAA21649(a)jobe.shell.portal.com>, Hal <hfinney(a)shell.portal.com> wrote: # From http://java.sun.com/sfaq/960327.html: # > Researchers at Princeton recently found an implementation bug in the Java # > bytecode Verifier. The Verifier is a part of Java's runtime system which # > certifies that applets downloaded over the Internet adhere to Java's # > language safety rules. Through a sophisticated attack, a malicious applet # > can exploit this bug to delete a file or do other damage. # This is one of the more worrisome places for a bug to exist. Much of # Java's security rests in the claim that it can screen for and detect bad # bytecode sequences. This screening code is extremely critical for Java # security and I am surprised to see that it was implemented in a flawed # manner. # I've been writing Java quite a bit in the last couple of weeks, and I # find that I have crashed my browser, whether Netscape or appletviewer, # many times. Granted some of my code has been pretty buggy, but it's # still not supposed to crash the browser. Obviously some of the runtime # checks are not being done properly. I had expected that the bug would # be in these areas, something like the stack overflows that we have seen # cause problems in the past. A simple error in the bytecode verifier # (if that is what this really is) seems like a more fundamental security # flaw. # The researchers have still not released full details on the bug, although # they had planned to do so by the end of March. Maybe they are waiting # for the fix to be distributed. As I keep saying (multiple times, in multiple forums) "Java is still in Beta-Test." Sun acks/grocks this, although Netscape ships most of their production-level browsers with Java enabled by default. The primary reason for releasing beta software is to catch any discrepancies between the documented behaviour and the implimented behaviour of a product. Bugs WILL be found in beta testing. To reiterate: "If you insist on being on the bleeding edge, you WILL bleed." This has been a test of the emergency reality-check service. Had this been a real reality-check, the software in question would be labeled "golden" and you would be provided with a "support(a)foo.bar.com" email address to contact for your product. Again this is only a test, and is (as such) non flamable. Any party that might take offense to this message should re-read the contents of the message, and either A) re-evaluate their perception of it, or B) re-evaluate their practices. -- Steve(a)AZTech.Net

1 0

Ecash Article in ID
by Joseph M. Reagle Jr. 17 Dec '03

17 Dec '03

This is a resend, but my subject didn't match the content in the last send { Found an interesting article on Ecash in Industrial (Internatioal) Design. / What is Money / Karrie Jacobs ID March/April 96 } _______________________ Regards, Those who would have nothing to do with thorns must never attempt to gather flowers. Joseph Reagle http://farnsworth.mit.edu/~reagle/home.html reagle(a)mit.edu 0C 69 D4 E8 F2 70 24 33 B4 5E 5E EC 35 E6 FB 88

1 0

Cypherpunks investigated, FOIA?
by Declan B. McCullagh 17 Dec '03

17 Dec '03

>From sgs(a)well.com: Have the cypherpunks requested data on whether they are being investigated by the same agencies under the FOIA individually or as a group listed by that name? If so, what are the results, if any, so far? Does anyone know if this has been done? The FOIA, that is. -Declan

1 0