December 2003 - cypherpunks-legacy

re finney's perl scripts
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

hal sez , : The other errors you are getting are probably due to the difference : between binary and ascii I/O mode on DOS. I forgot about that : in my test script. Try this revision of pgppadt.pl, and let me know if : it works on DOS: works like a charm , thanks !

1 0

Creating commercial acceptability for remailers?
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

How can we convince _lots_ of people to run remailers, assuming it can be made technically painless? How can we spread remailer-operations beyond the cypherpunks and fellow travellers and the privacy/paranoia businesses like tax reduction and pharmaceutical retailers? Suppose you were in the "Get Connected To The Net" consulting business, and you wanted to include a remailer in the outside-the-firewall part of the mail handler - how would you get companies to accept it? What kinds of other businesses could benefit from providing anonymous service? Some ideas for non-mundane businesses - - Shrinks-r-us or other on-line recovery groups, beyond the current use in a.s.a.r.? - Tax advice - one-shot anonymous returns so you can ask questions from the IRS or whatever without much risk of audit? - Anonymous tips (the D.A.R.E. hotline?) Arrrgh. - Whistleblowers.com? (Who'd trust whistleblowers.gov?) - For one-way anonymity, perhaps MTV could run an "email from Beavis" server, letting you send rude comments to your friends. Digitally signed, with optional MIME noises! Sending mail through it might put your address in an email junk-mail marketing list, but without tying it to the outgoing message? But what about mundane businesses? I've seen suggestion boxes operated with minimalist anonymization for internal use (no attempt to obscure the time or prevent logging, just header-zapping.) University ombudsman's offices could be a good approach, and might help get around the occasional reactive sysadmins. But that's inside the firewall, though I suppose you could use them for outgoing mail as well. Another use for inside-to-outside remailers is to preserve the privacy of internal addresses, though that's more likely to need a service which replaces the originating headers with the real user's name, using some authentication to prevent forged email from the company president, etc. Any suggestions on getting companies to accept outside-to-outside-capable remailers on their gateways, or outside-to-inside? Anonymity is cool, heh,heh.. Beavis

1 0

Re: Zimmermann charges NOT dropped
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

At 9:04 PM 2/5/95, Timothy C. May wrote: >Anyway, my apologies. I sometimes think I am talking to the 20-30 of >you who post regularly, and can thus feel free to ask about a report >I've heard. But, as Hal Finney and others have also discovered, this >is not the case...boundaries are changing in cyberspace. Very true. I tend to forget that this list isn't just composed of the few co-conspirators I sometimes tend to believe to know so well from their postings. How was Monte Carlo? I used to live in Nice for some years and made it to Monte Carlo once in a while. <Hmm, haven't been in Europe for years, London is really nice in April. All the lawns are covered in daphodyls. Got to get some tickets tomorrow.> -- Lucky Green <shamrock(a)netcom.com> PGP encrypted mail preferred.

1 0

Mixmaster supports PGP
by lcottrell＠popmail.ucsd.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Just wanted to officially announce the Mixmaster supports pgp encrypted messages. I also want to plug using it as a second generation remailer (that is why I wrote it). If you use a sun (that means you netcom folks), get the front end from my home page. Raph, please change the "mix" entry in your list to reflect pgp support. Here is the Key: - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAy8y6PAAAAEEAJF05HUUQM4n9G5wHOZ+bHZbF6yFmeX5wBGElssHqUnbb4PQ S/f8jWvJyfiZkjlOkzOEJ47fZ++x+yYWgzKGUKp2ejIKu2MvnzgLfIkwKfxioPXq xgBpLcFaDrbM52Mi4MEpEYW4DJqxk9TrAnHZBwXmxpOZQ57UcgbmF1BLzawNAAUR tC5NaXhtYXN0ZXIgUmVtYWlsZXIgPG1peG1hc3RlckBuYXRlbHkudWNzZC5lZHU+ iQCVAwUQLzLpflVkk3dax7hlAQH2GQP9FGBU7uGako4YghrUNzyb3tcdwZwsGkBx Gy9MGojOSwWgXQ0CRLD9+IWgkZnRY902pU65C3IZhFB7erXBk5eyGOXhbahHv07o mhHRiE2v4Z9hNapWVHHeDo0F2AoL7B8kkiFjXI2fVYzofB6gmXd7X8Wzh/9AEQsz 63U8X9cbajyJAJUDBRAvMulXBuYXUEvNrA0BAQOkA/9QfgNGLp6MX1Qwk55uLiHG ajeT+Rtgruaj9DPOoZFVj9w0pImBkCQNw5eA6iZTgiAqkbSG7RaR9yKMU27Gf/O+ yz3cWAx4slFmCpVDlEl5qSa1Bd+2LuneN4EvnxfeI7TLUIFKlPcIOnx9zsu5Ny0I SCtHVHBaGw43OT1OYmLjgA== =Zr4D - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBLzXU7lVkk3dax7hlAQHsrgP9G0NyW4RDvWOXa5BiWnr9gk6+Yq0bW0v8 gXZcn3tyzy3VAarmk09JLZOCnIADP9/zZXVEhJsXGDH/2O2j8IzBCCewCv9DnFcq VnGtzwTHUdeLROSiOZYgwvhdtUgLdhB76c0akJhlNcVv7xMVEPRMqGtSMC/BPbTd d9xUaQz/ibk= =/0EA -----END PGP SIGNATURE----- -------------------------------------------------- Lance Cottrell who does not speak for CASS/UCSD loki(a)nately.ucsd.edu PGP 2.6 key available by finger or server. Encrypted mail welcome. Home page http://nately.ucsd.edu/~loki/ Check out my essay on the next generation remailer Mixmaster on the WWW page. For anon remailer info, mail remailer(a)nately.ucsd.edu Subject: remailer-help "Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come." --Nietzsche

1 0

Re: MD5 coding
by philip＠cs.brandeis.edu 17 Dec '03

17 Dec '03

> I seem to recall that md5 is explained pretty well in >Schneier. You may be doing this to learn, which is great, but you >might be pleased to know that there are several md5 programs already >available. Tripwire includes one, and there was one included in a >CERT/CIAC advisory last year. > > >Adam I need a version that will run on a Mac also which is the version I am putting together now. I know there are versions for DOS and other platforms but I specifically need to be able to run it on a Mac since the server I am producing is Mac-based. Philip Trauring --=--=====--=--=====--=--=====--=--=====--=--=====--=--=====--=--=====--=-- Philip Trauring Brandeis University MB1001 philip(a)cs.brandeis.edu P.O. Box 9110 (617) 736-5282 ['94/95] Waltham, Ma 02254-9110 --=--=====--=--=====--=--=====--=--=====--=--=====--=--=====--=--=====--=--

1 0

Re: The SKRONK protocols (version 0.6)
by strick -- henry strickland 17 Dec '03

17 Dec '03

THUS SPAKE Network Security Observations <NSO(a)delphi.com>: # Henry, # I would like to publish the working doc. in the next available issue Go ahead; I place the document in the public domain. # of Internet Security Monthly. Obviously with a request to respond. It would be kind if you sent me a copy of the issues that discuss it. I'm not familiar with the journal. If it's on paper, ask for my USPS address. # Do you have any further material that you prefer to go along with it ? Nope, that says what I have to say right now. The followup discussion on Cypherpunks has been helpful to me; the punks mostly made good points and correct observations. best regards, strick

1 0

Remailer msgs ideath -> rebma don't work.
by Greg Broiles 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Remailer messages sent via remailer(a)ideath.goldenbear.com to remailer(a)rebma.mn.org are failing; the system which handles my mail upstream can't seem to connect to rebma. I'm going to try to get things ironed out, but until then the ideath -> rebma path should be avoided. Sorry for any inconvenience; the bounced messages have been discarded. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLzXb4X3YhjZY3fMNAQErKgP+ND8r1sqXs3PXv87rL8IGTJ8j7FB4gmXI YwDC3jNWHdOimVoK0zJS8utCAk9VlUDW7azXjBuXs+1qpMiygG9Nr7Up8iGaejM4 sV8906vU/+Hq+Dvd/fZn1tkfL7dB8qKUMpi7aNFz0YbadCvE79MYzLBuzUVKCJTm j17jVq6tpX4= =C3mW -----END PGP SIGNATURE-----

1 0

Re: Legal implications of one-of-a-group guilt
by an448＠freenet.carleton.ca 17 Dec '03

17 Dec '03

>Well, I'm not so sure. DNA fingerprinting has soared in popularity for >criminal cases over the last decade or so. From the figures I vaguely recall >being quoted, such evidence of a DNA match narrows down a list of >suspects to a mere few hundred thousand people, and is commonly admitted into >evidence. This situation is reminiscent of that phenomenon, IMHO. > >I imagine that the looser standard of evidence in civil cases would make such >information quite significant in determining "the preponderance of evidence". > >It would be interesting to hear from some folks with legal training on this >issue, if only to correct my mistakes. IANAL. Well, I missed the beginning of this, but here's the general principle. Any evidence is admissible which makes it more likely that whatever you're trying to prove is true rather than untrue. For example, I want to prove that you stole my watch. I can prove that the thief is a man: since you are a man, this makes it more likely than before that you are the thief. It doesn't prove that you did it, but it goes in that direction -- it narrows it down. Okay? Now, here's the important corollary. If the jury is likely to give undue weight to the evidence, it can be inadmissible even though it would be admissible under the general principle. Lie detector tests are a good example of this, at least in Canada: they're not admissible, and the reason they're not admissible isn't because they don't prove with 100 % certainty, but because the jury is likely to think they're much more reliable than they actually are. Since I have no idea what the original topic was, I leave it to you to apply these general rules to your specific concern as an exercise. :-) Disclaimer: Since I'm in Canada, obviously I can't give any advice regarding US law. Regards, -- Yves Bellefeuille, Ottawa, Canada an448(a)freenet.carleton.ca (finger here for PGP key) ua294(a)fim.uni-erlangen.de

1 0

RE: Firewall chips
by Brian D Williams 17 Dec '03

17 Dec '03

>> Actually, there is a germ of truth in this. On older phones >>(don't know if this works on newer electronic phones) when the >>handset is 'on-hook' a switch opens and breaks the voice >>circuit. This of course only works for DC circuits. If you drive >>that same circuit with an AC signal . . . >There's another angle I may have mentioned before. Many >electronic phones come with a ``feature'' that allows you to >call home, produce an electronic tone and eavesdrop on your own >house. When the tone is sounded, the ringing stops (or never >starts) and the phone goes into ``off hook'' mode (i.e., the >microphone in the mouthpiece is turned on). >Even if you did not buy this feature when you bought your phone, >it is still there, just waiting for that electronic tone. You >can't produce it, because you didn't buy the doohickey, but anyone >with such a doohickey can call your house and listen in. . . > S a n d y >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Devices of this type are known generically as "infinity transmitters." They will not function anywhere the phone network is run by a digital (4ESS or better) switch. In a modern switch, the ringing you hear is being generated by the switch, the switch is simultaneously ringing the number you dialed, however the two are not physically connected. The actual connection is not made untill the far end answers, this was implemented to stop various types of fraud, and unauthorized eavesdropping. Brian D Williams Cypherpatriot

1 0

Frothing remailers - an immodest proposal
by Nathan Zook 17 Dec '03

17 Dec '03

kevin(a)elvis.wicat.com: >Be gentle, though - it's my first time. Here? You jest. ;) >It seems to me that the current remailer web suffers a fundamental flaw. >It is simply too static. When a remailer disappears, service is >disrupted and messages are lost. Humans have to statically route their >messages through the web either by hand or using relatively primitive >tools such as the chain script (not to belittle the useful work that has >been done, but it is by no means idiot proof yet). Basically, the >current web of mailers shows nothing of the dynamic nature that has kept >the internet alive and has offered us a decent chance at truly anonymous >communications, nor is it easy to use to its full potential. > >Consider a more dynamic web of remailers. I envision remailers that >actively advertise their presence on the web so that all active >remailers are aware of all other active remailers. This advertising is >to have very low latency so that a new mailer can be known to the web >within minutes (I will address the implementation of this later). Thus, >remailers can constantly be appearing and disappearing without impact on >the web as a whole (I refer to this dynamic web of remailers as a >"froth"). Imagine also that remailers are allowed to dynamically perform >the routing functions that are currently done statically offline (for >reasons I will discuss shortly). > Some version of this discussion came up a few months ago, and I passed on it then, but I think I've heard enough to comment now: The remailers are based on an inherently different model than the InterNet. Some of these differences, in fact, are crucial. 1) The InterNet is based on mutual cooperation/mutual trust. Cypherpunks trust no one that they don't have to. This is not just a result of our twisted psyche. If we could trust everyone, we wouldn't _need_ remailers. Since we don't even know who is whom out there, we avoid extending trust. 2) The InterNet is concerned first about reliability, and not at all about privacy. The remailers are concerned first about privacy, and can leave reliability to the users, if need be. There is nothing to prevent Alice and Bob agreeing to send each other ACK statements, and retransmitting messages if they don't get the ACK. There has been some mention of remailers doing the same with each other, in an attempt to improve net-wide reliability. BTW, with T1, sending ACKs is not unreasonable between remailers. 3) From 1) and 2). The remailers are heading towards mandatory PGP, possibly nested. All InterNet messages are world-readable--although this may be changing as the model breaks down. Again, this has to do with the intrinsic diffences. >The use of such transient routers implies allowing dynamic routing. If >any given remailer may go down or move at any point, it is impractical >to expect users to keep track of which are up at the moment and create >static routes in the current manner. The only reasonable solution I have >come up with is to allow the remailers themselves to choose routing, >given that they have full knowledge of the current state of the froth. Here we have the real head of the problem, as Hal so asutely points out: in your model, if the first remailer is bad, the message is compromised. If user encrypt to all remailers, they might as well encrypt directly to mole(a)snakeoil.nsa.gov. If they don't, they severly limit who can pick out their messages. In particular, they bypass transient remailers. But that isn't all. If the remailers pick the route, they are in a no better state than the users. Since the flushing attack requires remailers to operate on ticks, with carryover, an hour delay per remailer is almost minimal, untill traffic really picks up. So if some message routes through four remailers, a minimum of four hour delay results. In your case, this could easily move between in/out of service modes. > Think about the proposed extension to MixMaster to >allow separate parts of a multi-part message to be routed separately, >and consider whether you really want to have to do this by hand. I >strongly suspect that most messages are currently routed via boilerplate >scripts, which has to make the job of traffic analysis much easier for >our good friend Eve. Stupid is as stupid does. >By the way, a brief rant on a related topic; people speak of not >trusting remailers any further than necessary, while I am clearly >suggesting granting more authority and trust to the remailers. This >notion of not assigning trust is simply nonsense. When you send a piece >of mail to a remailer, encrypted or not, you are assigning complete >trust in that remailer to keep you anonymous and not to forward your >mail to the NSA immediately. NOT TRUE. With proper use of encryption, you are trusting your first remailer only to not reveal that you sent a message, and not to correlate that message to the one it sends out. With rational use of garbage running two deep, you can even suffer this loss without significant harm. >This does lead to a related problem, however; if we allow remailers to >pop up at random and join in the froth, how do we know that Deitweiller >won't set up a number of black hole remailers that take your mail and >throw it away, disrupting the froth, or forward it to nphard(a)nsa.gov? How indee The reason we chain is buse we _don't_ really trust our first remailer--or any other. >Fortunately, we already have the PGP web of trust model in place and can >use it to good effect in this case. Remailers should simply not route >mail through any remailer whose public key is not trusted unless >explicitly ordered otherwise. This requires remailer operators to >cooperate to some extent to validate one another's remailer keys, but >does confer the great advantage of portable remailers as mentioned >above; if I run a trusted remailer on one machine, I can move it to >another machine, and as soon as I advertise the new address and the PGP >public key, it is a trusted and useful part of the froth. Actually, there may be something here. I don't know about you all, but my PGP isn't very happy about all these new remailer keys. We could agree to the following standard: Signing a remailers' key means that you believe the remailer to be secure. Trusting a remailer key means trusting the remailer operator to validate other remailer's security. This adds a whole new meaning to the phrase, "key compromise certificate". >While we are advertising a PGP key and internet address, we might as >well incorporate other useful information. For instance, remailers could >advertise their maximum latency. While I agree that it is useful to post the operating characteristics of the remailers, the maximum latency must theoretically be infinite in the standard model to prevent flushing attacks. > Kevin Hal <hfinney(a)shell.portal.com>: >I do like Kevin's ideas about a dynamic remailer net, but I think >another approach would put more smarts into the client program used by >the originator. Hear ye, hear ye! And along those lines... I'm scetchy (at best) by what is meant by "pinging" a remailer. Would it not be possible for live-on-the-net remailers to accept a (socket?) quick check to see if they are online? If so, then the ping would only work if the remailer was active when tried. Furthermore, client software could startup by sending out these pings, and presenting only responding remailers to the user--with an exception list for those not "live". Nathan

