December 2003 - cypherpunks-legacy

Re: Clarification of my remarks about Netscape
by Kipp E.B. Hickman 17 Dec '03

17 Dec '03

In article <9412111620.AA41983(a)eldamar.walker.org>, you write: > Several people have asked me to clarify my recent comments about Netscape. > I am more than happy to oblige. > > First of all, let me begin by saying that I am a biased observer, and that > all of this is my personal opinion. My annoyance with Netscape is also closer > to the surface this week than it normally is, due to a variety of factors > (including having just returned from the San Jose IETF meeting). My initial > comment, and the ones that follow in this message, are thus more frank than is > my usual style on, say, public Usenet newsgroups. > > That being said, here are some of the data that has gone into my impressions > of Netscape so far. > > (1) Netscape plays very fast and loose with HTML. Rather than participating > in the existing standardization efforts, they have indiscriminately added > "extensions" to it that are not supported by any other client software, > and which in some cases go directly against HTML's markup-oriented > structure. This only adds more confusion to an already muddy area, > delays the prospects for a standard HTML specification, and divides the > WWW into "WWW Classic" and "Netscape-compatible". Personally, as a > strong proponent of universal interoperability, I find this reprehensible. > There is no need to bypass existing efforts just to add cosmetic value to > your own software. This has nothing to do with security... > (2) The Netscape Secure Sockets proposal has an extremely poor security model. > It is not an end-to-end security model, but rather relies on transport > level security, which is in my view dangerously inadequate for reasons > which should be obvious to most of the folks on this list. Clearly I'm an idiot. Explain it to me. And while you are at it, why don't you email me your comments on the spec? I put my email address in there for that very reason. Jeesh. > It is also > tied directly to the RSA certification hierarchy. Now, for those of us > who have X.509 certificates rooted in the RSA Commercial Certification > authority, that's fine, but it also means that any other WWW client that > wishes to interoperate with Netscape's "secure servers" must license > TIPEM from RSA Data Security, and consequently pay RSA's rather high > royalties, unless the software is free (in which case RSAREF can be used). > This serves as a direct barrier to competition from other commercial > vendors. This is not all bad--I happen to like RSADSI's products and > technology--but promoting a transport-level security system instead of > an end-to-end one is to my mind simply irresponsible. This is an outright lie. We don't use TIPEM. You could build a conformant SSL implementation using RSAREF and the freeware IDEA cipher code. As for a barrier to competition. So what else is new? We all have barriers to overcome before we can compete. Should we get rid of TCP/IP as a barrier to using the web? > There has been no peer review of Netscape's security model--it was simply > implemented by fiat, without regard for the IETF standards process. I > find that this leaves a very bad taste in my mouth. I also heard similar > sentiments from a wide variety of other attendees at the IETF, including > members of the IP Security working group, people who attended the Secure > HTTP BOF, and others. This leads me to believe that it's not just a > matter of me leaping to wild conclusions. You are somewhat right here. In fact, this was done because we are a company interested in surviving long enough to withstand the eventual attack by microsoft. Instead of waiting several years before anything was agreed upon and ending up with a kitchen sink protocol as all others these days do, we took a simpler approach. And instead of hiding in a closet with it, we brought it out to light. As a result we received critical review from some decent members of the crypto community, including: Martin Abadi Mike Burrows Alan Schiffman Matt Robshaw Burt Kaliski to name a few. As for the IETF standards process, we are pushing the document into the RFC process. > (3) Netscape is viewed as a "loose cannon" by most of the other commercial > players in the WWW arena, mainly because they have introduced a fair > amount of FUD into the HTML standardization effort, while simultaneously > promoting themselves as being standards-based. Members of Apple's > "Cyberdog" project and Microsoft's web projects, who *are* trying to > contribute to the standards process, had particularly excoriating things > to say in this regard. This is a matter of opinion. However, I believe that our opinions don't matter in the long run because of the 800 pound gorilla Microsoft. They will push something out, it will be proprietary, and they will name the tune and ask us to play along. Now we can either just sit back in our current comfy cozy standards based processes and languish for a few years, and then SIGH and say "Gee wasn't that fun, too bad microsoft shoved yet another piece of excrement down our throats" or we can be "loose cannons", get something out there, try it out and see what happens. The market will decide one way or the other. > Now, as I said, I am biased and my comments about Netscape are strictly my > person opinions. I will be perfectly willing to revise these opinions as I > receive more data. For example, if Netscape takes a more active part in > the standards process, works with RSA to secure wider availability of the > underlying technology required by their proposals, and generally demonstrates > a willingness to play nicely with other children, that would be great, and > I'll just as strongly defend them as I am panning them now. > > However, in my view, they have not shown a good initial track record. > Only time will tell. > > > Amanda Walker > InterCon Systems Corporation > > --------------------------------------------------------------------- Kipp E.B. Hickman Netscape Communications Corp. kipp(a)mcom.com http://www.mcom.com/people/kipp/index.html -- --------------------------------------------------------------------- Kipp E.B. Hickman Netscape Communications Corp. kipp(a)mcom.com http://www.mcom.com/people/kipp/index.html

