December 2003 - cypherpunks-legacy

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