1 0

Cooperation
by Nathan Zook 17 Dec '03

17 Dec '03

Hal: I agree that it is to our advantage to minimize the cooperation between remailers, for the following reasons: 1) The existance of a cabal dominating such a function admits the posibility of the abuse of power, for whatever reason. 2) The requirement of cooperation between remailers limits the size of the remailer net to the number of operators that can effectively cooperate with each other. (Yes, we can extend via overlapping groups, but this introduces chokepoints--another weakness.) 3) The requirement of cooperation between remailers raises the cost (in time and legal vulnerabilities) to enter the remailer net. 4) Failing all of these, there is a real chance (happening even now) that users will trust the operators too much. But there is a major difference between active cooperation and agreeing to a standard. Active cooperation is just that--something which cannot be automated, or which involves automated judgement decisions. I claim that my ideas are merely standards. A standard which might even be extendable into the dominions of a hostile government. Nathan

3 2

Re: lwall
by Usenet Autoresponder 17 Dec '03

17 Dec '03

DO NOT PANIC! REMAIN CALM! READ *ALL* OF THIS MESSAGE BEFORE GETTING UPSET! Your Usenet test article was received here at the news gateway machine for NetNet, Inc. in Green Bay Wisconsin. We provide wholesale internet services for all kinds of services for internet providers and end-users. From WWW pages, newsfeeds, telnet accounts, ppp services, to fully maintained POP's in your area. For sales info please address sales(a)netnet.net. Technical and news support to shane(a)netnet.net For an auto-reply of gereral services and prices email info(a)netnet.net If you're a newsadmin and you'd like to run your own autoresponder, this one is available from ftp://ftp.cccd.edu/pub/usenet/innautorespond. If you want to suppress this message in the future, include the word "ignore" in the Subject: header of any subsequent articles posted to *.test. You could also post your test articles with a Distribution: header of "local" to prevent them from leaving your local machine, or you could also ask your local newsadmin to create a local *.test group that will not propagate outside of your organization. There are typically 5 possible reasons why you were sent this e-mail message: 1) You intentionally posted a Usenet news article to a *.test newsgroup. These newsgroups exist so you can verify that your articles are being propagated correctly. When your article arrives here, we send you this message as confirmation. We will only send you ONE e-mail reply for each of your test articles that we see. 2) You unintentionally posted a Usenet news article to a *.test newsgroup. This is a bit of net.childishness caused by a Followup-To: header directing all replies into a *.test newsgroup. This is done by somebody upset with the content of a discussion thread who wants to "punish" anybody who replies to his message. Your reply will be sent to *.test instead of the original newsgroup, and you will start receiving autoresponder messages similar to this one that you didn't ask for. To avoid this in the future, look for a Followup-To: header and make sure it's appropriate before replying to any articles. 3) You were a victim of a Reply-To: header directing your e-mail into a *.test newsgroup via a mail->news gateway. Similar to 2) above. 4) Somebody has forged a posting in your name to one of the *.test newsgroups. To avoid this in the future, use better net.etiquette and you will make fewer net.enemies. If you want to try and identify the forger, use the following procedure. Make a legitimate posting to the same *.test newsgroup that the forger used. We will send you an e-mail reply. Compare the Path: header from this legitimate reply with the Path: header from the forgery. The front part of the two headers will be the same or topologically similar path to your site. Where the forged header becomes substantially different can provide clues to where the forger lives. Note that if you receive multiple newsfeeds you may need to repeat this process several times so you can discover all legitimate paths between our site and yours. Once you think you've identified the forger's site, try sending POLITE e-mail to the newsadmin/ sysadmin/postmaster explaining the situation. 5) You issued a cancel control message to a *.test newsgroup. Some users dislike autoresponses for cancel messages, but the newsadmins here think it can be a valuable diagnostic tool for verifying cancel propagation. If you don't like it, use the "delete" key in your mail client! All headers plus at most 10 lines of user text from your original article are reproduced below for your perusal: questions to shane(a)netnet.net complaints to /dev/null ------------------------------- your post follows ---------------------------- Path: netnet2.netnet.net!news.sprintlink.net!howland.reston.ans.net!agate!overload.lbl.gov!emf.emf.net!hilbert.dnai.com!nbn!miwok!news.zeitgeist.net!ack.berkeley.edu!not-for-mail Subject: lwall Message-ID: <PINE4545-dhfsdkjc(a)ack.berkeley.edu> NNTP-Posting-Host: ack.berkeley.edu Organization: cypherpunks Lines: 2 From: cypherpunks(a)toad.com Distribution: world Newsgroups: alt.test Date: 6 Feb 1995 19:34:19 GMT test test