8 23

Re: Real-time surveillance of the police
by doumakes＠netcom.com 17 Dec '03

17 Dec '03

The technology of monitoring location is interesting, of course, but why on earth would the police, who will not consent to civilian review, ever go along with something orders of magnitude more extreme? ObCrypto/Privacy: I suspect there would be an immense amount of radio traffic involved in keeping track of a substantial group of people, say, over 1000. I don't doubt the ability of the device(s) to transmit the information, but the ability of the receivers to digest it all in real time. -- ______________________________________________________________________ Don Doumakes Finger doumakes(a)netcom.com for PGP public key Foxpro databases built to your specifications. Email me for details.

1 0

BEAT COPS
by Sandy Sandfort 17 Dec '03

17 Dec '03

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C'punks, Michael Crawford wrote: ... individual cops can rack up millions of dollars in legal settlement costs and still remain on the force. I heard ... that a small handfull of cops in San Francisco had cost the City tens of millions, with individual cops repeatedly causing lawsuits, without getting fired. True, but that's without embarrassing videotapes. The clueless populace doesn't stay clueless for long when they seen the police "blooper" tapes. Police unions won't have much clout compared to an enraged public. ... at least one cop wouldn't go for it - the cop we caught jacking off to a magazine of ill repute... Gives whole new meanings to "night stick," "the long arm of the law," "stop and frisk," "pat down," "pounding a beat" and going to the "policeman's ball." (Anyone else want to jump in on this one?) S a n d y ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Re: Misunderstanding of Remail Headers
by jrochkin＠cs.oberlin.edu 17 Dec '03

17 Dec '03

At 2:13 AM 12/12/94, L. McCarthy wrote: >Hal writes: >> There was also a misperception that my remailer was an official effort >> endorsed by Portal (again, despite the disclaimers). Note that it was >> they who were contacted, not me (yet). This might suggest that it will >> not be possible to cleanly separate the remailer operators and service >> providers when problems like this arise. Both may end up being hassled >> (time will tell whether I am). > >This is all too familiar to me. Although I still haven't heard the official >line on the shutdown of Underdog following the Scythe spam, at least some >people locally (including, crucially, my advisor) received the impression that >I had forged (and authored !) the offending news articles in spite of the >disclaimer headers. Maybe the remailers should put bogus "From:" lines in, to avoid this? Make it "From: nobody", or "From: Anonymous", or even something odd like "From: AnonUser!hfinney(a)shell.portal.com". Put in some other lines telling the actual address of the remailer, as well as a complaints-to: address. Maybe "Sender: hfinney(a)shell.portal.com", or "Remailer:hfinney@shell.portal.com". The "From:" line seems to be confusing people. The author of the article quoted from the Globe & Mail appearantly didn't even understand the disclaimer. The article was worded in such a way to make it seem the disclaimer was saying that Bob Rae didn't really write the message, as opposed to saying that Hal Finney didn't really write the message! Something needs to be done so that even the most internet clueless will understand that the message _isn't_ from Finney or McCarthy or Joe Random RemailerOp, which appearantly isn't clear to many people currently.

2 1

extra dashes in PGP-related blocks?
by jrochkin＠cs.oberlin.edu 17 Dec '03

17 Dec '03

