December 2003 - cypherpunks-legacy

PGPfone and (?) boxes
by Alan Patterson 17 Dec '03

17 Dec '03

A couple of months ago, the release of PGPfone got the list started on hardware alternatives to PTN encryption... An associate of mine recently returned from the Consumer Electronics show in Hong Kong and broght me a lot of stuff including a flyer for a telephone scrambler. >From the flyer: Secure your telephone conversations through high-tech scrambling. Never again be concerned with eavesdroppers! Description: With our state of the art Telephone Scrambler you can now discuss confidential business and/or personal matters over the public telephone network without worrying about eavesdroppers. This compact and easy to install unit renders taps and monitors useless by way of rolling code encryption. Eavesdroppers will hear nothing but gibberish, ensuring complete privacy for all your telephone conversations. The Telephone Scrambler allows you to set your own unique code ensuring that only you and the party that you are speaking with can decode the conversation. Two units are required -- one for each end of the conversation. Features: o One-touch scrambling o Thousands of key combinations o "Rollig code" scrambling o Works with Tone or Pulse o Easy connection o LED display o FCC registered o Compact and Portable Specifications: Power: 12 VDC Dimensions: 5 1/2" X 3" X 1" Weight: 6 oz PTN Connection: USOC TJ-11C Keys: 2^12 Company is: P3 Personal Protection Products 405 Park Avenue New York, NY 10022 (212) 421-4757 (212) 421-5024 Fax Well, in itself it isn't very impressive. However, I plan on giving them a call tomorrow and check prices. If they aren't that bad I'll get one and pull it apart. Perhaps it can be at least reprogrammed for more keys and another encryption algo. Hell, at 2^12 keys, all it takes is a few seconds to find which one the conversation is using. Alan Patterson (lep(a)wsnet.com) Fngpt: 41D0F61B496FECC09FABECF686AB2A1C WSNetwork Communications Services, Inc. PGP Encrypted Email Preferred Montgomery, Alabama (334) 263-5505 (800) INET-750 Public Key @ MIT keyserver

1 0