1 0

Change to the congressional contact list
by Samuel Kaplin 17 Dec '03

17 Dec '03

The congressional fax/phone list that I recently posted has at least one error in it. Senator Rod Grams' fax number is (202) 228-0956. The amended list will be available on the auto-responder in about 15 minutes. To get a copy: Send a message to: skaplin(a)c2.org With the subject: SEND FILE congresscritter.104 You should get it within two hours. Sam

1 0

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, 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.30.tar.gz For the PGP public keys of the remailers, as well as some help on how to use them, finger remailer.help.all(a)204.95.228.28 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{"vox"} = "<remail(a)vox.xs4all.nl> cpunk pgp. post"; $remailer{"avox"} = "<anon(a)vox.hacktic.nl> cpunk pgp post"; $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{"rebma"} = "<remailer(a)rebma.mn.org> cpunk pgp hash"; $remailer{"c2"} = "<remail(a)c2.org> eric pgp hash"; $remailer{"soda"} = "<remailer(a)csua.berkeley.edu> eric post"; $remailer{"penet"} = "<anon(a)anon.penet.fi> penet post"; $remailer{"ideath"} = "<remailer(a)ideath.goldenbear.com> cpunk hash ksub"; $remailer{"usura"} = "<usura(a)replay.com> cpunk pgp. hash latent cut post"; $remailer{"desert"} = "<remail(a)desert.xs4all.nl> cpunk pgp. post"; $remailer{"nately"} = "<remailer(a)nately.ucsd.edu> cpunk pgp hash latent cut"; $remailer{"myriad"} = "<remailer(a)myriad.pc.cc.cmu.edu> cpunk pgp hash latent cut ek"; $remailer{"xs4all"} = "<remailer(a)xs4all.nl> cpunk pgp hash latent cut post ek"; $remailer{"flame"} = "<tomaz(a)flame.sinet.org> cpunk pgp hash latent cut post ek"; $remailer{"rahul"} = "<homer(a)rahul.net> cpunk pgp hash"; $remailer{"mix"} = "<mixmaster(a)nately.ucsd.edu> cpunk hash latent cut ek"; $remailer{"q"} = "<q(a)c2.org> cpunk pgp hash latent cut ek"; $remailer{"syrinx"} = "<syrinx(a)c2.org> cpunk pgp"; $remailer{"tower"} = "<remailer(a)tower.techwood.org> cpunk pgp"; $remailer{"eniac"} = "<vanklava(a)eniac.ac.siue.edu> cpunk pgp hash latent cut"; $remailer{"charon"} = "<charon(a)styx.jpunix.com> cpunk hash latent cut ek"; $remailer{"bonafide"} = "<remailer(a)bonafide.jpunix.com> cpunk hash latent cut ek"; $remailer{"ford"} = "<ford(a)prefect.jpunix.com> cpunk hash latent cut ek"; $remailer{"aegis"} = "<aegis(a)athena.jpunix.com> cpunk"; catalyst(a)netcom.com is _not_ a remailer. lmccarth(a)ducie.cs.umass.edu is _not_ a remailer. JPUNIX.COM offers a domain hiding service for remailers. Send email to perry(a)jpunix.com for more information. NOTE: JPUNIX.COM itself does not run a remailer. All subdomains of jpunix.com on this list are remailers that are not physically located on jpunix.com Use "premail -getkeys remailer.help.all(a)204.95.228.28" as a stopgap to get PGP keys for the remailer, at least until Matt Ghio gets his machine situation straightened out. Fingering this address works too. Last ping: Mon 6 Feb 95 6:00:01 PST remailer email address history latency uptime ----------------------------------------------------------------------- rahul homer(a)rahul.net -*+****#-*+# 19:19 99.88% alumni hal(a)alumni.caltech.edu +****-*##* # 9:02 99.87% eniac vanklava(a)eniac.ac.siue.edu #***+#***# 6:06 99.88% penet anon(a)anon.penet.fi *+**+*+++-+* 1:40:22 99.99% tower remailer(a)tower.techwood.org *********# 7:38 99.88% mix mixmaster(a)nately.ucsd.edu --*-++++++++ 43:06 99.85% nately remailer(a)nately.ucsd.edu --++++++++++ 41:00 99.85% portal hfinney(a)shell.portal.com +***#-*##* # 6:53 99.85% xs4all remailer(a)xs4all.nl **-*+++**+** 16:46 99.75% charon charon(a)styx.jpunix.com #-++-* 26:06 99.78% bonafide remailer(a)bonafide.jpunix.com ##**** 6:39 99.68% ford ford(a)prefect.jpunix.com ++-+++ 27:13 99.67% soda remailer(a)csua.berkeley.edu .--.._..... 9:02:42 99.56% myriad remailer(a)myriad.pc.cc.cmu.edu +***-****** 37:47 99.37% vox remail(a)vox.xs4all.nl ...---..-- 22:10:50 99.51% usura usura(a)replay.com *+-****+ *** 15:05 98.98% aegis aegis(a)athena.jpunix.com 15:55 99.07% c2 remail(a)c2.org +++ - ++-+++ 1:44:28 97.95% syrinx syrinx(a)c2.org *** +++-* 30:09 97.85% q q(a)c2.org --+--+++-++ 1:13:16 97.75% flame tomaz(a)flame.sinet.org +***-****** 59:14 97.51% bsu-cs nowhere(a)bsu-cs.bsu.edu ***+ *--**-* 1:38:08 96.72% ideath remailer(a)ideath.goldenbear.com --------- -- 2:04:17 95.12% desert remail(a)desert.xs4all.nl .-___.-_.- 48:16:44 68.02% rebma remailer(a)rebma.mn.org _.-_--- 21:10:27 41.53% extropia remail(a)extropia.wimsey.com 5:04:09 6.34% For more info: http://www.cs.berkeley.edu/~raph/remailer-list.html 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). Options and features 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. oldpgp Remailer does not like messages encoded with MIT PGP 2.6. Other versions of PGP, including 2.3a and 2.6ui, work fine. 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. special Accepts only pgp encrypted messages. ek Encrypt responses in relpy blocks using Encrypt-Key: header. Raph Levien

