- cypherpunks-legacy - lists.cpunks.org

Re: Remailer Unreliability
by jordyn＠alinc.com 17 Dec '03

17 Dec '03

>> Date: Thu, 2 Feb 95 18:00 EST >> From: nobody(a)myriad.pc.cc.cmu.edu (Anonymous) >> >> What if it was possible to specify an alternate remailer? In the case that >> a remailer went down, you could specify an alternate. For example: > > Well, *I* think it is a good idea. But how does remailer1 know that >remailer2 is both a remailer and down? The issue of whether or not the alternate address is a remailer seems to be largely irrelevant. It doesn't really hurt anyone to be able to specify an alternate address, and the feature would even seem to have some practical value as you could specify alternate addresses for an end-recipient if you suspect an address might be unreliable. As long as the alternate address is only invoked if the first mail delivery fails, the problem of the exponentially-growing message is avoided as well. Jordyn ------------------------------------------------------------------------- Jordyn A. Buchanan Environmental Studies (B.U.S.) jordyn(a)alinc.com University of Utah -- '95 (hope) PGP Public Key: 0xADEEC1 ED 3D 36 5A 98 CE 9D B4 4B 37 0B 9B B5 D6 F3 4B

1 0

Re: Fundamental Question?
by Andrew Lowenstern 17 Dec '03

17 Dec '03

> Although I understand the need for remailers for anonymity, is it > not true that the whole idea of encryption (good encryption, that > is) is that no matter who gets the encrypted text, it really doesn't > matter? Does this not mean that something like USENET is *perfect* > for this? Usenet may be provide good untracability for the recipient, but the if the sender desires untracability she needs to use a remailer or some other service to get the message into Usenet. Also, the recipient needs to know if and where to look for the message. If the recipient isn't anticipating the receipt of a message untracably, or doesn't care if 'they' know she is receiving the message, then Usenet isn't necessary. andrew

1 0

Re: ESP Unix encrypted session protocol software
by norm＠netcom.com 17 Dec '03

17 Dec '03

At 11:49 PM 1/31/95, Thomas Grant Edwards wrote: >On Tue, 31 Jan 1995, Eric Hughes wrote: > >> Just because plain old Diffie Hellman is subject to active attack >> doesn't mean it's useless. Some protection is better than no >> protection at all. It's still worthwhile implementing some security >> to make an opponent's task harder than to implement no security. > >I'm curious though if there is some way to reduce the risk or at least >increase the detectability of active DH spoofing. I am thinking of the >use of a trusted adjudicator who could receive information from both the >original participants and check to see if the two keys matched. > >Does anyone see a good solution to this problem? .... I trust that that the attack refered to is the "man-in-the-middle". I find it very curious that there is a simple fix to the attack for the enctrypted voice channel. Each unit displays to its human a few bits of g^(xy). One human quotes them vocally to the other. If there is a man in the middle the bits are unlikely to match. What I find curious is that there seems to be no automated analog to this precaution. It has to do with the difficulty of substituting the vocal signals that code these bits. This is too hard for either computer or man (in the middle). I write to stimulate a solution. I have none.

2 1