Re: The NSA Visits Compendium
by daw＠quito.CS.Berkeley.EDU 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- In article <Pine.SOL.3.91.951017102059.25411F-100000(a)eagle.nexor.co.uk>, Andy Brown <asb(a)nexor.co.uk> wrote: > On Mon, 16 Oct 1995, Peter Wayner wrote: > > > [...] > > The most interesting thing that he mentioned was thatthe company had to > > guarantee that the data would never be encrypted sequentially by two > > _different_ algorithms. Apparently double encryption by 40-bit RC-4 was > > okay, but using different algorithms was verboten. > > Very interesting indeed. With RC4 the bulk of the time is in key setup, > so if they could do two setups in parallel then the total time to search > a double-encrypted 40 bit keyspace would not be that great. > Hold on -- was the NSA rep talking about double encryption *with two different independent keys*, or talking about double encryption with the same key? Somehow I doubt the latter: for starters, double encryption with the same key with a stream cipher is generally a Bad Idea. (Remember Robert Morris's suggestion to ``always look for plaintext?'') <grin> In any event, double encryption with the same key is never gonna be much more secure than single encryption, because it doesn't increase the key space. But if the NSA ref was allowing RC4 double encryption *with two different independent secret keys*, then this *is* interesting! There are well-known meet-in-the-middle attacks on double encryption (with independent keys); but the standard one requires lots of storage (2^40 storage -- this can't be precomputed if you use 88 extra non-secret salt bits in the key like SSL); a less well-known more recent attack doesn't need the storage, but takes a bit longer (probably a few hundred times longer) than brute force search of single encryption. van Oorschot & Wiener have a paper on this subject. So did you use a SSL-like construction with lots of non-secret salt bits in the key? If not, then the 2^40 bytes of storage could be precomputed, and I'd guess that this NSA position might mean that the NSA has some Exabytes full of precomputed RC4 output for all possible 40 bit keys. :-) Curious, Dave Wagner - --- [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 iQBEAwUBMIbr9SoZzwIn1bdtAQGWOAF0DdBaTogLiH0QDSxjAI8iGeiXFLnPg8pT 2H0cv6rcSSo+23lqB3zZw3UP4uHGeZk= =3KwF -----END PGP SIGNATURE-----

1 0

Re: airport security
by Dan Veeneman 17 Dec '03

17 Dec '03

"Bob Bruen, MIT Lab for Nuclear Science" <BRUEN(a)mitlns.mit.edu> writes: > Without actually agreeing with the FAA, the reason you can't have a name > other than your own on your ticket, as well as why you are required to > be in your assigned seat on take-off and landing is because if there is > a plane crash, they need to be able to identify an otherwise difficult > to identify body. This is *not* how crash victim identification is done. The FAR requirement is only that passengers be _seated_ during takeoff and landing, not that they be seated "where they're supposed to be." In fact, many airlines do not assign seats at all. First come first serve for airlines like Southwest, ValuJet, Western Pacific, etc. Actual victim identification varies from mundane (do they have a wallet on their person, etc.) to rather more gristly methods. > Sorry about this, Don't be sorry. > Bob Dan -- system(a)decode.com (Dan Veeneman) Cryptography, Security, Privacy BBS +1 410 730 6734 Data/FAX

1 0

Ginetta Sagan to give Jing Lyman Lecture at Stanford
by todd＠lgt.com 17 Dec '03

17 Dec '03

My apologies for cross posting this but she is really a great speaker... Todd >Date: Thu, 19 Oct 1995 17:38:43 -0700 (PDT) >From: Samson Tu <tu(a)camis.stanford.edu> >Sender: Samson Tu <tu(a)camis.stanford.edu> >Subject: Ginetta Sagan to give Jing Lyman Lecture at Stanford >To: aiusancal(a)camis.stanford.edu, aiusagr19(a)camis.stanford.edu, > amnesty(a)lists.Stanford.EDU >MIME-Version: 1.0 > >Jing Lyman Lecture on Visionary Women > >Women in the Resistance During World War II and After > > Ginetta Sagan >Honorable Chair, Amnesty International USA Board of Directors > >Time: Noon-1pm, Wednesday October 25 >Place: Oak East, Tresidder Union > Stanford University Campus, Stanford >Sponsored by: Institute for Research on Women and Gender > >end official announcement and begin personal plug: > >For those of you who don't know, Ginetta Sagan, a participant in the Italian >Resistance during the WW II, is the godmother of Amnesty activities in the Bay >area and beyond. She is a spunky, dynamic woman, and a great storyteller. Even >though the title of the talk is about the past, she promises to mention >Amnesty's current concerns. When I last talked to her, she was on the phone >with the IS researcher on Algeria, getting the latest scoop. I especially urge >Stanford Amnesty members to come and see a local celebrity and a great human >rights activist. (Her husband, Dr. Sagan, is a consulting professor at >Stanford.) > Regards, T. S. Glassey Chief Technologist Looking Glass Technologies todd(a)lgt.com (415) 324-4318 -----BEGIN PGP SIGNATURE----- Version: 2.6 iQB1AwUBMFu5E6gNRnWhagU5AQHI+gL+Mwpcd3lAWd8FF06qcG6rnLhIYveHW71a XC7xh1T0uu8qnYX31yMp17OG28jWpKUbWec1IM9/eXOi+gInA7rKICWczV8zo9Z0 0puxjRRN7yO4KfRb3cPpk+r0p6pDg01Y =bTYb -----END PGP SIGNATURE-----

1 0

PARTY! Nov. 18th, sponsored by Community ConneXion
by sameer 17 Dec '03

17 Dec '03

Subject: PARTY! Nov. 18th, sponsored by Community ConneXion (Apologies if you receive this multiple times) Mark your calenders... Community ConneXion: the Internet Privacy Provider is having a party! We're partying to celebrate the spread of privacy on the net, through the increased security of internet products, as well as the growth of our services. (Many new services and new features on existing services will likely be announced before the party. Stay tuned.) We're inviting all our customers and other potentially interested parties, which includes you, if you've received this note. So please join us, and send a copy of this invitation to anyone else you may know who would be interested in attending. Where: Icon Byte Bar & Grill 299 9th Street (at Folsom) SF CA 94103 When: Sat. Nov. 18 1995 7:00 PM This is a good chance to meet and network with the people who are making privacy on the internet a reality. Find out more about the HackNetscape and HackMicrosoft contests. Learn about our specialized web services, found nowhere else but at Community ConneXion. Hear about the anonymous and psuedonymous servers here and what we're doing to improve them. There will be catered snacks and a no-host bar.

1 0

ANSI to work on e-payment -- first meeting coming up
by Rich Salz 17 Dec '03

17 Dec '03

First Meeting of Electronic Commerce Work Group November 29, Washington, DC ANSI Accredited Standards Committee X9 - Financial Services - in response to the explosion of payment transaction proposals for the internet, has approved a new work item to develop a single secure electronic payment syntax. The first meeting of the Electronic Commerce Work Group will be Wednesday, November 29 from 9:00am till 5:00pm at the American Bankers Association, 1120 Connecticut Ave, NW, Washington, DC 20036. Agenda Review of Scope of Work Consideration of Federal Reserve Request to expand scope to Bank-Bank messages Presentation from Industry groups with existing payment protocols Assignment of work items New items Next meetings (Jan/Feb. - San Francisco, May - Boston??) A draft scope: The payment syntax described in this standard is designed to order a financial institution to make payment to a merchant from an account of a purchaser based on the near term delivery of low monetary value goods or services. It will be possible to include this payment order in any electronic protocol that is based on communications between the purchaser and the merchant, and between the merchant and a financial institution. This standard does not describe, nor recommend, any particular communications protocol. When used within a complete payment infrastructure, the secure payment order described shall offer privacy and integrity of the purchaser's payment information, and shall prevent the purchaser from successfully repudiating the sending, or the merchant from successfully repudiating the receiving, of a valid payment order. Thus the financial institution can be sure that its customer requested the payment and that the merchant can be accurately identified on the account statement. About ASC X9 ASC X9 is the accredited standards developer which brings together banks, securities trading companies, equipment and software manufactures, associations and others in the financial services industry to develop voluntary nationally accepted standards based on industry consensus. Founded in 1976, ASC X9 was accredited by the American National Standards institute in 1984. The American Bankers Association serves as X9 Secretariat. For more information on X9, contact the secretariat at 202/663-5300, for more information on the Electronic Commerce Work Group, contact its chair, Tom Jones at 602/554-3569.

2 1

old doc cohen
by an116512＠anon.penet.fi 17 Dec '03

17 Dec '03

<<this post was written by me and two other people who have been watching cohen's career for the last few years. i'n sorry for the spelling mistakes and typos.>> dr frederick b. cohen's frequent rants in which he expresses nothing but contempt for everyone else in the security and crypt business have to be understood in their context: he's trying to sell something. what's he selling? who's he trying to sell it to? there are several answers. all are partly true and taken together explain his posts pretty well. directly, he's trying to get us to buy his products, services, and books, or at least recommend them to others. it is obvious how setting himself up as the only one who recognizes these serious flaws would enhance his consulting business. he doesn't care about netscape or pgp. he cares about his wallet. indirectly, he's testing out halfbaked ideas here to better learn how to refute those who see through their weaknesses so that he'll be better prepared when he spews in more "serious" forums. this is a low risk place, as far as he's concerned, to make a fool of himself. socially, he's selling the idea of his own academic respectability. notice how he reminds us he's "dr." (look at me! i have a doctorate!!!) cohen. the truth is he never managed to get the respect of the mainstream academic and research worlds. he's been reduced to playing the role of victim-soothsayer. we'll all regret not listening to him back when we had the chance, one of these days. look at the reaction to his "seminal work" on viruses for a great example of how the real research world yawns at him to understand why this is so important to him. he feels cheated out of the respect he deserves. (he's willing not to care about his wallet to the extent that he gets this) psychologically, he's selling the idea that he's respectable to himself. ultimately it doesn't matter that most of us see right through him as long as he gets enough people listening to him to feed his very delicate ego. he needs us (someone, anyone, even us cypherpunks if that's what it takes) to love him and take him seriously. it's very sad. let's just ignore him. he'll find somewhere else to play (he always does). --****ATTENTION****--****ATTENTION****--****ATTENTION****--***ATTENTION*** Your e-mail reply to this message WILL be *automatically* ANONYMIZED. Please, report inappropriate use to abuse(a)anon.penet.fi For information (incl. non-anon reply) write to help(a)anon.penet.fi If you have any problems, address them to admin(a)anon.penet.fi