1 0

Re: Vinge on PKE ? (really idiot savants)
by Jonathan Corbet 17 Dec '03

17 Dec '03

> These so-called "idiot savants" can easily factor > 100 digit numbers. The ability to solve such problems is not tied to IQ, > as there are many such people with IQs of 150+ who cannot solve them. Gee...such a person could do a pretty thorough job on a 512-bit RSA key. How many of them do you suppose the NSA employs? :-) jon

1 0

Camden New Jersey
by an158409＠anon.penet.fi 17 Dec '03

17 Dec '03

I thought nothing but armed robberies happened in Camden New Jersey. Teenage Pirate To Pay $25,000, Loses BBS Equipment CAMDEN, NEW JERSEY, U.S.A., 1995 FEB 3 (NB) -- A teenage computer operator charged with illegally distributing hundreds of copyrighted commercial software programs has reached a settlement with Novell Inc., (NASDAQ: NOVL) and Microsoft Corp., (NASDAQ: MSFT). The settlement requires the operator of the now-defunct Deadbeat Bulletin Board to pay $25,000 to Novell and Microsoft and forfeit the equipment he used to run the board to the two software makers. The agreement apparently closes the book on an investigation of the New Jersey computer BBS (bulletin board service), which authorities said contained several hundred commercial software products. The equipment was seized in an August raid of the board. This was just one of the cases investigated under an aggressive joint campaign by Novell and Microsoft to locate and prosecute pirate system operators. The project was mounted last summer and has already resulted in the closing of two bulletin boards. The two companies said they expect more seizures in the near future. Pirate bulletin boards let users download commercial products, paying for them in money or in barter by uploading programs the BBS doesn't have. According to Novell the Deadbeat Bulletin Board also contained several beta files, software which is still in the testing stage. Beta programs are often incomplete or contain problems, and are distributed to a limited number of users so those problems can be worked out before the final product comes to market. Novell and Microsoft investigators said they first got wind of the illegal software in late July, and eventually discovered more than 60 Novell and Microsoft products on the board. A court ordered seizure of the equipment and the raid was carried out in August. The court records have been sealed until now. The agreement also prohibits Microsoft and Novell from any further action against the 17-year old boy and from releasing his name. (Jim Mallory/19950203/Press contact: Jessica Jersey, Novell, 408-577-8739; Public contact: 800-785-3448 or 800-747-2837 to report suspected software piracy) ------------------------------------------------------------------------- To find out more about the anon service, send mail to help(a)anon.penet.fi. Due to the double-blind, any mail replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin(a)anon.penet.fi.

