December 2003 - cypherpunks-legacy

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

Re: THROUGH THE LOOKING GLASS
by snyderra＠dunx1.ocs.drexel.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- At 9:13 PM 12/12/94, Sandy Sandfort wrote: >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. sed -e "s/cop/citizen/g" sed -e "s/cop/employee/g" sed... Bob [For the sed-impared: s - search and replace string 1 with string 2. g - do it multiple times per line.] -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBLu0bQeS0CjsjWS0VAQEmzAP+OV59f7hR8CKi6UC13k2x/Fj1QylXPSaj /nR614LzoCeHf7+OAVLN6COx5vGC6yL3EoDL1Ocjm52bWh1nxoIfsGImRBuqRo9R Mcwa6Av+/kn9271O6I6VKLnFU6SYA35vuOAACOAVB647aQ6dAOfheU2fLAd0xEEZ l9mpaNalm7E= =HXZ/ -----END PGP SIGNATURE----- -- Bob Snyder N2KGO MIME, PGP, RIPEM mail accepted snyderra(a)post.drexel.edu PGP & RIPEM keys on key servers When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.

1 0

Re: Broadcasts - addressing
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

> I have been contemplating how to mark broadcast messages as being > 'for' someone. To foil traffic analysis, you don't want to include > their nym or key-id, for the sake of the your poor CPU, you want to > avoid the need to attempt decryption on everything that passes through. The main problem is how to avoid decrypting _most_ of the traffic, without giving away significant information about the recipient. One approach is to do something some political users have been asking for - implement support for very short keyids (e.g. 4 bits instead of 24-32), so that the keyid isn't a good identifier for the user. Another approach is to include a tag in the Subject: with either a hash of the key (substantially reducing the number of bits), or simply the last hex or two of the keyid - that lets you ignore 15/16th or 255/256th of the traffic, without giving away much.

2 1

Photuris
by amanda＠intercon.com 17 Dec '03

17 Dec '03

> Ah, the hazards of not going to IETF... Good thing the proceedings get publicized in electronic format, eh? :) --Amanda

1 0

RE: Crypto Declaration of Independence
by nobody＠jpunix.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- James A. Donald <jamesd(a)netcom.com> wrote: >Anonymous writes >> I have a proposal for you all. >> >> I have started work on a Crypto Declaration of Independence, based on the >> famous American work which represents Independence. > >This is unwise and unnecessary. > >It is unwise because we do not wish to alert the government >to the fact that the net is largely ungoverned and ungovernable. I do not think it is unwise because we do want to state a position for ourselves. We need to let everyone, including the government, know that we will not stand for crypto-policy which is not in our best interest. No matter what comes, we will continue to use PGP, SHTTP, link-encryption and every method which we have determined to be in our best interest, not what we must have faith in what we are told is in our best interest. >It is unnecessary because crypto is already covered by various >existing declarations on rights. > > > >THE BILL OF RIGHTS This is bullshit, and you know it as well as I do. A steady stream of misinformation has mislead government officials into 'ignoring' these rights when dealing with electronic documents, and encryption specifically. When the administration has something which might be unfavorable in the public eye (ie, Clipper), they quickly try to pass it through, ignoring public cries in the process. How many letters did it take before there were any open hearings about the EES, and then the words of respected professionals were seemingly ignored as the policy was pushed ahead. This was not thought to be an extremist attempt at breaking off from our current government. It's also not supposed to be a confrontational attack. It was intended to be a strong statement, letting all know what we believe in and why we do. We need to declare our independence from being governed by policy which encroaches on our rights, rights which this country was founded in, and rights which are being ignored. Asynchronous -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLuwXDFG1rORFKstdAQEc2wP/Ytq8crc/8YiHlYeO9eoF/Mrx4Q39be9t Y1vD/Hn2qcvXUlWqtqfSPZXzpBV10rNH2qZ0L1A7j/ErUxqXm4Xqz36fWDgxht2m t/KWBXydSBzGDt3HEgmXQ29XE0Ka8w9iaXXq0bKfx87l5XPuknOnAyu8ZBEPj4wM dN5Gc4uMdtM= =vrB+ -----END PGP SIGNATURE-----

1 0