When people have been posting their public keys, or encrypted address blocks, to various lists I'm on, all of the "-----BEGIN whatever..." lines seem to have a "- " preppended to them. So, for instance, they look like: - -----BEGIN PGP MESSAGE----- Version: 2.6.2 [stuff] - -----END PGP MESSAGE----- I'm guessing if I really sent a block like that to a remailer, the remailer would hork because of the prepended "- "s. I know that sometimes people's public keys they've posted to a list look like that, and when I try to add them to PGP, it horks, and I've got to go into a text editor and remove the "- ", and then add it to my keyring. Does anyone know what it is that's putting in these "- "s, why it's putting them in, and how to stop it?

4 8

Re: extra dashes in PGP-related blocks?
by Andrew Lowenstern 17 Dec '03

17 Dec '03

> I'm guessing if I really sent a block like that to a remailer, the > remailer would hork because of the prepended "- "s. I know that > sometimes people's public keys they've posted to a list look like > that, and when I try to add them to PGP, it horks, and I've got to > go into a text editor and remove the "- ", and then add it to my > keyring. PGP does this... Not only does it complicate nested PGP signed messages, but if you pgp-sign an entire MIME message (i.e. by sending it to the autosigning service) instead of placing the signed doc inside the MIME boundries, it can cause mail readers to not recognize the MIME boundries and display the letter as normal ASCII-Mail. andrew

1 0

re: real time surveillances
by Sandy Sandfort 17 Dec '03

17 Dec '03

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C'punks, Mark Hittinger had several thoughts about real-time surveillance. He wrote: ... The technology to fabricate video evidence is there is it not? Big problem with self-surveillance; not a problem with a properly set up system of police surveillance. The critical element is a trusted third-party agency to archive the tapes. There was a relatively recent sad case of two officers that had a video camera installed in their patrol car.... the occupants of the car murdered the policemen and the *entire* scene was obtained on video tape.... It is possible that they might have been saved had this been real-time video rather than taped. Yes, and real-time video monitoring would be a good upgrade when the technology allows it (real-time location monitoring is possible now). In the meantime, *obvious* video recording would also help protect officers in that some perps would think twice before killing someone *on camera*. ... Another great idea would be anonymous real-time monitoring of vital signs along with position data. Auto-911 if you will. We know somebody at this corner had a heart attack 5 minutes ago where is he? The developers of the localizer technology I mentioned in my article have anticipated you. Their equipment can do real-time vital sign monitoring. There are some obvious benefits for wired cops plus some subtle drawbacks for bad cops. (I leave discovery of said drawbacks as an exercise for the student.) S a n d y ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3 3

Re: News->Mail & CMU's Andrew Message System
by cactus＠seabsd.hks.net 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- L. McCarthy <lmccarth(a)ducie.cs.umass.edu> wrote: >Is the AMS software (or some similar system) available as freeware or >shareware somewhere ? I'm considering the possibilities for anonymized >subscription to newsgroups through a mechanism like this. AMS is pretty strongly tied to AFS (now known as part of DCE) and is geared towards sites with users in the thousands. It's probably not what you want, even if it were available (CMU is in the process of phasing it out, since their user base usage has exceeded the design limitations of AMS). >Come to think of it, >many newsgroups are gatewayed to related mailing lists for readers on BBSes >and such; I need to search a bit for the software used to do this. Take a look at newsgate, available somewhere on ftp.uu.net. All you have to do is set up a pseudo-site in your news server's newsfeeds file and send the messages through news2mail. >I'm curious how such systems deal with cancellation messages; presumably they >would simply have to drop them. This would partially eliminate the threat of >spam-of-cancels attacks I mentioned earlier. It totally depends upon the configuration of the gateway and the format of the message. If your gateway passes Control: headers, then cancels will be forwarded to the user and perhaps even be effective if they have another mail-to-news gateway up (that allows Control: headers). Even more so for cancels of the "Subject: cmsg cancel" format, since everything passes Subject: headers. - -- Todd Masco | It's difficult to be loud about keeping your enumerated cactus(a)hks.net | rights when you're busy exercising your unenumerated ones. cactus(a)bb.com | http://www.hks.net/~cactus/cactus.html - --- [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 iQBFAwUBLuyoqSoZzwIn1bdtAQH4gQGAqbROjwEHW6VVYwawXtzeTitdkpWXoytC UNEMT8FPQ49MqbwWnWMJfZDY1CGZoRpU =Yrr9 -----END PGP SIGNATURE-----