2 1

CFP'95 Program/Registration Information (fwd)
by Michael Froomkin 17 Dec '03

17 Dec '03

---------- Forwarded message ---------- Date: Sun, 05 Feb 1995 12:43:36 -0500 From: Carey Heckman <ceh(a)leland.Stanford.EDU> To: Multiple recipients of list <cyberia-l(a)birds.wm.edu> Subject: CFP'95 Program/Registration Information The Fifth Conference on Computers, Freedom and Privacy Sponsored by: * ACM SIGCOMM, SIGCAS, SIGSAC, and * Stanford Law School 28 - 31 March 1995 San Francisco Airport Marriott Hotel Burlingame, California CONNECT WITH OTHERS WHO ARE DETERMINING HOW COMPUTERS AND TELECOMMUNICATIONS WILL AFFECT YOUR FREEDOM AND PRIVACY... JOIN US AT CFP'95. We have reached the crossroads of the Information Age. No longer is the electronic frontier inhabited solely by a small band of technical pioneers sharing a common code of conduct. Computer and telecommunications technologies have become part of mainstream living, conversation, and politics. These changes compel us to reexamine the definition of our rights and the processes by which those rights are being defined. The Fifth Conference on Computers, Freedom and Privacy will assemble experts, advocates and interested people from a broad spectrum of disciplines and backgrounds in a balanced public forum to explore and better understand the definition of our rights at this crossroads. Participants will include people from the fields of computer science, law, business, research, information, library science, health, public policy, government, law enforcement, public advocacy, and many others. Featured speakers include: John P. Morgridge, Chairman, Cisco Systems Esther Dyson, Release 1.0/EDVenture Holdings, Inc. Roger W. Wilkins, Professor of History and American Culture at George Mason University and commentator, National Public Radio Margaret Jane Radin, Professor of Law, Stanford University Willis H. Ware, RAND Some of the topics in the CFP'95 program include: FREEDOM AND RESPONSIBILITY OF ELECTRONIC SPEECH -- Exploring recent controversies in online free speech, including a Socratic forum that will ask whether the Constitution can indeed be viewed through a technologically transparent lens. HIS MASTER'S VOICE... -- Probing the future for "net propaganda" from governments, government officials, and politicians, and who will pay so whose message will get to whom. STUDENT DATABASES: FOR EDUCATION AND FOR LIFE? -- Looking at how gaining the benefits of nationwide information about K-12 students could also spell serious privacy problems. CAN THE NET SURVIVE COPYRIGHT? CAN COPYRIGHT SURVIVE THE NET? -- Delving into the controversies surrounding copyright protection that throttles freedoms and copyright protection that protects just rewards for creativity. INTELLIGENT TRANSPORTATION SYSTEMS: PAVING OVER PRIVACY -- Examining the privacy implications of tracking and surveillance technologies now being planned for vehicles and roadways nationwide. "IT OUGHTA BE A CRIME..." -- Debating with law enforcement representatives about who should set the rules for governing the net and when should bad manners become a crime. WHEN DO THEY NEED TO KNOW 'WHODUNNIT'? -- Discussing the right time and places for identified, anonymous, and pseudonymous transactions. TRANSACTION RECORDS IN INTERACTIVE SERVICES: WHO WATCHES THE SERVERS? -- Looking at the issues raised by the collection of personal information as part of the new interactive home entertainment, telecommunications, and online services. DEFINING ACCESS PARADIGMS: LIBRARIES, RURAL AREAS, AND INTERNATIONAL ASPECTS -- Evaluating the differing models of "open access" to Internet and computer-mediated communications in the library, rural, and lesser-developed country contexts. THE CASE AGAINST COMPUTERS: A SYSTEMIC CRITIQUE -- Daring to discuss whether computers may be doing our world more harm than good. A NET FOR ALL: WHERE ARE THE MINORITIES? -- Examining how and to what degree minority groups participate on the net and asking whether social class is relevant to net participation or non-participation. WHO OWNS THE LAW? -- Reviewing the debate over legal citation form and online databases, and what it means to all of us. CAN WE TALK LONG-DISTANCE? REMOVING IMPEDIMENTS TO SECURE INTERNATIONAL COMMUNICATIONS -- Covering export and import controls, outright prohibitions, and other technical and policy obstacles to secure international communications. The Fifth Conference on Computers, Freedom, and Privacy will also offer a number of in-depth tutorials on subjects including: * Inside Washington: The New Congress and Secrets of Advocacy * National ID Card Initiatives * The Law of Fundamental Rights for Non-Lawyers * Everything You Need to Know to Argue About Cryptography * Digital Activism * Inside the World of Law Enforcement * Intellectual Property for the Information Age FOR MORE INFORMATION ABOUT CFP'95: Web: http://www-techlaw.stanford.edu/CFP95.html Gopher: gopher://www-techlaw.stanford.edu/CFP95 FTP: ftp://www-techlaw.stanford.edu/CFP95 Email: Info.CFP95(a)forsythe.stanford.edu Fax: (415) 548-0840 Call: (415) 548-9673 REGISTRATION Please register for the conference by returning the conference registration form along with the appropriate payment by any method listed below. The registration fee includes conference materials, three luncheons (Wednesday, Thursday, and Friday), two banquets (Wednesday and Thursday) and evening receptions (Tuesday, Wednesday, and Thursday). Registration Fees are: If mailed by: February 24 March 14 after 14 March Conference Fees $335 $395 $445 Tutorial Fees: $155 $185 $220 Registration is limited to 550 participants, so register early and save! By Mail: By Fax: (with Check or Credit Card) (with Credit Card only) CFP'95 Registration Send Registration Form P.O. Box 6657 (415) 548-0840 San Mateo, CA 94403 Available 24 hours By Phone: By Email (at your own risk*): (with Credit Card only) (with Credit Card only) (415) 548-0840 Register.CFP95(a)forsythe.stanford.edu 9 am to 5 pm Pacific Time * Information for sending a PGP-encrypted registration available at http://www-techlaw.stanford.edu/CFP95.html and ftp://www-techlaw.stanford.edu/CFP95. CFP'95 Scholarships: The Fifth Conference on Computers, Freedom and Privacy will provide a limited number of full registration scholarships for students and other interested individuals. These scholarships will cover the full costs of registration, including three luncheons, two banquets, and all conference materials. Scholarship recipients will be responsible for their own lodging and travel expenses. Persons wishing to apply for one of these fully-paid registrations should contact CFP'95 Student Paper and Scholarship Chair, Gary Marx at: Gary.Marx(a)colorado.edu or call (303) 492-1697. Hotel Accommodations: The Fifth Conference on Computers, Freedom and Privacy will be held at the San Francisco Airport Marriott Hotel in Burlingame, CA. This facility is spacious and comfortable, and is easily accessible from the airport and surrounding cities. Because of the intensive nature of the conference, we encourage our attendees to secure their lodging at the conference facility. Special conference rates of $99/night, single or multiple occupancy, are available. ************************************************************************* * Our room block is limited and these conference rates are guaranteed * * only until February 17,1995, so we urge you to make your reservations * * as early as possible. * ************************************************************************* After February 17 but before March 15, the special conference rate will be $110/night, single or multiple occupancy. When calling for reservations, please be sure to identify the conference to obtain the conference rate. Hotel Reservations: (415) 692-9100 or (800) 228-9290 or fax (415) 692-8016. Official Airlines: Special convention airfare discounts have been arranged on American and United Airlines. Bungey Travel, (800) 286-4391 or (415) 325-5686 or fax (415) 321- 5309, will be happy to assist you in any manner. Please identify yourself as attending the Computers, Freedom, and Privacy Conference and you will automatically receive a 5% discount off nonrefundable discounted US tickets or 10% off of all unrestricted US coach fares.

