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, which is available at: ftp://ftp.csua.berkeley.edu/pub/cypherpunks/premail/premail-0.33a.tar.gz 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)extropia.wimsey.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)valhalla.phoenix.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 ek 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{"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"; 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 hroller alpha) (gondolin gondonym) (flame hacktic replay) (alumni portal) (vishnu spook wmono) 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 4 Mar 96 6:48:59 PST remailer email address history latency uptime ----------------------------------------------------------------------- nymrod nymrod(a)nym.alias.net **+-*+***+*# 10:33 99.99% vegas remailer(a)vegas.gateway.com **#+***#+### 3:24 99.99% ecafe cpunk(a)remail.ecafe.org ############ :18 99.97% treehole remailer(a)mockingbird.alias.net +-+-----+--+ 2:02:33 99.96% hacktic remailer(a)utopia.hacktic.nl *********+** 8:08 99.95% gondonym alias(a)nym.gondolin.org ------------ 3:27:17 99.94% replay remailer(a)replay.com ****+**+**** 5:07 99.91% portal hfinney(a)shell.portal.com ###* +*--##+ 25:24 99.87% gondolin mix(a)remail.gondolin.org -----+------ 3:27:40 99.77% alpha alias(a)alpha.c2.org *-+*+++ +.-+ 58:19 99.76% exon remailer(a)remailer.nl.com *+* .+*----+ 46:22 99.75% vishnu mixmaster(a)vishnu.alias.net -+-**** -** 32:44 99.70% c2 remail(a)c2.org +-*-++++ -* 39:23 99.66% flame remailer(a)flame.alias.net ----------- 2:31:41 99.57% tjava remailer(a)tjava.com #*-#######*# 3:08 99.19% extropia remail(a)extropia.wimsey.com ----___.+- 24:11:30 99.18% nemesis remailer(a)meaning.com *-*+*-*** -* 24:02 98.98% penet anon(a)anon.penet.fi .-.---... 23:23:07 97.58% shinobi remailer(a)shinobi.alias.net +*****+* ## 25:06 90.76% lead mix(a)zifi.genetics.utah.edu +++++++ +-+ 37:47 90.28% alumni hal(a)alumni.caltech.edu #- ## 22:41 80.89% mix mixmaster(a)remail.obscura.com ..---+ 5:31:48 34.72% 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

No Subject
by nobody＠vegas.gateway.com 17 Dec '03

17 Dec '03

Thought that this was worth reposting: >I attended last weeks "Information, National Policies, and International >Infrastructure" Symposium at Harvard Law School, organized by the Global >Information Infrastructure Commission, the Kennedy School and the >Institute for Information Technology Law & Policy of Harvard Law School. > >During the presentation by Paul Strassmann, National Defense University >and William Marlow, Science Applications International Corporation, >entitled "Anonymous Remailers as Risk-Free International Infoterrorists" >the questions was raised from audience (Professor Chaarles Nesson, >Harvard LAw School) - in a rather extended debate - whether the CIA and >similar government agencies are involved in running anonymous remailers >as this would be a perfect target to scan possibly illegal messages. > >Both presenters explicitly acknowledged that a number of anonymous >remnailers in the US are run by government agencies scanning traffic. >Marlow said that the government runs at least a dozen remailers and that >the most popular remailers in France and Germany are run by the >respective government agencies in these countries. In addition they >mentioned that the NSA has successfully developed systems to break >encrypted messages below 1000 bit of key length and strongly suggested >to use at least 1024 bit keys. They said that they semselves use 1024 >bit keys. > >I ask Marlos afterwards if these comments were off or on record, he >paused then said that he can be quoted. > >So I thought I pass that on. It seems interesting enough, don't you >think? > >Best > >Viktor Mayer-Schoenberger >Information Law Project >Austrian Institute for Legal Policy > Groundfog(a)alpha.c2.org

2 1

PAB_lum
by jya＠pipeline.com 17 Dec '03

17 Dec '03