FMP
by Todd Masco 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Can anybody tell me where I might be able to find the FMP library ( Riordon's PD GMP-a-like)? Archie turns up empty. Thanks, - -- Todd Masco | "Schooling serves to reduce the risk of being eaten." cactus(a)hks.net | - Scientific American, June, 1982 Cactus' Homepage - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLzAAXyoZzwIn1bdtAQHjuwF+JHUY0HeNtzptxC2hTuVRrNV/s9/k1DeZ F0XE3PUFvSTBCyo9iv++O31td0xt1YWj =3iAP -----END PGP SIGNATURE-----

1 0

Re: Fundamental Question?
by kevin＠elvis.wicat.com 17 Dec '03

17 Dec '03

>2. USENET propogation is not that slow; Between well connected sites >(IE, just about any Internet host that isn't swamped for other reasons >like Netcom frequently is) I haven't seen a larger lag than a few hours. Consider the incoming directory on my local news host: -- jlc:/usr/spool/news/in.coming$ ls -l total 401 -rw-r--r-- 1 news news 172237 Feb 1 16:08 21705-000000.t drwxr-xr-x 2 news news 1024 Jan 31 13:43 bad/ -rw-r--r-- 1 news news 79792 Jan 27 12:35 nntp.a00606 -rw-r--r-- 1 news news 130025 Feb 1 16:09 nntp.a21731 drwxr-xr-x 2 news news 21504 Jan 21 12:57 save/ -rwxr-xr-x 1 news news 194 Nov 30 14:22 unz* jlc:/usr/spool/news/in.coming$ grep Date 21705-000000.t | more Date: Mon, 30 Jan 1995 18:28:21 GMT Date: Mon, 30 Jan 1995 18:34:30 GMT Date: 30 Jan 1995 11:03:14 -0800 Date: 30 Jan 95 13:25:19 +0200 Date: 30 Jan 1995 13:35:59 -0500 Date: 30 Jan 95 17:59:27 GMT Date: 30 Jan 1995 13:25:40 -0500 Date: 27 Jan 1995 14:11:51 -0600 Date: 27 Jan 1995 14:50:32 -0500 -- The majority of incoming messages are two days old (this was on Feb 1 at 16:10, GMT -7); the worst instance in this particular batch was six days old (posted from a backwater site in Sweden). Before you object that this is obviously a poorly-connected site, we're on a leased 56K line two hops from the backbone (we're fed by BYU, who is in turn fed by the University of Utah, one of the original four internet sites and as well fed as you get). Our server is keeping up with the incoming news. I suspect this is a pretty typical scenario. -- Kevin

1 0

Re: Frothing remailers - an immodest proposal
by kevin＠elvis.wicat.com 17 Dec '03

17 Dec '03

>Without quoting the entire message, I think I better solution, in terms of >ease to implement as well as conserving bandwidth would be to have a >sophisticated remailer script-language. > >For instance, the script language could tell the remailer to check if a >site is on-line (perhaps within certain GMT hours or dates) and use the >next site if not available, or to randomly choose from a list of sites >the active ones, etc. Aye, there lies the rub. How exactly does one determine if a site is active or generate a current list of active sites? It is not enough to ping the site or even to successfulyl deliver mail to it: the fact that something is alive and running sendmail does not make it a remailer. Likewise, a remailer cannot select an alternate site on behalf of the user if the routing is chosen by the user, as each "envelope" is encrypted specifically for a given remailer. I suppose one could develop client software that built several redundant "envelopes" for alternate mailers, but that would get out of hand pretty quickly, both in terms of the effort of generating a secure message and in term of the size of a message. Scripting is useful (hell, the ::Request-Remailing lines are effectively a script) but not until there is data to operate on. >Maybe even have it work with a data haven? Mail the message to a data haven >and send another message to a remailer chain to pull the message from the >data haven and post the data (not flaws in this: don't want remailers getting >files from people's accounts and posting them to usenet etc.). Not a bad idea, actually. -- Kevin

1 0

Re: Frothing remailers - an immodest proposal
by kevin＠elvis.wicat.com 17 Dec '03

17 Dec '03

>1. Broadcasting every couple of minutes isn't necessary and is undesirable >due to the real limitations of the Internet. A remailer could broadcast >its location with a time-out on the location without a constant stream >of availability announcements. In your position for example, you'd >broadcast a message at 5 pm with a 16 hour valid time. True, but this has two basic assumptions that I disagree with: first, that we can guarantee delivery of a broadcast message to all interested sites; and second, that remailers never go down for unexpected reasons. When the day comes that both networks and software are perfect, this method will be reliable. Of course, you are also right that broadcasting is undesirable; that is why I am pondering a way to minimize the impact. >2. This is actually unnecessary for your situation: All you need to do is >advertise your location as a "real" remailer and then have a cron job that >kill sendmail at 5pm on your remailer machine (assuming you have a spare >machine that doesn't need to run sendmail). The mail network is flexible >enough that things will Just Work. Mail won't go through instantly during >the day, of course, but that just helps to muddy up the mix. But, if my understanding of remailer operation is correct, this has two potential problems: first, I will still receive mail during the day, causing a bandwidth concern (I know, it's probably not a problem right now, particularly since users will probably choose to avoid a remailer with a possible 16 hour delay); and second, the machine delivering mail to me simply has to trust that a remailer will in fact pop up on this machine to process the stored mail. There is no way of determining that mail is not simply going into a black hole. And even if I try to be nice when the mailer goes down permanently and tell everyone not to route mail through it any more, that news still has to travel via word of mouth to all users of the web. > >3. Broadcasting over live IP isn't all that great a model. Ideally, >you'll use a mechanism that doesn't require instant communication among >hosts. I favor USENET for this: messages have a naturally long life- >time and the network is self-adjusting. If a direct route is temporarily >unavailable, an indirect one will often manifest itself. I also favor >using USENET store-and-forward for the messages themselves for the same >reasons: traffic analysis is impossible inside the web and direct routes >are not necessary. I am not happy with my proposed advertising methods, and was quietly hoping for some guidance from internet gurus in this point (the irc suggestion in particular is a pretty shaky straw man). However, see my earlier message (on some other thread) about Usenet propagation times. Propagation times in days do not seem to be rare (post to misc.test and see when the last reply comes back). While this is better than word-of-mouth propagation, it does not offer the very low latency I was looking for. >4. Using a PGP-style web-of-trust is important. In the ideal situation, >one human in an extended web can certify individual remailers and all other >remailers close enough on the same web of trust would pick up the message >immediately. It strikes me as critical; right now, a user has to choose to trust a set of remailers, given no assistance other than a list of "reliable" ones. Given an extended web of trust between remailers, the user can choose to trust one remailer (I have no idea how to make this process more palatable) and immediately gain the security of a large web of remailers (maybe you are right about that instant gratification thing...) Kevin

1 0

Re: Fundamental Question?
by cactus＠seabsd.hks.net 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- In article <9502012323.AA00271(a)toad.com>, <kevin(a)elvis.wicat.com> wrote: >Consider the incoming directory on my local news host: ... Strictly speaking, you've really only demonstrated that there are a lot of poorly connected sites on the USENET. The primary characteristic that really needs to be considered is the time for news to reach one remailer site from another. My experience is that new propogation is fast enough that close to real-time conversations happen all the time. I take part in them on the newsgroups I still read and observe them all the time. I don't have a ready explanation for why my experience differs so much from yours. The worst-connected site I've ever read from was 9 mo.s ago with a batched feed from uunet. Even then the vast majority of posts I saw were from the day just ending. What are other people seeing as news delays? - -- Todd Masco | "life without caution/ the only worth living / love for a man/ cactus(a)hks.net | love for a woman/ love for the facts/ protectless" - A Rich Cactus' Homepage - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLzAmeSoZzwIn1bdtAQHHiwGAxL13i5YYjZxREU1XwnAp81+XWgir7H92 enbDeqFQwjddTeEgHX+fKZWoZJBe4wy6 =pmE5 -----END PGP SIGNATURE-----

1 0

Re: Frothing remailers - an immodest proposal
by kevin＠elvis.wicat.com 17 Dec '03

17 Dec '03

[deletia] >Now, dynamic rerouting is good for better delivery, but is bad for the >trust in silence. Trust in externally unverifiable properties is >_not_ transferrable. Just because I believe that my regular remailer >is OK does not mean you do. The creation of these links of trust is >not something that can be automated solely by the remailer operators. >The end users of the remailers are the endpoints of this trust >relationship. The end users must be involved, either directly or >through some (legal) agent, in the manipulation of these relationships. First, I must admit to being somewhat out of my depth here; this seems to be becoming a philosophical problem. With that shameful admission out of the way, let me bull ahead regardless. It seems to me that I can choose to trust in the fact that *your* trust in other remailers is well founded. This then becomes a third category of trust for a given remailer: trust that it will deliver (verifiable); trust that it will be silent (unverifiable); and trust that its operator has good judgement in choosing who to trust (unverifiable). These latter two are, and should be, the end users responsibility. Now, as I have mentioned in an earlier message (I'm being far too verbose today) I am proposing that dynamic routing be optional, though the default behavior, for reasons mentioned there. Thus, if I, as user, choose to allow dynamic routing (through omission - I must admit, I am becoming less fond of the notion of this as default behavior - it begins to smack of the heresy of "implied consent") I am expressing the third flavor of trust, just as by using the remailer at all, I am expressing the second variety. Of course, I still have to trust that a remailer will honor my routing requests. However, I believe this falls fair and square into the second category (trust in silence) >Any solution which tries to do this independent of the end user is >broken, by definition. -- Kevin ( I have no joke here, I just like saying "I trust a remailer if it is trusted by an entity I trust to trust remailers".)

1 0

NYC area C'Punks meet 2/11/95
by mjwohler＠netcom.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Attn.: New York City area Cypherpunks NYC C'punks meeting: Sat Feb 11, 3:00 P.M., at the home of Linn & Barbara Stanton 315 West 106 Street Apt 2A (Between West End Ave & Riverside Drive) 212-316-1958. Once again the gracious Stanton's invite local area Cpunks to their lovely home which is smoke free and feline friendly. The agenda is still open and suggestions can be made to mjwohler(a)netcom.com or phone Marc Wohler @ 212-362-0690. Let me know if you plan to attend. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLy+PL2eikzgqLB7pAQGHigP9HW1Py30O2fcZH/f1SAOToOBZYVZMiB9c buGQrujaicGVJlvGb1Le/OjJ872JB69BQD1MMsemABSYi4swL15w9qj1rhoTAHIg yTRDFJD16g1lqqLvEJZ0RijOh1dXLaUg8HNue0JoSAbARkQed8I3+mklP4C4saYn qW2Fa/kDuZY= =Rl9C -----END PGP SIGNATURE-----

1 0