1 0

Re: Cooperation
by Hal 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- From: Nathan Zook <nzook(a)bga.com> > I agree that it is to our advantage to minimize the cooperation between > remailers, for the following reasons: > [...] > But there is a major difference between active cooperation and agreeing to > a standard. Active cooperation is just that--something which cannot be > automated, or which involves automated judgement decisions. I claim that > my ideas are merely standards. A standard which might even be extendable > into the dominions of a hostile government. I see your point. I tend to have something of a knee-jerk reaction against proposals which put more responsibility into the hands of the remailer operators, but as you say the mere promulgation of a standard does not in itself require cooperation. We have de-facto standards right now, which is what makes chaining possible. And from the technical point of view, the idea of remailers encrypting between themselves seems to do no harm and could possibly make the attacker's job potentially more difficult by reducing the amount of information he has available. One problem is that one remailer may not know about all of the others. So to the extent that your proposal requires a registry of remailers, a centralized service which keeps track of all remailers, I still have a problem. This is where my vision departs from those who see the "remailer net" as an entity, and for whom the notion that remailers would treat messages to each other specially is a natural assumption. If you would suggest that at each stage the message included not only the address of the next remailer, along with the "payload" which was already encrypted (by the sender) for that remailer, but in addition a key for that remailer and a request to encrypt under that key, then I would feel much better about it. This way there is no need for the remailer to know anything about whom it is sending to. Likewise if we wanted to specify in the standard that messages could be signed, that also would not imply collusion. However to specify that signatures must be checked would have some implications about acquiring the necessary public keys through some means, and I don't think that should be done. I do like the idea of standards. In fact I wonder if the current "mark 1" remailer command set shouldn't be documented as an Internet RFC. It has been in use for a couple of years now, evolving somewhat over that time, and some twenty or thirty remailers have operated for some part of that time following that spec. It would also give a certain amount of (undeserved, perhaps) respectability to remailer operators if there were an actual numbered RFC which they were following. And it does seem to me that this kind of thing is exactly what the RFC's are for. Certainly there are a great many "minor" RFC's which are less followed than our remailer standards. Hal -----BEGIN PGP SIGNATURE----- Version: 2.6 iQBVAwUBLzZTfBnMLJtOy9MBAQFsRwIA4A5EzFZwJdEmSvcfMmnu+RCAEGYK56dg y2LBawLdYn5FNcnvH6YkfCMHIcWURm1b6emEsw32FVH2m6ScAAH/iQ== =F2+s -----END PGP SIGNATURE-----