3-4-96. WSJ: "U.S. Commission Recommends Staff Cuts at Intelligence Agencies." The most numerous cuts would be at the CIA, DIA and NSA. Former Sen. Warren Rudman said the super-secret NSA, which conducts various forms of electronic eavesdropping abroad, was most in need of a cut that could provide money for new computer-related technology and bring in people with new technical skills. 3-3-96. NYT: "Spy Pablum." [Editorial] After a year of study and high public expectations, the commission stepped up to this promising moment with all the spine of a rag doll. There is nothing radical about its report, which is precisely its problem. When it comes to the larger picture of just what kind of intelligence network America needs now that the cold war is over, and whether some agencies ought to be combined or eliminated altogether, the commission lacks imagination and courage. PAB_lum

1 0

Re: NYT on Crypto Bills
by pcw＠access.digex.net 17 Dec '03

17 Dec '03

Well, my first objection is that this law could become something like mail fraud. If the term "data coding" is used, it should be carefully defined. After all, this letter is coded in ASCII. My voice communications are digitized and coded by some algorithm defined by the phone company. -Peter

1 0

No Subject
by owner-cypherpunks＠toad.com 17 Dec '03

17 Dec '03

Adam Shostack writes: > > In suggesting key:// urls, I (without commenting) placed a path of > /s/telnetd/ in a URL. I was considering that a telnetd might need > many keys and associated documents, all of which could be found in a > directory. > > gateway's master telnetd public key. > daily keys > policy statements about who may connect, or how > etc > > I expect that we could extend the syntax in such a way that a URL > could contain most of the data we need. Thus, the default document > might be a 'cert of the day,' with possibly with references within the > certificate to the master telnetd key, the hosts master key. > > To expand, I was thinking of: > > key://foo.bar.com/{u,s,h,d}/family/instance While that would be useful in a lot of cases, I would hope that all that path gunk wouldn't be required.... most people would have one key, at least initially, and so a simple key://foo.bar.com/username/key.asc would be enough for them. I wouldn't want to prevent people from using your system, in fact it's a good idea. I just don't think that it should be required, just recommended. Something else to add would be a specifier for the type of key, i.e. key://slack.lne.com/pgp/ericm/key.asc The reason for the keytype specifier is obvious, so that the system can support more than just PGP keys. The problem with the above example is that the 'pgp' part is imbedded in the path. Since the apps that read these key URLS need to know which ones are for PGP and which for DH or DSS or whatever, the keytype specifier needs to be in a standard location in the URL. Suggestions? maybe key:/pgp/slack.lne.com/ericm/key/asc? Finally, a question: should the keyserver be able to serve keys in a way that is secure from a MITM attack, or can it depend on the certificate chain in the key certificate itself to validate the key certificate? I think it can, but I am not sure, so perhaps someone smarter than I can explain why, or why not. The attraction is obvious, if the key server doesn't have to validate the keys it serves, the whole problem of distributed key servers becomes much easier. -- Eric Murray ericm(a)lne.com ericm(a)motorcycle.com http://www.lne.com/ericm PGP keyid:E03F65E5 fingerprint:50 B0 A2 4C 7D 86 FC 03 92 E8 AC E6 7E 27 29 AF

1 0

Re: NYT on Crypto Bills
by mike＠fionn.lbl.gov 17 Dec '03

17 Dec '03

On Mar 4, 3:09pm, Adam Shostack wrote: > Markoff shouyld know better than this. There is a long > history of business use of codes & ciphers, going back hundereds of > years, and durring the heyday of the telegraph, there were fair size > companies that created codebooks with (locally configurable) > superencipherment systems for the market. I thought that, for the most part, the telegraph systems described above were to reduce cable charges (1 code word instead of a 15-word sentence, a huge savings in those days). Maybe it's the use to which the encoding's put that's controversial, not the (idea of) encoding itself.

3 2

Re: (Fwd) Gov't run anon servers
by Hal 17 Dec '03

17 Dec '03

