- cypherpunks-legacy - lists.cpunks.org

CDA Yes Votes; Collection
by Tim Cook 17 Dec '03

17 Dec '03

Find out if yours ( or any ) representative or senator voted for the CDA. Send me email with the subject CDA-YES. Put their name and where they are from in the body. I'll compile the list and post it. When this is over they'll wish they realized how powerful the internet REALLY is. Besides, what makes the US Congress think they have any control over a worldwide network? PS. Repost this msg where appropriate. I'm only posting to cypherpunks. Another "Logical Conclusion" by: Tim Cook <twcook(a)cts.com> Support THE US Constitution... Vote Alexander in '96 and '00!

1 0

Accounts...
by Thomas Riggley 17 Dec '03

17 Dec '03

This brings up an interesting point to which I have been trying to create a person list myself. Certain systems out there offer Free account to anyone without any sort of identity check.. I have only found a couple myself and all of them seem to limit access to News and ftp unless you send them money... However I am still looking for these computers which seem to offer the best anonymous access to anyone... Could you please e-mail me ANY sights that offer free/cheap internet access via telnet that do not check id? -Tom -=><=--=><=--=><=--=><=--=><=--=><=--=><=--=><=--=><=--=><=--=><=- * * * Thomas Riggley jester(a)cyberspace.org * * * * What ever happened to privacy?! * * * -=><=--=><=--=><=--=><=--=><=--=><=--=><=--=><=--=><=--=><=--=><=-

1 0

L.A.-area meeting Karl Hess
by j.hastings6＠genie.geis.com 17 Dec '03

17 Dec '03

> > (The same Karl Hess who is involved in libertarian matters.) > The same Karl Hess (sadly departed on the same day as Tricky Dick > Nixon) who wrote for Goldwater: "Extremism in the defense of liberty > is no vice, moderation no virtue" When William F. Buckley was here in Southern California to give a speech at the AARP (buncha greedy old geezers), he was more concerned about Karl Hess than Tricky Dick. So I heard from a friend who met WFB there for other business. Here's the real text: "Extremism in the defense of liberty is no vice, and let me remind you, moderation in the pursuit of justice is no virtue." Hess admitted that it came from someone else, I think Tom Paine, but he was the one who got it into Goldwater's speech. When I posted my Karl Hess club flyer a while back, a few people implied that I was an incompetent, bungling moron just because I forgot to say "L.A. area meeting." That's Los Angeles, not Lake Arrowhead. In California, the United States of America, Western Corporate Fascist Empire, Earth, Solar Federation Slave Labor Star System. Others thought it was off-topic. One guy complained about weird ASCII characters like , , , and perhaps . Heh heh heh. So "let me remind you" if you are in the LOS ANGELES AREA, or know someone who is and might be interested, that the Karl Hess Club will meet in the Alpine Village Restaurant Emerald Room, Monday, July 18, 1994, at 7 P.M. Torrance Blvd exit off the 110 freeway, presumably in the City of Torrance. I will be doing my mega-bit to Sink Clipper by distributing PGP. Victor Koman will deliver a timely presentation against NASA, based on the research he did for his new novel, Kings of the High Frontier. Three cheers for "Subnationals in Space." No reservations needed, and free admission. If you want dinner, the arrangement with the restaurant is $17 prix fixe incl tax and tip. Kent - j.hastings6(a)genie.geis.com

1 0

Re: Leaving the Country
by tim werner 17 Dec '03

17 Dec '03

>Date: Sun, 17 Jul 1994 18:27:52 -0400 >From: "Perry E. Metzger" <perry(a)imsi.com> > >Goldwater was a friend of his to the end. Recently, some Republicans >have been shocked to discover that Goldwater supports equal treatment >under the law (although not "affirmative action" or other similar >crud) for Homosexuals and other similar unattractive groups, and that >he holds other evil "liberal" views. Some conservatives have gone so >far as to denounce him for "slipping". They never have understood what >his views have been all along, either. > >However, might I point out that none of this has anything to do with >cryptography? That may be true, but does it have to do with punks? tw

1 0

Re: PC-Expo
by lassie!jim%lassie＠netcom.com 17 Dec '03

17 Dec '03