5 5

Re: dna ink
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

At 10:30 PM 2/5/95, Dan Harmon wrote: >I just saw an item on CNN about a company in LA called Art Guard. It >sells an ink that is created using your dna as a protection against >forged signatures. Why not just sign in blood? -- Lucky Green <shamrock(a)netcom.com> PGP encrypted mail preferred.

3 2

MD5 coding
by philip＠cs.brandeis.edu 17 Dec '03

17 Dec '03

I am looking to put together an MD5 message digest program and have extracted the MD5.c and MD5.h files from PGP(excerpt of the MD5.h file below) but I'm not sure how it all works. Can someone who is familiar with the functions and the data structure please e-mail me with a bit of guidance as to what each one does and how to implement it. If anyone can lead me to a good description of the processes involved I would appreciate that too. Thanks. ----====---- struct MD5Context { uint32 buf[4]; uint32 bits[2]; unsigned char in[64]; }; void MD5Init(struct MD5Context *context); void MD5Update(struct MD5Context *context, unsigned char const *buf, unsigned len); void MD5Final(unsigned char digest[16], struct MD5Context *context); void MD5Transform(uint32 buf[4], uint32 const in[16]); ----====---- Philip Trauring --=--=====--=--=====--=--=====--=--=====--=--=====--=--=====--=--=====--=-- Philip Trauring Brandeis University MB1001 philip(a)cs.brandeis.edu P.O. Box 9110 (617) 736-5282 ['94/95] Waltham, Ma 02254-9110 --=--=====--=--=====--=--=====--=--=====--=--=====--=--=====--=--=====--=--

3 2

To Bundle Or Not To Bundle?
by jltocher＠CCGATE.HAC.COM 17 Dec '03

17 Dec '03

From Edupage: TO BUNDLE OR NOT TO BUNDLE? THAT IS THE MICROSOFT QUESTION One of the fears Microsoft rivals have is that Microsoft will build directly into the Windows operating system various applications software packages (such as encryption for financial processing over the Internet), because customers would be reluctant to pay for products that do more-or-less the same thing as an installed product that they get "for free." Although it's unlikely that the government would consider breaking Microsoft up into separate companies, it is conceivable that it could force Microsoft to limit what it includes with its operating systems. (The Economist 1/28-2/3/95 p.61) John L. Tocher THE CITY-a bounded infinity. A labyrinth where JLTocher(a)earthlink.net you are never lost. Your private map where every PGP: CE 72 1A 11 07 47 35 block bears exactly the same number. Even if you 35 9A C1 DE EA 64 21 BC 94 lose your way, you cannot go wrong. --Kobo Abe

1 0

Child Porno
by Ben 17 Dec '03

17 Dec '03

Just heard on the radio "How child pornographers are using the 'Net to turn your home computer into their playground and why you can't do anything because of lax and permissive legislation." All this over some very discordany chords to make it seeem more ominous. Gotta love the evening news here in CT. >From the same people that had a feature of 'MArtial arts weapons as weapons of mass destruction and how easy they are to get.' I wonder if the producer is a closet facist or a ratings freak. Ben.

1 0

Selection key crypto protocol trial balloon
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