I have run two remailers for about three years now, and I have never been contacted in any way by law enforcement or government people in relation to the operation of the remailers, or of any mail which has been sent through them. I get a fair number of complaints by private individuals, but I have never heard anything from the government. However, if I were a computer-savvy law enforcement agent, and I wanted to track messages through one of my remailers, I would try a technological approach. I would first break the key for my remailer. That is trivial. The passphrase is in PLAINTEXT in the script file which runs the remailer!. It has to be. That is true of all automated remailers. Anyone who can break into the remailer server and acquire root permission can find the remailer secret key. My keys have been unchanged for three years. Surely some enterprising hackers have stolen the keys by now. (That is why my keys are only < 512 bits.) Then the LEA has to insert mail-monitoring software somewhere either in the remailer system or on some connection to it. That is probably more difficult and may require cooperation from a system manager somewhere. I don't really know how hard it would be. But breaking the key is the easy part. Hal

2 1

Re: NYT on Crypto Bills
by pcw＠access.digex.net 17 Dec '03

17 Dec '03

>On Mar 4, 3:09pm, Adam Shostack wrote: >> Markoff shouyld know better than this. There is a long >> history of business use of codes & ciphers, going back >>hundereds of >> years, and durring the heyday of the telegraph, there were >>fair size >> companies that created codebooks with (locally configurable) >> superencipherment systems for the market. > >I thought that, for the most part, the telegraph systems described >above were to reduce cable charges (1 code word instead of a >15-word >sentence, a huge savings in those days). Maybe it's the use to >which >the encoding's put that's controversial, not the (idea of) encoding >itself. Yes, this is true, but the government still spent plenty of time getting a library of the standard libraries of commercial codes. There are books and books about these codes. Naturally, some were more oriented toward secrecy. Others were just so obscure that you needed the code dictionary to understand them.

1 0

Re: Duress
by jf_avon＠citenet.net 17 Dec '03

17 Dec '03

The transponder analogy might not be very accurate. When you fly in a controled airspace, the *controller* asks you to dial in certain digits on the transponder. If you do not dial them in, the controller will start harrassing you for doing it and for not complying and for entering airspace while unauthorized. You have to do it. depending on cockpit configuration, the hijacker might very well have no choice but to let the pilot do it. In any case, this is a situation where there are 3 persons involved (hijacker, pilot and controller) vs 2 in the duress case I would guess that most hijacks gets disclosed before they land because there are so many ways that the pilot could stego a help message in the flow of the numbers that are exchanged btwn him and the ground. JFA **** OLD KEY: USE ONLY FOR VERIFYING SIGNATURES **** 1024 bits Key ID:57214AED 1995/10/04 Jean-Francois Avon <jf_avon(a)citenet.net> 84 96 76 AE EB 7C AB 15 88 47 87 B0 18 31 74 9F

1 0

art-stego
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

The recent discussion "Chaff in the Channel" got me thinking about an alternative to hiding random bit streams in picture files. The goal of steganography, as I see it, is to provide plausible deniability. The problem with hiding bit streams is that you can never be sure if the opponent has developed an analysis technique to prove a particular file contains a suspicious bit pattern. The alternative to hiding bit streams is to not hide them. Use them to generate pretty pictures. For example, modify a fractal image generator to accept a bit stream as input. Use the bit settings to influence the values used to iterate the fractal function. You don't have to use fractals, any function that produces pretty pictures would probably work as long as there was a way to extract the bit stream from the final picture. Brute force would probably work fast enough for humans. One possibility is a screen saver that produces an "infinite" variety of pretty pictures by generating a pseudo-random bit stream and using it to help generate the next background picture. Occasionally, the picture might be so cool you will want to send it your friends or post it on the Net or just keep it around to look at. The goal is to create an innocent reason for passing around unique images that contain random bit streams so we don't have to worry if somebody finds the bit stream. If you live in a country that doesn't outlaw abstract art you have plausible deniability. Jim_Miller(a)suite.com

5 4