December 2003 - cypherpunks-legacy

new remailer-politics mailing list (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: >From owner-austin-cpunks(a)ssz.com Sat Sep 13 20:08:32 1997 Date: Sat, 13 Sep 1997 19:55:44 -0500 (CDT) Message-Id: <199709140055.TAA26578(a)matrix.eden.com> From: combee(a)techwood.org (Ben Combee) To: austin-cpunks(a)ssz.com Subject: new remailer-politics mailing list Sender: owner-austin-cpunks(a)ssz.com Precedence: bulk Reply-To: austin-cpunks(a)ssz.com ------- start of forwarded message (RFC 934 encapsulation) ------- Message-Id: <3.0.3.32.19970913162941.03343264(a)rboc.net> X-Sender: support(a)rboc.net (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk Reply-To: 2600(a)ninja.techwood.org From: "Robert A. Costner" <pooh(a)efga.org> Sender: owner-2600(a)ninja.techwood.org To: 2600(a)ninja.techwood.org Subject: [SE2600] Remailer politics Date: Sat, 13 Sep 1997 16:29:41 -0400 - -----BEGIN PGP SIGNED MESSAGE----- A new mail list is forming, called "remailer-politics". You are welcome to use your nym or any address to join the list. You are also welcome to create a new nym just for the mail list. You of course are welcome to use your normal email address as well. Anonymous mail to the list is very welcome, but obviously you must submit a nym or email address to be able to read the mail. The list is called remailer-politics, and is run on majordomo. We'd like to discuss the non technical issues of remailers. I'm hoping the contributors to the list will be part users of remailers, and part people who have not used remailers. Also, bear in mind I'm not the remailer administrator, so I'm looking to be educated as well. Hopefully we will talk about remailers, laws, encryption, email and newsgroup abuse, privacy and anonymity. Personally, I'd like to be able to walk away from the discussion thinking that I can better defend the concept of a remailer to someone who is anti-encryption, anti-anonymity, a lawyer, a judge, or even a nationally known pro-civil liberties person. To join, send a message body of SUBSCRIBE to REMAILER-POLITICS(a)SERVER1.EFGA.ORG If you have trouble, just email me and I'll manually put you on the list. Similar messages have gone out to other mail lists, newsgroups, etc. Your subscriptions will be mix'ed in with the rest if you use your real address, so no one will know. The list of list members will not be available for inspection. Please join us, and help educate myself and others about the benefits of remailers. - -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQBVAwUBNBr3sUGpGhRXg5NZAQHbcAIAj/vh+yX9osQ++X69Q75NztBcP7eGCnQi 6ETbNJqktQjmS02CSkhex2d3lz2htcJRZbaq4NysMdwybMNsRl5Amg== =1SxI - -----END PGP SIGNATURE----- ------- end ------- -- Benjamin L. Combee (combee(a)techwood.org) <URL:http://www.yak.net/combee/> ...if the highlight of your day is prowling through signatures looking for pithy quotes or neat phrases, then consider a career with the IRS or NSA...

1 0

Re: netscape bug
by David_A Wagner 17 Dec '03

17 Dec '03

In article <199509201855.LAA17261(a)netcom16.netcom.com> you write: > > none of the articles mention that the cracker must have login access > to the computer that the random numbers are generated on. is this true? > does the code require knowledge of the PID etc. that can only be obtained > by a login to the system that the netscape session is running on? > No, the time, pid, and ppid often leak to a remote adversary too. The attack probably requires a bit more sophistication when the cracker doesn't have login access, but I believe it's still possible. See my recent post to sci.crypt for some comments from Ian & I about this.

1 0

Re: List of US representitives
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- In article <00996ED487C83F20.00003C77(a)sanchez.com>, gorkab(a)sanchez.com ("Brian Gorka") wrote: >Someone posted a list of US reps awhile back... Can someone forward me a copy? Everything you need to know put pressure on Congress critters is at http://www.NRA.org/pub/congress/104/ I especially recommend http://www.NRA.org/pub/congress/104/congress.awk.Z - From the readme: "congress.awk is a comma-seperated database of congress members & some unix awk code for manipulating the database" - -- - -- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred. - --- [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 iQBFAwUBMGcQ9ioZzwIn1bdtAQHKLwGAnzE6f67qn0bZFVcOV/49gemiD9jAluJo ageYFxFsIIbkD9q28/a/7yX/GKaDNTSu =0h5T -----END PGP SIGNATURE-----

1 0

Re: Exchange random numbers (was: Re: netscape's response)
by David_A Wagner 17 Dec '03

17 Dec '03

In article <199509211852.LAA22259(a)Csli.Stanford.EDU> you write: > > | If I only ever give out a hash of my seed, and only ever *add* any received > | info to my seed (and stir it in well), how can anyone find out anything? > | (Apart from hash weaknesses.) > > Giving out contribution: > MD5(select_bits(my_seed, start_bit, stop_bit)) -> remote > Taking in contribution : > my_seed = my_seed XOR > ((select_low_bits(remote_contrib, contrib_width) << contrib_area) > People seem to think this kind of thing is obviously safe. I'm not yet convinced. By xoring in a quantity *chosen by your adversary*, you're essentially allowing related-key attacks on your stream cipher. (Your PRNG is just a stream cipher, keyed with my_seed.) Noone knows how secure most ciphers are against related-key attacks: related-key attacks are known to be very powerful (often more powerful than any other type); but very little research on this topic is available. You're treading on unknown ground. There's the also a small error in your specific algorithm. Let n = stop_bit - start_bit; presumably n is much less than the length of your seed. Then a brute-force search over n bits will recover n bits of the seed -- this is a much faster cryptanalysis than a brute force over all bits of the seed. This can probably be fixed by something like MD5(select_bits(MD5(my_seed))) -> remote, but the related-key uncertainties still remain.

2 2

Article in 9/25 Computerworld about Netscape
by Mike Fletcher 17 Dec '03

17 Dec '03

Just got the Sept 25th issue of Computer world in my box and it's got a big first page article on the NS bugs. They get the key lengths wrong (30-bit and 300-bit), and they say that "... future products will also use 300-bit keys." And they mention Cypherpunks by name! :) --- Fletch __`'/| fletch(a)ain.bls.com "Lisa, in this house we obey the \ o.O' ______ 404 713-0414(w) Laws of Thermodynamics!" H. Simpson =(___)= -| Ack. | 404 315-7264(h) PGP Print: 8D8736A8FC59B2E6 8E675B341E378E43 U ------

1 0

Re: Notes security question
by Herb Sutter 17 Dec '03

17 Dec '03

At 14:52 1995.09.25 -0400, Jon Lasser wrote: >On Fri, 22 Sep 1995, Herb Sutter wrote: > >> While I'm at it, here's a question I've been wondering about recently: Why >> is it I've never heard of any security issues with Lotus Notes? Are there >> no known weaknesses? Or did existing weaknesses just not get much press >> because Notes isn't a commercially visible consumer product like Netscape? > >Perhaps the Notes pricing scheme is sooo outrageous (by the standards of >a student like myself, and probably most others, if it's still anything >like it was at the 1.0 release) that mostpeople have had zero opportunity >to examine the program, let alone really have time to play with it? Good point. However, since it's been around for years and is (in some people's eyes, at least) cutting-edge secure replication technology, it made me begin to wonder about the product's actual security. All I know is that they use one of RSADSI's libraries, since RSADSI mentions them in their "here are our current users" advertising. >From the deafening silence, though, it seems like there's not a whole lot of information or opinion either way on Notes' security...? Herb ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Herb Sutter 2228 Urwin, Suite 102 voice (416) 618-0184 Connected Object Solutions Oakville ON Canada L6L 2T2 fax (905) 847-6019

1 0

Another Netscape Bug (and possible security hole)
by Ray Cromwell 17 Dec '03

17 Dec '03

I've found a Netscape bug which I suspect is a buffer overflow and may have the potential for serious damage. If it is an overflow bug, then it may be possible to infect every computer which accesses a web page with Netscape. To see the bug, create an html file containing the following: <a href="http://foo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.f…! o.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo/foo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.! bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo .foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo/foo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.f! oo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foofoo.bar.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo> blah </a> On my BSDI2.0 machine running Netscape 1.1N, this causes a segmentation fault and subsequent coredump. GDB reports nothing useable (stripped executable) As you can see, I just chose an extremely long domain name. I guessed that the authors of netscape probably thought something like "well, a buffer size of 256 characters is good enough to hold any domain" It's definately the domain that's causing it, and not the length of the URL or the data after the domain name. I also tried to overflow some netscape servers using similar techniques (and shell metacharacters in all sorts of URLs), to no avail. I suspect a similar attack may work against the Netscape Server if it is proxying. Does anyone have a disassembly of Netscape, or more specifically, a disassembly of the URL parse and domain lookup routines? I'd be happy to collaborate and "Hack Netscape" ;-) Happy Hacking,

9 20

Netscape as vehicle for cypherpunk agenda/the cypherpunk bully pulpit
by sameer 17 Dec '03

17 Dec '03

I was thinking recently how the events of the past week or so have turned me into a sort of a Netscape advocate. Granted, there are bugs in Netscape, and there probably will be more bugs uncovered (someone needs to write an exploit if they want themself & Ray to get a T-shirt btw), but Netscape is interested in fixing problems and the new 2.0 is doing encrypted email, probably with a really nice interface (Haven't seen it yet, of course) and they are working to make the 128-bit version downloadable. (The 128bit version is available overseas already anyway, I hear.) The really big sticking point I see, however, is the certification authorities. There is a single point of failure here and that is at Verisign. This becomes a large problem I think if the en rypted email that Netscape does requires personal x509 certificates (I read that Versign is issuing those for $9/each.) This is a problem because for one thing I don't think Versign will want to issue certs to psudonyms, and Netscape may not talk encrypted email to non-certified people. (I am not sure) The solution to this, of course, is to allow Navigator to accept alternate certification hierarchies, so we can setup a Cypherpunks cert agency or a c2.org cert agency, which -will- sign nym's keys, etc. The question exists though, as to whether or not Netscape will allow for alternate agencies in Navigator. I haven't seen any mention of this feature in 2.0, so if the feature exists in 2.0, then great! Otherwise, unless Netscape is going to allow for alternte cert agencies on a specific timescale, I think we have to do something about it in order to force the issue. Along the same lines of what happened recently-- because of the exposed hole and the pressure put on Netscape, management was finally willing to let some of the code be available for public review. If something happened to show how relying on a single point of failure such as Verisign was bad and resulted in much press & publicity, then perhaps Netscape management would be convinced to allow for alternate cert hierarchies.. Some sort of hack which demonstrates this would be great. I am feeling uncreative and can't think of anything effective short of stealing Verisign's private key, but that would be pretty damn tough. -- sameer Voice: 510-601-9777 Community ConneXion FAX: 510-601-9734 An Internet Privacy Provider Dialin: 510-658-6376 http://www.c2.org (or login as "guest") sameer(a)c2.org

4 3

SSL Man-in-the-middle
by David J. Bianco 17 Dec '03

17 Dec '03

Has anyone given much thought to the feasability of a man-in-the-middle attack against an SSL (or other similar) transaction? To me, the possibility seems obvious, so I figure it must have been discussed before, though I haven't seen it. The basic idea is pretty simple, really a flaw in the user interface of the browser more than a flaw in SSL. Neither browsers nor servers routinely validate that they are communicating with the entity they think they are. Sure, with netscape you can ask for the document information window, which shows the server's public key information, but this isn't a common action among users, and certainly isn't something you'd want to do for every page you viewed. The only readily accessible information about security is that blue key at the bottom of the netscape window. Netscape docs tell you that if that key is blue, your transaction is "secure." In reality, the only thing that key means is that you've negotiated a session key and are encrypting your communications. It says nothing about the fact that you're actually communicating with the correct party. Authentication is a large part of security, and Netscape doesn't make that information conveniently available. Consider the following example. Bob wants to communicate securely with Alice. He fires up his "secure" browser, looks up Alice's address in the DNS and makes a connection. He then sends Alice a document and disconnects. Now consider the following attack on the scenario: Bob still wants to communicate with Alice. He fires up his browser and looks up Alice in the DNS. Mallet, who wants the information Bob's sending, has subverted Alice's DNS server and replaced Alice's IP address with his own, making a note of the proper value. Thus, when Bob looks up Alice's address in DNS, he gets the wrong information and contacts Mallet instead. Mallet performs the SSL protocol with Bob, pretending to be the server, and then with Alice, pretending to be the client. Since neither the browser nor the server perform any authentication checks, neither Bob nor Alice know they are really speaking to Mallet. The best Alice can do is check the IP address of the client she's speaking to, but if Mallet has his own DNS, he can make the IP address map to whatever name he wants, including Bob, in order to fool alice. Even if Alice doesn't depend on the DNS for IP resolution, probably doesn't know that the IP address in question is really Mallet's, since it looks just like any other IP address to her. In this scenario, Bob gets a warm fuzzy since his key is blue and he knows his information is being encrypted as it goes out. Alice has a smaller fuzzy, since she believes the transaction is secure from prying eyes. Mallet has a *really big* fuzzy, since he's able to read the data Bob sends, decrypt it, save it, then re-send it to Alice. I've read through the SSL spec, and it provides authentication for both the server and the client, but these features are rarely used, probably because they are somewhat inconvenient for the user. A good first step would be to include the IP address of the server in the certificate signed by VeriSign. In this way, browsers could perform automatic checks that the IP address in the certificate is actually the one that's being communicated with. This does raise other questions (such as protecting from IP spoofing), but IMHO would be a good way of providing an automatic "first check" without inconveniencing users. The added inconvenience of obtaining a new certificate when your server's IP address changes is fairly minor, and could be viewed as necessary overhead for doing secure transactions via the Net. -- ========================================================================== David J. Bianco | Web Wonders, Online Oddities, Cool Stuff iTribe, Inc. | Phone: (804) 446-9060 Fax: (804) 446-9061 Suite 1700, World Trade Center | email: <bianco(a)itribe.net> Norfolk, VA 23510 | URL : http://www.itribe.net/~bianco/

5 7

Re: "random" number seeds vs. Netscape
by norm＠netcom.com 17 Dec '03

17 Dec '03

At 12:29 PM 9/24/95, Ed Carp [khijol SysAdmin] wrote: .... >I learned the hard way - keep the transmitters away from a reverse-biased >doide acting as a noise generator. Only until I examined the output did >I realize it wasn't random. I fixed it, though, by looking at the output >and testing its randomness. .... Very interesting. I wouldn't be too sure that a transmitted signal at a single frequency is the only signal that an opponent could use to bias your random numbers. How do you "test for randomness". I think that signal to noise arguments, phrased in terms of entropy, can protect you against unknown and unwanted signal. (Ironically you want a very low signal to noise ratio!) Perhaps you merely take n/(S/N) bits from the HRNG when you need n bits and run them thru MD5. Here S is the signal strength of the maximum plausible unwanted signal, and N is the noise of the diode. I encourage both diode theorists and information theorists to quibble with the above formula!

2 1