Before replying to Tim's comments on Mike Ingle's new directions for anonymity which, I think, are based on a misunderstanding of what Mike was essentially positing, here's my (slightly lengthy) take on the Selection Key Crypto protocol. Please read it before criticising, as I've already done that... Mp is the plaintext message. Alice encrypts it with Bob's public key: Mc = E.kpub (M) [1] She sends Mc to Hermes, the Hoarder of Messages. Hermes also receives Alice's identity string (Ia) which will probably be anonymous, but let's assume it's not. Now's the tricky bit. Hermes adds Mc to its message store, S: S' = G (S, Mc) [2] The key here is G, the Digest function, which has to spread M over S (with a variation of the Fourier function, perhaps), and not just append it, so that the _only_ way it can be extracted is with Bob's selection key, which Bob transmits to Hermes along with an involuntary identity string (Ib) to get: Mx = H.ksel (S') [3] where H.ksel is the Regurgitate function applied with Bob's selection key, and Mx is _not_ the original encrypted message, Mc, nor the plaintext Mp. Finally Bob decrypts Ms with his _private_ key (or possibly a variation, which we'll call v(kpri)), to get the plaintext: Mp = D.v(kpri) (Ms) [4] So the possible crypto operations are: Mp = D.kpri (E.kpub(Mp)) Mp = D.v(kpri) (Mx) where v(x) may be = x Mx = H.ksel (S') And the Digest function, S' = G (S, E.kpub(Mp)) Note that only the private key kpri, and its variation v(kpri) are private. The other two are public. Now for the obvious criticisms: 1. after [1] Hermes can store Alice's identity (Ia) in a dark grey dossier, and match it to Bob's identity (Ib) and the extracted message (Mx). Nope. The premise of this scheme is that Mx doesn't look like Mc at all, and that G (in [2]) dissolves the original message into a sludge, from which Mx somehow emerges, NOT that it chops Mc into bits with Ia on a little nametag 2. after [1] Hermes can store Ia along with the message and feed [Mc, Ia] to [2] in the hope that it will reappear in [3] as [Mx, Ia']. Well, the digest function has prevent this, possibly by making the regurgitated thing so different from the input that matching Ia to Ia' will be impossible. Of course, Bob probably won't grok [Mx, Ia'] in [4] 3. Hermes gets Bob's identity string (Ib) in [3]. Et alors? As that is incidental, not required to extract the message (unlike in a remailer, where that identity string - e-mail address, return block, whatever is _precisely_ what is required for a message to reach), it's irrelevant. The _real_ identity is the selection key, which does not correlate to any cyberspatial location. See further on traffic analysis. 4. ksel, Bob's selection key, is obviously not private, at least not to Hermes, and may as well be public. So anyone can extract the message intended for Bob (which reinforces my previous point that Ib is irrelevant). But what they extract is Mx, which is not the plaintext. To get the plaintext you need not the selection key but Bob's private key, which only Bob has. 5. The Digest function [2-3] has to be robust, i.e. it shouldn't puke if it's got lots of messages, and should be able to extract the right one in any state. Well, yes, that's tough. Traffic analysis The difference between the SKC model and remailers Alice --> (Raven, the remailer net) --> Bob .... multiplied ad infinitum Alice --> (Hermes) --> Bob --> Carol, David, the whole world as the selection key is public The remailer net is essentially one-to-one, making traffic analysis easier and limiting Bob's deniability - if the last remailer says it's gone to Bob, it was _for_ Bob. The broadcast model essentially increases deniability - they all got it, any of them could have seen it if they had the key, and you'll only know that I had the private key with thumb-screws. But they all _get_ it, so bandwidth is huge. The SKC model is a compromise. It increases deniability - anyone could have got it, they all have the selection key, they could only have seen it with the private key etc. It cuts bandwidth. But it's not a data haven, at least not as earlier discussed. The data haven in its latest guise has the same deniability as SKC, and the same prerequisites that aid recipient protection (anon anon ftp etc). But it doesn't protect the sender. If the haven is in collusion with remailers that Alice used to post, it can link her to the message and possibly to Bob. With SKC, even with the collusion of remailers the link gets lost in digestion. Also, Bob (or anyone) can frequently extract stuff with the selection key, perhaps garbage if Hermes is misbehaving or without messages for Bob. Of course when (and how) Hermes is to expire messages is part of the problem of the various functions involved. Comments? ----------------------------------------------------------------------------- For Electric Dreams subscriptions and back issues, send a mail to rishab(a)arbornet.org with 'get help' as the message Subject. Rishab Aiyer Ghosh rishab(a)dxm.ernet.in rishab(a)arbornet.org Vox +91 11 6853410 Voxmail 3760335 H 34C Saket, New Delhi 110017, INDIA

1 0

Re: Cooperation
by jrochkin＠cs.oberlin.edu 17 Dec '03

17 Dec '03

At 3:43 PM 02/06/95, Perry E. Metzger wrote: >I'd say that it would work far better if things were changed to MIME >formats. You would send a message by recursively encapsulating your >message to be remailed inside a MIME message. Simple and clean... Well... perhaps for a future remailer standard. I think the purpose of an RFC at this point is to clearly outline how it is that present remailers work, and standardize the working somewhat, and provide a document for people writing new remailers to look at to make sure their remailers work like everyone elses (or are a superset of the "Standard Type 1 Remailer" functions, a superset which certainly could include MIME or anything else). The point is to accurately describe how most remailers work now, rather then propose a major change in the way most remailers work. The latter has a place, but the former seems more pressing, as well as easier to do, and perhaps a first step to the latter. Changing "Request-Remailing-To:" to "Anon-Send-To:" is trivial, in that it would be an incredibly minor code change, and in that some remailers already implement "Anon-Send-To:". But changing everything to MIME would not be so trivial, and if we published a "standard" that said to do it with MIME, we'd end up with a standard that in fact no one follows, that doesn't accurately describe the way things are. The remailers are definitely evolving, and it's been mentioned that it might be a good idea to have a Type 1 Remailer standards document, and a Type 2 Remailer standards document, etc. But it seems of primary importance to first publish a standard of how the remailers _are_ (Type 1 remailer), instead of how we might wish they could be. (Type 1 remailer with MIME, Type 2 remailer, whatever). As for the idea of using MIME headers in itself, I'm a bit concerned that it might make it overly complicated to put together a to-be-remailed message by hand. I'm not entirely familiar with MIME and recursive encapsulation of MIME, so my concern might be ungrounded. But I think it might be a Good Thing that it's easy to remail a message by hand by adding a simple "::\nAnon-Send-To:" at the top, and it would be a mistake to make it more complicated or dificult to do this by hand, unless it's really neccesary for some reason.

1 0

Re: "encrypt tcp connections" hacks
by Johnathan Corgan 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >It's certain that IP security will greatly increase the overall >security of the Internet. I'm not advocating its removal but rather >the acknowledgement that higher (and lower) level abstractions will >require their own cryptography. This resolves to a layered quality-of-service issue. Encryption and authentication at the network layer provides an excellent base for improving security, and in and of itself solves a lot of problems like packet payload sniffing, session stealing, etc. But as you so aptly point out, trust boundaries do not coincide with network boundaries. Applications that "ride" on top of TCP and UDP may have their own, very different, threat models. And sniffing the physical layer provides most of what you need for traffic analysis unless some sort of sophisticated packet laundering is used. You pointed this out to me at the last cpunks meeting--each layer in the network model needs to be able to ask for and use security facilities in the lower layer, as well as advertise its security features to the next layer up. Of course, it is perfectly reasonable for me to expect to write an email, encrypt it with PGP and send it via an encrypted SMTP protocol to my mail gateway. On its way, it will ride on top of an encrypted TCP session to port 25, with the physical T1 link between my site and the internet encrypted as well. This is an example of security features present at most of the layers between 1 and 7 of the OSI model. These should remain independent. == Johnathan Corgan "Violence is the last refuge of the incompetent." jcorgan(a)aeinet.com -Isaac Asimov WWW: http://ftp.netcom.com/pub/jc/jcorgan/home.html -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLzad6E1Diok8GKihAQExdAP+LZvM2rbJWf6WwIs2oHPjfWRCyXAQTnYm gpMld86xiJeM5AKudlH2YW+b12lv+9wdH71Fo38FNOdLDX7xDkXQzmkz2creV7sQ GCfrJOAObLro8vwpZ5LVwin0qvmZzH4PO7to2Th3iYGbrXh4zoOdr5GNLU8j+wTd HcV9N6nELxg= =iNH8 -----END PGP SIGNATURE-----

1 0