1 0

Re: Misunderstanding of Remail Headers
by mclow＠coyote.csusm.edu 17 Dec '03

17 Dec '03

>At 2:13 AM 12/12/94, L. McCarthy wrote: >>Hal writes: >>> There was also a misperception that my remailer was an official effort >>> endorsed by Portal (again, despite the disclaimers). Note that it was >>> they who were contacted, not me (yet). This might suggest that it will >>> not be possible to cleanly separate the remailer operators and service >>> providers when problems like this arise. Both may end up being hassled >>> (time will tell whether I am). >> [ stuff deleted ] >The "From:" line seems to be confusing people. The author of the article >quoted from the Globe & Mail appearantly didn't even understand the >disclaimer. The article was worded in such a way to make it seem the >disclaimer was saying that Bob Rae didn't really write the message, as >opposed to saying that Hal Finney didn't really write the message! >Something needs to be done so that even the most internet clueless will >understand that the message _isn't_ from Finney or McCarthy or Joe Random >RemailerOp, which appearantly isn't clear to many people currently. While I'm all for having clear disclaimers, the facts remain: 1) You can't force people to read. 2) Even if you could, you can't force people to understand. Improve the disclaimers, sure. But don't think that this problem is going to go away because of it. -- Marshall (who has just blown his lurker status) :-) Marshall Clow Aladdin Systems mclow(a)san_marcos.csusm.edu

1 0

remailer list
by fhalper＠pilot.njin.net 17 Dec '03

17 Dec '03

What's the ftp site where I can obtain the latest copy of the list of remailers? Thanks, -RH- --------------------------------------------------------------------------------- Reuben Halper I'm not growing up, I'm just burnin' out." Montclair High - Green Day - Montclair, NJ E-mail: fhalper(a)pilot.njin.net PGP 2.6ui Public Key available upon request ---------------------------------------------------------------------------------

1 0

oh, and by the way...
by perry＠imsi.com 17 Dec '03

17 Dec '03

I forgot one element of my proposed alternative to SSL. For securing HTML documents themselves, use something like the new IETF security multiparts standard, which is suitable for protecting MIME encapsulated documents. .pm

1 0

Re: Real-time surveillance of the police
by Sandy Sandfort 17 Dec '03

17 Dec '03

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C'punks, Don Doumakes wrote: ... why on earth would the police, who will not consent to civilian review, ever go along with something orders of magnitude more extreme? (1) There are civilian review boards; the consent of the police is not a prerequisite. If they don't like it, they can get a real job. (2) It is in their best interests to be protected from false accusations, and to be able to be quickly located under emergency conditions. ObCrypto/Privacy: I suspect there would be an immense amount of radio traffic involved in keeping track of a substantial group of people ... [I doubt] the ability of the receivers to digest it all in real time. (1) My suggestion was for (probably local) recording, not real time monitoring of video; therefore, no bandwidth problems. (2) Tim might want to comment, but my understanding of the localizer technology is that it too is somewhat "local" and that polling or burst transmission keeps the bandwidth requirements at manageable levels. S a n d y ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3 2

Re: Clarification of my remarks about Netscape
by Amanda Walker 17 Dec '03

17 Dec '03

