December 2003 - cypherpunks-legacy

CHOMSKY MADNESS!!!
by L. McCarthy 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- James Donald writes: > One may be a reasonable inference, as I inferred > that Chomsky sought to justify mass murder and > brutal terror. The other is a lie. Hey Eric, how about a filter that delays all messages to the list which mention Chomsky by a month or so ? - --- [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 iQBFAwUBLu4kpCoZzwIn1bdtAQHgDgGApDSD7Z+FZW+ykNEO8WujOFnDUhbyxSnv tyb0ZVY8mnVjmookxn19UVE8iRbLZQKU =Rwt7 -----END PGP SIGNATURE-----

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

Clipper Revived?
by jltocher＠CCGATE.HAC.COM 17 Dec '03

17 Dec '03

From Edupage: REPLACEMENT FOR CLIPPER AT&T and VLSI Technology Inc. will collaborate to develop microchips that use a triple-strength version of DES (data encryption standard), which previously had been rejected by the National Security Agency. VLSI is the designated contractor to make the government-favored Clipper chips, but this latest announcement reveals their doubts over whether there's a market for the Clipper. "These companies have basically made the determination that Clipper is dead and there's going to be the proliferation of encryption anyway, so they might as well take advantage of it," says one observer, who predicts the market for such technology "could reach hundreds of millions" of dollars in annual sales by the end of the decade. (Wall Street Journal 1/31/95 A3) 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

2 1

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

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- - -----BEGIN PGP SIGNED MESSAGE----- In article <199502011911.OAA09754(a)bwnmr5.bwh.harvard.edu>, Adam Shostack <adam(a)bwh.harvard.edu> wrote: > Its awfully expensive to send messages all over creation so >one person can read them. Much better to send it to the person who >wants to read it. Besides, USENET propagation can be slower than >remailers; the far ends of the chain can often take around a week. 1. Let's have some perspective here. Remailer traffic can't really be expected to exceed the traffic in, for example, alt.binaries.pictures.erotica. Additionally, with USENET it's trivial to control when are whether you receive particular groups. Don't want to carry alt.anonymous.remailer.channel? No problem. Don't. 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. The biggest reason to use remailers is not to avoid interception of traffic: that's a trivial problem with PGP. The biggest threat is that of traffic analysis: Alice doesn't want her boss Charlie to know she's having an ongoing discussion with Bob about a new "career opportunity." As I've said, I think USENET is perfect for this. Add some reordering to the processing and a hidden way to define the intended recipients and no way that passive traffic analysis is going to succeed. - - -- Todd Masco | "Schooling serves to reduce the risk of being eaten." cactus(a)hks.net | - Scientific American, June, 1982 Cactus' Homepage - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLy+w1xNhgovrPB7dAQFjcgQAqc6eu22NAB8wE5iAyyGMTFbwlXLbiHF0 FUmJlWXQ4J8EkPXEa+ZUKGlcbCETjQ2rXxzHh3cOiVxjRVnKKh5Q/VmU4JOALPXE lBIfH+W8ty0LxaXBue9KkXh4cFvoehW7UXhq9oitNgSqiTmf/EoCbjJc5A7w7YHd Aqu7sgyyPFQ= =4UNd - -----END PGP SIGNATURE----- - --- [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 iQBFAwUBLy/p3CoZzwIn1bdtAQGkNgGAtR+F+nkckmLHgvrlurrHsGng24kdBu4R 20AwntDjdEcZjNHAqrc/aCf8TKVhUUJV =o09G -----END PGP SIGNATURE-----

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