passes. I think handing out floppy disks is NOT a very cost efficient scheme. It makes more sense to spend the money on xeroxing flyers explaining to people what encryption is, why it's important and how they can get the tools for themselves. Very people are going to load up a program from a disk that some stranger gave them. You'll also likely get thrown out of Javitts. I think that uploading to a local BBS is a bueno idea. I downloaded all PGP and shell programs from Internet and then uploaded them to a local BBS. I then put a classified add in the local Mensa paper (monthly) and gave phone number, description and asked that if anyone downloaded the files to upload a copy to their favorite BBS. In Haydukes book "Get Even" they called this the multiplier effect. Although the add costs me nothing and they circulation is only around 900 or so issues there is a good chance the software will travel to another 25 or so boards. I am also condidering taking out an add in the Arizona Republic (circulation aloat) and offering PGP !!!!FREE!!!! to anyone that calls my friends BBS. That should make him happy and should also spread the program to thousands of non Internet users. The cost to me is about $25 but the satisfaction is imense. Hayduke is right about the multiplier effect, just like I said about faxes earlier. If all members of this group fax to their non-long-distance government representatives then we can get the word out effectivly stronger than any other group. The ol' multiplier effect on the good ol' cypherpunks group. several hundred times 6 is 1200 messages from one letter. I think this is good. -- * Spelling errors are intentional and international * Jim Nalbandian netcomsv!lassie!jim%lassie(a)netcom.com Tempe, Arizona, USA N7SZS(a)K7BUC.AZ.US.NA No free man shall ever be de-barred the use of arms. The strongest reason for the people to retain there right to keep and bear arms is as a last resort to protect themselves against tyranny in government. <-------- Thomas Jefferson --

2 1

Some informed comments on RSA's S/MIME
by Rich Salz 17 Dec '03

17 Dec '03

Date: Thu, 14 Sep 1995 08:39:49 -0700 (PDT) >From: Ned Freed <NED(a)innosoft.com> Subject: Re: Re[2]: MOSS conformance testing Cc: pem-dev(a)TIS.COM Message-id: <01HV9F2PHBSU8Y4Z8U(a)INNOSOFT.COM> > I just got wind of RSA's draft for Content-Type: application/x-pkcs7-mime. > Has there been any discussion on this - comparison to PEM etc.? If so > where's the list, URLs of archives....? Or did I just go "deaf" for a while > here on thist list? (The last could of months have been caught up in > changing companines...) S/MIME was developed privately by RSA in conjunction with a number of other companies. To the best of my knowledge all discussion has occurred on closed, private lists. As a potential customer of RSA I recently managed to get myself added to one of these lists (it may or may not be the only one where S/MIME is discussed) but I haven't had time to post anything there yet. I plan to post this message there in the next couple of days. I'm not saying this approach to protocol development is a good thing or a bad thing, but I do believe that it has led to the production of a specification that is seriously flawed, and that those flaws would have been detected and probably corrected had the discussion been more public. More on this below. > I browsed through the IETF drafts & personal contributions & search tool... > didn't find anything on RSA's "S/MIME". > I did get the PostScript file from RSA's pages & had a read.... > http://www.rsa.com/pub/S-MIME/ The specification, at least, is public. Given the amount of press surrounding this proposal and the strong liklihood of it being widely used I strongly recommend that everyone who is interested in email security obtain a copy of the specification and read it. However, the proposal is simple enough that it can be summarized in just two paragraphs. S/MIME is based on PKCS #7, which in turn is based on classic PEM. The significant difference between PKCS #7 and PEM is that it uses an ASN.1 encoding for the entire security object rather than the header/text encoding of RFC1421. In fact the specification states that mechanical conversion between RFC1421 formats and PKCS #7 should be possible as long as the proper set of algorithms are used. I think that mechanical conversion into and out of the PEM-derived subset of MOSS is also feasible but I haven't checked up on the specifics of this. S/MIME in turn is a simple encapsulation of PKCS #7 in MIME, consisting of an application subtype label and an encoding of the PKCS #7 object using standard MIME encodings. The inner secured content is then seen as another MIME object. This is almost identical to Jeff Schiller's earlier proposal for embedding PEM in MIME. There is only one significant twist -- in the case of signed but not encrypted data the specification calls for the use of multipart/alternative, with the first part being an unsigned copy of the signed data and the second part being the PKCS #7 object, including the signed data. Two obvious flaws in this approach should be obvious from this description. The first is simply one of excessive overhead -- sending signed material in such a way that it can be read on vanilla email systems as well as with an S/MIME system introduces something on the order of 133% overhead. The second flaw is more serious. The data that a user without S/MIME reads is not signed. This opens the door to attacks where the unsigned version is tampered with but the signed version is left alone. This turns into a really insidious problem when you consider how privacy services are likely to be deployed in some environments. One model I expect to be rather popular is that of having a remote signature verification service within a secure enclave. That is, most of the user agents that people use won't have the ability to validate a signature. Users will, however, have secure access to an agent that will validate the signature on a message for them. (The service may well be a different application on the same machine.) They simply submit the message to this service and it tells them whether or not the signature matches. The problem, of course, is that the material the user of the unextended agent reads isn't what's signed. And in general there is no way to correlate this material with the signed copy -- since it was exposed to the message transport layer without any special tagging to indicate its signed nature the transport may well have changed it so its no longer a byte-for-byte copy of the signed version (which is inherently protected against such munging). Comparing this approach with security multiparts is quite instructive. Security multiparts only introduces the overhead necessary to encode the single copy of the data -- at most 33% in the case of base64 -- plus of course the fixed overhead of the signature information. As such, it is far more efficient than S/MIME when it comes to signed but unencrypted material. Security multiparts can be processed in a single pass as well. I'm not sure this is true of S/MIME -- it depends on the specifics of the ASN.1 structure that's used. But by far the most important difference is that security multiparts do not suffer from this vulnerability when used in an environment with remote security servers. You can of couse avoid this problem by not including the extra copy of the signed material. The problem with this approach is that you won't be able to read such a message on anything short of an agent that knows how to take apart a PKCS #7 structure. I note in passing that there was absolutely no reason why security multiparts could not have been used in S/MIME instead of the chosen encapsulation. PKCS #7 explicitly provides a facility whereby the secured data is stored outside of the ASN.1 object. This then fits seamlessly into the security multiparts methodology. I do not propose to debate the relative merits of PKCS #7 versus MOSS. Modulo the MIME issues this is essentially the same as debating the merits of PEM versus MOSS, and I've had more of that than I care for. Besides, I think folks should use whatever security service they feel like using. I've maintained all along that my interest is primarily that of standardizing on a single embedding methodology for use with MIME. I'm very disappointed that S/MIME has seen fit to use what to my mind is a technically inferior embedding solution when compared to security multiparts, and I'd really like to try to get the S/MIME folks to switch to a security multiparts approach if its not too late for them to do so. I'm very interested in any and all comments on what I've written here. I intend to post them to the S/MIME list I'm now on. Ned