[I'm sending this to the list because it does have some crypto content] "Kipp E.B. Hickman" <kipp(a)warp.mcom.com> writes: > > There is no need to bypass existing efforts just to add cosmetic value to > > your own software. > This has nothing to do with security... Agreed. My annoyance with Netscape is not based solely, or even primarily, on security concerns. In fact, my only annoyance with your security proposal is that it is at the wrong layer (or, more accurately, at layer which should be secondary). In my view, you picked the right technology, but applied it to the wrong problem :). > Clearly I'm an idiot. Explain it to me. SSL is a mechanism whereby a client and a server can establish a secure, authenticated transport channel. The problem is that this isn't what I want to secure and authenticate. Most of the time, in fact, I don't care about the transport: I may be talking through a proxy (like the current CERN httpd), or bringing things in from a cache, or talking to a load-balanced server array. I want the *documents* I'm accessing to be secure and/or authenticated. I want my HTML documents signed and certified by the *author*, not the server. I couldn't care less about the server if I can verify that I've got the right document in response to my query. Similarly, if I send the contents of a form containing, say, my Amex number, I want to encrypt the session key with the public key of the merchant, not the service provider. This is what I (and many others) mean by an "end to end security model." Transport security is a nice secondary ability (it helps defend against traffic analysis, for example, and casual snooping by students with packet sniffers), but without end-to-end security, it's simply a way of providing a false sense of security. I wouldn't want to do away with the TCP checksum field simply because the modem I use for my SLIP link is "error-correcting," and I feel the same way about security. > I put my email address in there for that very reason. Jeesh. I'd rather that technical feedback occur in a public forum like the IETF. I have no pretensions about being a security expert, and I want people to shoot down my bad ideas too. Heck, I *like* having my competitors tell me what's wrong with my ideas :). > > This serves as a direct barrier to competition from other commercial > > vendors. > This is an outright lie. We don't use TIPEM. You could build a > conformant SSL implementation using RSAREF and the freeware IDEA > cipher code. Nope, not if I want to sell it (note the word "commercial" in my comment). RSAREF cannot be used for commercial software, nor can IDEA under the PGP license. There is no feasible way to license the RSA patents for commercial use except by licensing TIPEM. I have been told this outright by Kurt Stammberger of RSADSI (their VP of marketing, I believe). This is not secondhand information. All commercial software that I know of using RSA public key encryption and RSA stream ciphers (such as RC2 and RC4) uses TIPEM and BSAFE, including Lotus Notes and Apple PowerTalk. RSA's royalty structure is based on a percentage of revenue, with the percentage on a sliding scale based on gross corporate revenue (not just on products which use RSA's patents). If you keep your margins low to compete in the marketplace, you lose. Even you folks are making your money on high-margin products (servers) rather than low-margin ones (clients), I'd wager at least in part because it's a way to make money despite having to pay RSA royalties. The RSAREF license has been loosened up some recently, but it's still restricted to freeware. > As for a barrier to competition. So what else is new? We > all have barriers to overcome before we can compete. Should we get rid of > TCP/IP as a barrier to using the web? I don't have to pay royalties to sell an implementation of TCP/IP. Your analogy fails. > You are somewhat right here. In fact, this was done because we are a company > interested in surviving long enough to withstand the eventual attack > by microsoft. You've already got your eggs in the right basket on this one--sell servers and services, not client software. Microsoft has a miserable track record in the server arena (witness the underwhelming success of Windows NT :)). It's also less of a commodity market, which is where Microsoft excels (no pun intended). > As a result we received critical review > from some decent members of the crypto community, including: > > Martin Abadi > Mike Burrows > Alan Schiffman > Matt Robshaw > Burt Kaliski Mostly RSADSI people, by my count. Great technical background, but I wouldn't call relying on one of your technology vendors "peer review"... > As for the IETF standards process, we are pushing the > document into the RFC process. Precisely. Rather than working with others in the industry and research communities, you are trying to push your proposal into the standards track. > The market will decide one way or the other. On this I agree completely. Amanda Walker

4 3

Herbert S. Zim dies
by Philip Zimmermann 17 Dec '03

17 Dec '03

Herbert S. Zim, author of over 100 children's books, including "Codes and Secret Writing", died at age 85 on December 5th in Plantation Key, Florida, where he has lived for many years. He had Alzheimer's disease. I mention his passing because he wrote the first book I ever read on cryptography, which I read in 4th grade in 1964. If it weren't for Zim, I might not have created PGP. -Philip Zimmermann

1 0

Re: extra dashes in PGP-related blocks?
by jrochkin＠cs.oberlin.edu 17 Dec '03

17 Dec '03