1 0

Don't Kill the Messenger--A New Slant on Remailers
by tcmay＠got.net 17 Dec '03

17 Dec '03

(I was out of town most of the past few days, when the debate about this "Modest Proposal" happened. In reading the messages in the thread, I see a lot of the issues mentione that we talked about several years ago--not that this is a sin to talk about issues more than once--and that led to the creation of "message pools" and groups like "alt.anonymous.messages". But some new ideas are emerging. And I have a new idea for a remailer, so this is turning out to be a fruitful topic! Too bad the topic has already died, apparently.) At 4:36 PM 10/18/95, Hal wrote: >Eli Brandt <eli(a)UX3.SP.CS.CMU.EDU> writes: > >>If you >>split the message into shadows, you avoid having anyone in this >>position. > >I think splitting the message would be OK, but then the question is who >is responsible for reassembling it? If there were a "reassembly >server" which took such messages, assembled them, and forwarded them, >then we would be right back where we started from. If the end user is >responsible for reassembly, then that is tantamount to voluntarily >agreeing to receive anonymous messages, and that is no problem. The >complaints we get are virtually 100% from people who didn't want to >receive such messages, or see them posted. And of course anonymous news >postings via shadows would also have the reassembly problem. Hal succinctly describes the conceptual flaws in many of these schemes to replace the "last remailer" with something else: it usually turns out that such replacements either don't work (forging headers) or merely shift the problem to another agent. The most practical short term approach is for any remailer operator feeling some heat to do what Hal does with his Caltech remailer: remail to a site less likely to cause problems. For example, bounce all messages through a Netherlands remailer. (Even if the NL remailers are ultimately shut down, using them accomplishes the practical purpose of removing the heat from one's self...of course, they might feel the same way and lob the message back to U.S. remailers!) (Leading to the "Dining Buck Passers Problem," where a message never gets delivered because all remailers are passing the buck by lobbing the message to other remailers...."Charlie on the MTA.") THE ROLE OF THE "MESSENGER" But I think I have a longer term solution, one that involves a change in thinking about the differences between the _originator_ of a message and the mere _messenger_. The notion is to much more explicitly separate the functions of the "messenger" or "deliverer" from the "originator" or "sender." Granted, this is already done in the sense that a piece of e-mail goes through many hands. For example, Hal's message that I am responding to here has this in the header blocks, showing some of the "couriers" or "messengers": Return-Path: owner-cypherpunks(a)toad.com Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by you.got.net (8.6.9/8.6.9) with ESMTP id KAA08536 for <tcmay(a)got.net>; Wed, 18 Oct 1995 10:47:24 -0700 Received: from toad.com by relay3.UU.NET with SMTP id QQzlzw04926; Wed, 18 Oct 1995 13:06:48 -0400 Received: by toad.com id AA06207; Wed, 18 Oct 95 09:38:06 PDT Received: from nova.unix.portal.com by toad.com id AA06198; Wed, 18 Oct 95 09:38:02 PDT Received: from jobe.shell.portal.com (jobe.shell.portal.com [156.151.3.4]) by nova.unix.portal.com (8.6.11/8.6.5) with ESMTP id JAA01733 for <cypherpunks(a)toad.com>; Wed, 18 Oct 1995 09:36:59 -0700 Received: (hfinney@localhost) by jobe.shell.portal.com (8.6.11/8.6.5) id JAA17879; Wed, 18 Oct 1995 09:36:58 -0700 Date: Wed, 18 Oct 1995 09:36:58 -0700 From: Hal <hfinney(a)shell.portal.com> Now, by convention, we don't treat the _intermediate_ steps in the same way that we treat the "From: Hal <hfinney(a)shell.portal.com>" step. So, why do many treat _remailers_ as originators? Mostly, it's education. People get a message from "remailer(a)kremvax.org" and they are trained to think this is the sender. Or, they are trained to think they can send a message back to this site, or to "root(a)kremvax.org" complaining abou the mail they received and expecting that something will be done to make it stop. But trying to educate people that a remailer is not the same as a sender is likely to be a long and disappointing process. A better approach is needed. I believe that by changing the nature of remailers and making them much more explicitly like messengers, couriers, and delivery services, that we can win the public relations battle. There may still be legal challenges, but at least the semantics will not be so confusing. Just as Willis Ware made the point to Michael Froomkin about the confusing and misleading semantics of "escrow," I believe the same is true of the confusing and misleading semantics of "remailer." Perhaps we should just change the name from "remailer" (or "mix") to "Message Delivery Services." Perhaps some of you can think of a shorter and catchier term that still makes the messenger role clear. (I hang out on the Cyberial mailing list for cyberspace law discussions, so I am well aware that any change such as I am suggesting must also be tested as a legal strategy, and that conceptual ideas may not hold water, legally. I won't address legal issues here, at least not now.) The idea is to make it much more explicit that a remailer is merely _delivering_ a message. Few people hold their local postal carrier responsible for delivering a letter containing "bad material," be they threats, hate speech, unwanted pornography, etc. Likewise, package delivery services are generally not held responsible. And telephone answering services are not treated as the authors of, say, threatening messages, when they pass on messages such as: "Tim, you received a call at 4:15 p.m. saying that if continue with your project to collect reports of NSA visits to software companies that some guys dressed in blue suits will try to run you down in your parking lot." In these cases, we don't kill the messenger. We don't even sanction the messenger. And it's more than just that we treat the messenger as being ignorant of the contents, as the telephone message service example shows: there are several examples I can think of immediately in which harmful or hateful speech is relayed to someone with no expectation that the relayer will face sanctions. This is much more than the oft-cited doctrine of "common carrier" status, where the government (it is claimed) grants to the phone company certain rights and responsibilities with the proviso that it will not hold them liable for the _content_ of phone calls. (I'm not sure if Federal Express is treated as a "common carrier," but I'm fairly certain they are not held liable for various evils delivered in sealed packages, with certain obvious exceptions involving cooperation with law enforcement.) I'm not a lawyer, but I believe the law recognizes (and has for a long time) that the messenger of bad or harmful news, or mail, etc., is not to be held liable. There are oft-debated examples involving a newspaper editor's responsibility not to "relay" libelous material, and so forth, but these are not cases of mere couriers or messengers. (Counterpoint: And yet couriers who knowingly transport drugs of course face sanctions. This is a case where the possession (and hence transport) itself is illegal. This involves scienter--awareness--of what is being transported, in a way that delivery of an encrypted message clearly could not. Or even unencrypted messages, if the messenger could make a plausible claim that he does not look at or screen messages. Lots of issues to discuss.) A MAIL DELIVERY SERVICE (don't we already have them? yes, but....) So, how would this work? With remailers, even more steps need to be taken to make it absolutely clear that the delivered message is not _from_ the last Internet site that shows up in the "From:" field. More than just disclaimers are needed. One approach is for a _notification-based_ system. To wit: "You have a piece of mail awaiting at our mail delivery service. The originator is unknown. The title of the message is "Tentacles of Medusa Must Die!" You may retrieve this message by replying to this notification with the word "Yes" anywhere in the Subject field. This message will be kept for 60 days and then deleted." The idea being to more carefully distinguish between mere messengers and the "From:" field (not that "From:" establishes origin, as we all know from the whole point of remailers, but most people associate "From:" with an actual originator, wherein lies the problem). It would also lessen complaints from people who suddenly find unwanted mail arriving anonymously. People would have to make at least some token effort to "accept delivery." Similarities to "general delivery" mail delivery are obvious, as are similarities to fee-based mail forwarding services and "Mailboxes Etc." services. (By the way, and not to digress again, but I see systems like this as the likely future of mail. Some scheme where a user chooses to accept or reject delivery--as with packages delivered which one can refuse delivery on--is needed to solve several problems: mailbombs, unwanted illegal material arriving, the sheer flood of mail, etc. And with people moving around, changing companies, wanting anonymity, etc., such mail service sites will be a natural fit. Having them add filtering services, a la MailWeir, is one obvious service.) This could be implemented as a new type of remailer. This could also integrate with paid delivery systems, a la digital postage. (I can imagine some people demanding to be paid some small amount to receive a message....this is not feasible with the current "free delivery" model, but a lot of things are not possible with "free delivery." But I digress.) I'll quit for now. Lots of issues. "Don't kill the messenger." --Tim May Views here are not the views of my Internet Service Provider or Government. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

4 4

Re: Postscript in Netscape
by lyalc＠mail.mpx.com.au 17 Dec '03

17 Dec '03

> >WRONG!!! Netscape claims to be "secure" - hence it is Netscape's job to >be secure - regardless of the user's use of their product. Otherwise, >the ads should read: > > "Netscape can be used securely by sufficiently knowledgeable > users who have emasculated their postscript interpreters before > using them to view files of unknown origin, and who have removed > all other known, unknown, and/or undisclosed security holes from > their systems. Otherwise, Netscape is insecure and should not be > trusted." > >-- cars are claimed to "safe". That only applies is driven sober, within speed restrictions and road conditions by a (basically) trained driver. The same analogy applies, in my view. lyal

1 0

Re: digital cash and identity disclosure
by Holger.Reif＠PrakInf.TU-Ilmenau.DE 17 Dec '03

17 Dec '03

Scott Brickner writes: >Andreas Bogk writes: >>But as far as I got Chaums idea, Alice would not reveal Bobs identity, >>but rather her own. Am I missing a point here? > >You're right. Tim's wrong. Bob can't spend the money Alice gave him >without depositing it in the bank and getting new money issued. Each >coin has "This money was issued to Alice" as an invisible imprint which >only shows up when two coins with the same serial number are together. I don't understand how this could happen? The two coins are identical (as I understood it from the tech backgound of ecash). what has a double- spended coin what a copied single-spended coin not has? Forgive if I missed relevant postings to this subject since I only read parts from the list offline. read you later - Holger Reif http://remus.prakinf.tu-ilmenau.de/Reif/

4 4