1 0

Loi Log
by anonymous＠freezone.remailer 17 Dec '03

17 Dec '03

There was an uncharacteristically long delay (2+ hours) in receiving documents from the <http://www.cnam.fr/Network/Crypto/> site, including those linked to non-fr sites. Not sure if it is due to self-applied site restrictions or the other loi-logging.

1 0

Re: Linking = Showing = Transferring?
by Rich Salz 17 Dec '03

17 Dec '03

> I think this case is safer than the porn one, because the actual data > in this case is legal in both jurisdictions, it just must not be > transferred from jurisdiction US -> jurisdiction non-US, which it has > not been. I believe you're right, this is the key distinction which I missed. (Disregard my earlier email to you :) Thanks for the patient explanation. /r$

1 0

Re: ecash remailer
by Bill Stewart 17 Dec '03

17 Dec '03

Sameer and Hal both suggested ecash-laundering methods to provide payee anonymity using methods like this: >Enterprising cypherpunk, Ed sets up the Ecash Remailer. >Alice pays Bob e$15. Alice is anonymous. >Bob sends Ed the e$15 >Ed cashes the e$ into his ecash mint account, withdraws e$13.50 >then pays Bob those e$14 .. Bob can now spend those e$ at will. > Bob is now anonymous. As implemented here, Ed is strictly in the money-laundering businesss, and can expect a visit from the Feds as soon as they can break through the chain of digital mixes and crypto he uses to operate alt.money.laundry, or follow the money when _he_ tries to deposit it. On the other hand, he could operate a strictly legitimate business, selling financial assets such as bearer bonds or low-commission lottery tickets, or converting funds between different e-banks, or simply offering anonymous bank accounts with currencies in multiple denominations - Bob can set up an account with Ed's Eurocurrency Exchange in the name "Public Key nnnnn", deposit his $15, and withdraw US$14.95 worth of Yen or Deutschmarks or Kongbucks. Aside from Bob's need to trust Ed, and his need to trust Alice not to double-spend (since laundering used bills is much harder than laundering marked bills) it first looked to me like Ed has a serious risk that he'd be nabbed by the Feds as soon as he tried to spend the bills, so he has to trust Bob not to be spending ransom money or pharmaceutical profits. But as near as I can tell, _any_ merchant has that risk, because there's no way for Ed to distinguish between cash that Bob withdrew himself and cash that Bob got from someone else. Does this mean that anybody who sells goods to anonymous clients is automatically a money-launderer? If so, either the bogus money-laundering laws have to go (yay!) or laws against selling to anonymous clients will get written (boo!) or selective enforcement and entrapment will become increasingly popular, leading merchants to refuse to do anonymous business just to defend themselves against extortionists\\\\\\\\\\\\legitimate needs of law enforcement? #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

2 1

Re: NSA on GAK
by Rich Salz 17 Dec '03

17 Dec '03

Yeah, really. I didn't say it isn't true, I just said it's more like a cute quote than truth. Compare the number of bits downloaded in TCP/IP and routing infrastructure to the number of bits that are purchased at the store or via a P.O. Miniscule. r$

1 0