At 5:03 PM 12/12/94, Andrew Brown wrote: >but is a remailer (or pgp) smart enough to take the output from checking >a signature and run pgp over it again? is it going to know to take something >and pass it through pgp until pgp can't do anything with it any more? i think >that's the problem that jrochkin was addressing. he has a pgp encrypted >message and then signs it and then wants to mail it to a remailer so that the >remailer can decrypt the message but it won't ecause the encryption is >nested... > >wasn't that it? Well, no, not really. My problem was that a user would send me their public key, inside of a signed message, and the "BEGIN PUBLIC KEY" stuff would have the "- " on it. Which means that before I can add it to my keyring, I've got to edit out the extra "- "s, and then save it in a file, and then pass it through PGP, instead of just passing the original message though PGP, or using the Mac "copy" command on a part of the message and sending that through PGP. Or someone sends me an encrypted address block inside a signed message, and I've got to do the same before I can use it. I now understand why PGP does what it does, but it's still a pain. Perhaps the ideal mail reading program would run my incoming mail through PGP before I even saw it, so I wouldn't have this problem. Well, actually not. My ideal mail reader would check the signatures before I saw them, but would also leave them intact on the message, so I could re-check them myself manually if I wanted. Oh well. It's not a limitation on functionality of any kind, just on convenience.

1 0

Remailer and gateway list
by skaplin＠skypoint.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Can someone please provide me with a list of all of the current remailers and mail -> usenet gateways? Thanks, Sam ============================================================================== The release of atomic energy has not created a new problem. It has merely made more urgent the necessity of solving an existing one. - Albert Einstein ============================================================================== skaplin(a)skypoint.com | "...vidi vici veni" - Overheard | outside a Roman brothel. PGP encrypted mail is accepted and | preferred. | Change is the only constant in the | Universe..."Four quarters, please." E-mail key(a)four11.com for PGP Key or | Finger skaplin(a)mirage.skypoint.com | Smile!! Big brother is watching. ============================================================================== -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: This message digitally signed to verify the identity of the sender iQEVAwUBLuzfI8lnXxBRSgfNAQEH8wf8CON8wTlCcJPalXWfXMUC4efhG319fISX 8DdRWu7hRJWIbxWQ3kUmqVSk6oGHQv9OuiRR1xJH0x+dcKmdfb7CzJkZ50eX92vI HBCdSE4xfBGWKr/CtLVP3ag8OOcd2dMsZRjG0p0y2oV54fYD70KkUXW6mg1L5xUC eZMpWmi3ZgFZC3xSZREa7nv8TnPkpZBgT7mojFNpwn7vPY29L5Zbb78USSmfR0E0 oNY0JyePxiuMXT4XDHV8XrA/f7fTNtXgGJTZAtHE8ZaU6R10NQBx2AKUnh362X0L RqxHPbgC1Q9ooTkAPPw/4qleceM2j2ZjKbzb5DozCshUdEB88fcNsQ== =z2QT -----END PGP SIGNATURE-----

1 0

Time to exhaustively break 40-bit RC4?
by raph＠netcom.com 17 Dec '03

17 Dec '03

The SSL documents say that exhaustively searching 40 bits of RC4 keyspace takes 64 MIPS-years. When I brought this figure up at the cpunks meeting, it was roundly derided. However, I think it might be a sound estimate. The key schedule operation in RC4 does 256 "swap" operations. Let's say it takes four instructions to do each swap. So, it's 2000 instructions per key. A one-MIPS processor can search 500 keys a second. There are about 30 million seconds in a year, so that's 15 billion keys a year. 40 bits is a trillion keys, so it works out to 66 years, which is well within the Pentium-style accuracy of the calculations I've done. Am I missing something here? On the second floor of Soda Hall are about 100 HP Snake workstatations. I think they're about 100 MIPS each. During the winter break, they will be sitting mostly unused. If the math checks out, they should be able to search keyspace in two and a half days. Anyone wanna do some cracking? Raph

6 9

Re: alt.anonymous.messages propagation
by cactus＠seabsd.hks.net 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- (Replied to this once privately, but since mail continues to come in I'll repeat here) In article <9412122127.AA17019(a)hodge-podge.MIT.EDU>, Derek Atkins <warlord(a)MIT.EDU> wrote: >> Nope, no alt.anonymous. 'Leastaways, not off the servers that the turist >> accounts use. And since I configured news on the machine, I'd love to >> hear if there are MIT servers that have a larger set than life.ai's. > >I just looked on news.mit.edu and bloom-beacon.mit.edu (the MIT >news-transport machine), and I found both alt.anonymous and >alt.anonymous.messages, so I don't think saying "MIT doesn't get >alt.anonymous" is at all correct. > >It may be correct to say that "GNU.AI.MIT.EDU doesn't get >alt.anonymous", but GNU is _NOT_ MIT! Yup, that's why I qualified my statement. Can't check on servers I don't know about, after all. FTR, it's not GNU that I'm on/help maintain. It's bronze. So, life.ai.mit.edu is a deficient newsserver and I'll switch the default on bronze to news.mit.edu after appropriate consultations. - -- Todd Masco | It's difficult to be loud about keeping your enumerated cactus(a)hks.net | rights when you're busy exercising your unenumerated ones. cactus(a)bb.com | http://www.hks.net/~cactus/cactus.html - --- [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 iQBFAwUBLuz6VCoZzwIn1bdtAQG1/wF7BAGUuLjGM1JVjpYxP1e6eUYNRSUPrvbX /alvpNH0g8mVFKaSPf8EH1nEeiV4K4Pf =MsKC -----END PGP SIGNATURE-----

1 0

Anonymous Repository
by Tony.Gurnick＠nzdairy.co.nz 17 Dec '03

17 Dec '03

To solve anonymous replys heres a little scenario. Alice wants something from bob (crypto?) but dosent want bob to know (or any others (NSA?)) to know. 1) Alice sends a request to bob via and anon-remailer chain. 2) In the request she specifiys that bob is to put a special code in the message and send it to anon-repostiory(a)nowhere.com 3) Bob sends the info + the special code, for whatever reason. (Payment recieved?) 4) Alice sends a message to anon-repostiory(a)nowhere.com saying to copy bobs message (using special code) to a new secret special code (here code represents a file name) - This message could/should be encrypted and the repository should delete it after the copy is made. 5) At some indetermined time in the future alice ftp`s or sends a mail message to anon-repostiory(a)nowhere.com and retrives bobs message. This should defeat traffic analysis but will do nothing if the repository is compromised! But the same goes for anon-remailers. There are huge blanks in this, so does anyone want to comment? T

1 0

A Golden Opportunity
by tcmay＠netcom.com 17 Dec '03

17 Dec '03

Cypherpunks, It seems to me that we have a golden opportunity to apply our crypto know-how, and our special perspective, to truly important issues. In recent days we have seen on our own list commments from folks from Netscape--surely a major players in whatever's coming--and from attendees at the recent IETF meeting (that stuff is Acronym City to me, so I stay out of the debate). And contributions from Phil Zimmermann, Bruce Schneier, Steven Levy, and the like. "Can't we all just get along?" is a much-laughed-at slogan, but it seems to apply here. We have a golden opportunity to influence the Net of the future, surely a good thing. (And I haven't even mentioned the Cypherpunks connections to digital cash of various flavors.) I understand that this list is no substitute for things like the recently-occurring IETF conference (or whatever it was), but it seems unproductive to be arguing here. (Argument can be good, of course. Amanda Walker _started_ the argument, but the resulting debate has been illuminating, so I think the outcome of the argument has been generally good.) I suppose what I'm suggesting is that we treat the confluence of influntial people here as a good opportunity to debate the future. We probably can't debate fine points in great detail--the list just can't support the passing of detailed specs back and forth--but I think many of us are willing to put up with some acronyms in exchange for you putting up with our non-IETF comments (:-}). The future Net is now being architected. What better time for Cypherpunks to apply their various views? --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. Cypherpunks list: majordomo(a)toad.com with body message of only: subscribe cypherpunks. FAQ available at ftp.netcom.com in pub/tc/tcmay

2 1

public key algorithms and Netscape
by eric＠remailer.net 17 Dec '03

17 Dec '03

The claim was made here by someone at Netscape that no suitable public key algorithms existed other than RSADSI technology. I don't remember how explicit this claim was; it may have been an implication of some more general statement. I note that the folks at Netscape must never have heard of elliptic curve algorithms for public key technology. I would hazard that representatives at RSADSI stated or implied that such technology was covered by their patents. I would then ask if they said so in writing. Making claims about a patent that are knowingly false is grounds for vacating the patent. The IEEE P1363 working group on cryptography standards is moving forward with elliptic curve cryptosystems but not with RSA because of patent issues. Coincidence? Eric

1 0

THROUGH THE LOOKING GLASS
by Sandy Sandfort 17 Dec '03

17 Dec '03

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C'punks, Tim May wrote: ... I don't want to see my local cops have all of their actions videotaped and reviewed for quite another reason--I don't want a "mechanization" of the enforcement process! Won't happen. First, cops are already required to enforce some stupid laws; the mechanism used is "quotas." Second, the vast number of laws makes total enforcement impossible. Third, the cops aren't pulling a fast one when they use their discretion to cut someone loose. I've even seem them do it on the TV show "COPS." That discretion is clearly within their powers. It's the "let's-whack-the-hippie" sort of discretion that is denied them. ... I have some good opinions of the California Highway Patrol ... even a cop-disliking skeptic like me can be convinced that some good is done is by them, and that not all cops are bad.... I agree; and Mussolini did make the trains run on time . . . My proposal is not anti-cop; it's anti- *bad* cop. Good cops *benefit* from protective surveillance; and *all* cops benefit from having their exact location known when the feces impacts the turbine. S a n d y ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

OFF LINE
by Sandy Sandfort 17 Dec '03

17 Dec '03

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C'punks, I am moving back to California. I fly out tomorrow evening. I will be off-line for a day or two at least. Go ahead and send me stuff; I'll get to it as soon as I can. S a n d y ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Re: BofA+Netscape
by marca＠neon.mcom.com 17 Dec '03

17 Dec '03

At 7:50 AM 12/12/94, Perry E. Metzger wrote: >Marc Andreessen says: >> I fully expect we'll be supporting other security standards and >> approaches as they emerge, and we certainly welcome realistic suggestions >> on what we should do, when, and how. > >I told you in Email, Mr. Andreessen, that new transport level security >protocols are useless now that IPSP has come near to standardization >and now that prototype implementations are nearly available. Great, IPSP looks fantastic and we look forward to supporting it as it moves through and beyond the "near" phase. > Many >people at IETF in other groups expressed far less interest in >proceeding with new security protocols now that there will be a >network layer security protocol. However, you did not appear to be >remotely interested. I suppose that you considered the comment I made >"unrealistic". No, I think IPSP is a great idea and I don't thin there's any question we'll be supporting it. >unfortunately, the product is >just too pretty looking. Thanks! Cheers, Marc -- Marc Andreessen Netscape Communications Corporation Mountain View, CA marca(a)mcom.com

4 3

uSuRa anonymous remailer [update]
by Alex de Joode 17 Dec '03

17 Dec '03

I have registerd the domain-name replay.COM at InterNic. XS4all has installed some sort of MX-handling for my account, usura(a)xs4all.nl, so my new address wil be usura(a)replay.com. The remailer that is operated from that account is now also reachable at the replay.com address. The usura(a)xs4all.nl remains valid. Raph Levien has updated the address in his automated pinger; here is the updated PGPkey for the usura(a)replay.COM remailer: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 Comment: Replay and Company Limited. mQCNAi4wTh8AAAEEAMb9gl6NlZHy4FdjADel4d+C+Th7+inTOV4mEsKk+N/QfJAj BN6YPnJ9bm+Ch19FrR1KeTwrpluP6J+GdJrMkVSosvIqBPpSRgOs7nvMhnn3Tnrn uUFZVDYslQ1wRZvFbTpCEW8TzgVhGy6HMznxEC4ttnOq8pFRFUpL3asf+toVAAUR tCt1U3VSYSBhbm9ueW1vdXMgcmVtYWlsZXIgPHVzdXJhQHJlcGxheS5DT00+iQCV AgUQLu0YykpL3asf+toVAQGqhAQAuAnqzqRc5MzYGHmzBVjvUxnEuHiwju4EZmIO OZ5wbxd62gNDV7Nj+M3yj5pnSuwLBL/AOjxLEGRQ49HwvCOLy0wtJWulsg71Pi+y sPkUrP9uq7Aa381Rkwcrcje73WGvFcv89LGtcZlvuiqeNatubbvEgeC9VWb5ovEq jZFLvEI= =snZE -----END PGP PUBLIC KEY BLOCK----- EnJoY. -- Exit! Stage Left. <URL:mailto:usura@replay.com> Alex de Joode <URL:http://www.xs4all.nl/~usura>

1 0