December 2003 - cypherpunks-legacy

Re: Postscript and 50 ways [MAJOR NOISE] [long]
by patrick＠Verity.COM 17 Dec '03

17 Dec '03

I too had to put up with Dr. Fred on the firewalls list. I don't see what you hoped to accomplish by posting this off-topic mean spirited stuff to cypherpunks though. There are many others here that are also on firewalls, and we've let Dr. Fred speak for himself. Everyone has already formed the opinions they'll likely have, and it seems the only purpose of your tirade is to mean-spiritedly kick a man when he's down. It doesn't reflect well on you, it wastes our time, and is a bit sickening. Were you one of the people making the geek dance in high school too? I really wish you'd apologise to the list for this crap. We're here to discuss cypercoolness, not flame people, (whether they might seem to invite it or not). Lately this list has turned into a flame the geek list. It's not quite the fun it once was, and it's embarassing to watch. Patrick _______________________________________________________________________ / These opinions are mine, and not Verity's (except by coincidence;). \ | (\ | | Patrick J. Horgan Verity Inc. \\ Have | | patrick(a)verity.com 1550 Plymouth Street \\ _ Sword | | Phone : (415)960-7600 Mountain View \\/ Will | | FAX : (415)960-7750 California 94303 _/\\ Travel | \___________________________________________________________\)__________/

1 0

Re: Postscript in Netscape
by James A. Donald 17 Dec '03

17 Dec '03

At 07:56 AM 10/18/95 -0400, Dr. Frederick B. Cohen wrote: > 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: Warning: This bullet proof vest will not protect you if you take it off and stand in front of a gun. If you download a virus infested executable using netscape and execute it, what do you expect? --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.jim.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the state. | jamesd(a)echeque.com

1 0

"power one time pad"
by Paul Koning 1695 17 Dec '03

17 Dec '03

I'd be interested in reactions to the article in Network World, 10/16/95 issue, page 53. It describes a supposed cryptosystem that sounds bogus, but I can't make up my mind about how much is the system and how much is the confusion of the author. Among other things, it says that POTP "doesn't use an encryption algorithm; instead it synchronizes random processes on two computers as they communicate". (I wonder if the author understands that that's just another way to describe encryption algorithms...) The other claim is that it eliminates the need to manage keys. "... there is no need for central servers where PGP keys ... are kept". This seems like a strange claim because of course PGP doesn't require central servers, but more importantly, you can't do authentication without at least one piece of keying data being established out of band. That could be a certification authority public key, but you need something to get started. Supposedly this thing was shown at Interop. Did anyone see it, and does the product make sense even if the article didn't? (One thing that disturbes me about the product name is the use of the phrase "one time pad". Since the "random" processes are presumably not random but rather pseudo-random, there is no one time pad involved at all, but rather a plain old stream cypher of some sort, which may or may not be secure in practice but cannot have the "secure from first principles" property that real one time pad has.) paul (pkoning(a)chipcom.com)

4 3

Re: Don't Kill the Messenger--A New Slant on Remailers
by Tom Rollins 17 Dec '03

17 Dec '03

tcmay(a)got.net (Timothy C. May) wrote: >(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.") There could be a risk based messgae market here. That is what the Futures market is about speculation and hedging (buging and selling risk). What is a risky message in one country may be acceptable in another. > > >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 I like the Mail Delerery Service idea combined with user selectable filters. I would also like to see the merging of different message transmission technology using gateways. We have gateways... Fidonet to/from internet, email to newsgroup, and Telegram to (snail) mail. Would it not be beneficial to add other gateways such as email to snail mail, email to fax, fax to email, snail mail to email, and CB to email. Remailers are in place in the RF world. They are called repeaters or transponders. They perform the function of taking a weak signal and boost it's power so that a larger group of receivers can pick up the signal. Ham radio has (vhf ?) repeaters in metropolitan areas. Satellites use transponders allowing the signal to be sent from horizon to horizon. (this already has potential problems. Hughes is comming out with a product called DirectPC. I believe it allows you would transmit over a slow modem but receive high data rates from a satellite. I guess if you just look at or edit some crypto source code from your shell account, it would be exported as far as the satellite horizon as a byproduct of being sent to your display). Does it not make sense for some kind of listening post to be set up to take messages sent via Satellite, Ham radio, or CB and either place them in a newsgroup or an archive site or a mail delivery service? Transmitting your anonymous e-mail by CB would be kind of nice. Some of these RF modes are highly regulated. I believe that Hams already have packet radio but cannot encrypt data and are accountable for all the data being sent on their transmitter. CB seems less regulated , perhaps because of it's limited power and range. (this would change with an internet repeater.) I don't know about satellite regulation, but recall some CNN broadcast out of Bagdad with a portable transmitter during Desert Storm. Perhaps that kind of equipment will be cheap and available in the future. Is public access limited to cable? -Tom Rollins <trollins(a)hns.com>

1 0

Re: responce to graphic encryption replies
by Rev. Mark Grant 17 Dec '03

17 Dec '03

Urk.. not wanting to start up the "MIME is Evil, ASCII Forever !" thread again, but it would help those of us who have to use MIME-supporting mail programs if you didn't send messages as MIME attachments, pine is too stupid to actually include the attachment in the reply... > How Secure Can PrivaSoft Be? > The typical policy is to limit the allowable cryptographic strength of > commercial products to a level that is strong enough for commercial > purposes. Sadly, that's not true. The typical policy is to limit the cryptographic strength to a level that the NSA or a few hackers can break. IMHO 40-bit RC4 doesn't come close to being strong enough for commercial purposes, at least for anything other than trivial messages. > The cryptographic engine of PrivaSoft PrivaSoft uses a pseudo-random > generator that is seeded by a 9 digit number uniformly normalized from > the user's secret key. So that's about 30 bits ? Hmm, the computer on my desk kicked butt five years ago, but today it's not much use for anything other than an X-terminal, and slower than my $1500 laptop. Yet when we were cracking SSL, it was searching a 28-bit chunk of keyspace every hour or so merely using the idle cycles. In which case, if it's no harder to detect a correct decryption than SSL, and no slower to decrypt than RC4, I could crack your messages in about 4 hours by myself (of course, from what you've said, it almost certainly *is* harder than that, the question is *how much* harder). Incidentally, how do you intend to distribute these secret keys ? Do you have some kind of RSA layer on top, or do I just have to call everyone I want to send faxes to and ask for their key ? > The 9 digit key, when applied to analogue, the graphical encryption is What do you mean here ? What's analogue in this system ? You're running it on digital data in a digital computer, right ? > equivalent to a much longer key applied to alphanumeric encryption. Perhaps, but it would have to be at least 1000 times harder merely to make it as secure as RC4-40, which we've already shown to be insecure. > PrivaSoft is unique in being a one-stop product than can serve all types > of modern correspondence, including E-mail, fax and paper printouts. ^^^^^^ This seems to be a direct contradiction of what you said above, unless you plan to send email by creating a bitmap, encrypting the bitmap, and then sending that to the recipient. Some of us don't have T1 links to support that kind of mail... and it won't support, say, sending an executable file or C source code in that message and being able to use it at the other end. It's also hardly unique, as PGP can readily encrypt any kind of digital data, with much better security. Mark

1 0

Re: responce to graphic encryption replies
by Rev. Mark Grant 17 Dec '03

17 Dec '03

I said : > This message is in MIME format. The first part should be readable text, > while the remaining parts are likely unreadable without MIME-aware tools. AAaarrrgh ! > Urk.. not wanting to start up the "MIME is Evil, ASCII Forever !" thread > again, but it would help those of us who have to use MIME-supporting mail > programs if you didn't send messages as MIME attachments, pine is too > stupid to actually include the attachment in the reply... Thank you pine.. I guess it's time to add POP support to privtool so I can use a proper mailer... Mark

1 0

_Digital Cash_ info...
by pcw＠access.digex.net 17 Dec '03

17 Dec '03

As John Young noted the other day, the publisher is finally shipping my book called _Digital Cash_. If you're curious, you can see the table of contents from my home page: http://access.digex.net/~pcw/pcwpage.html You should be able to get the book at fine bookstores like Computer Literacy or through the publisher's 800 number (1-800-3131-APP). If you like, you can order the book directly from me at the list price of $34.95. Shipping is free. You can either snail mail me a check or get a First Virtual account. Let me know if you have any questions or comments. I would like to thank the many members of the cypherpunks mailing list who contributed to my knowledge in the subject. Really. Thanks. -Peter Wayner

1 0

Re: Don't Kill the Messenger--A New Slant on Remailers
by Rev. Mark Grant 17 Dec '03

17 Dec '03

On Thu, 19 Oct 1995, Timothy C. May wrote: > "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." I suspect that I could easily hack this into Mixmaster in a day or two, but wouldn't it open you to attacks where Anonymous Fed, say, sends terrorist kiddy-porn through your remailer and busts your ISP during those 60 days for possession ? I'm not sure if it would be better or worse than current setups from that point of view. I might do it anyway, and set it up to only forward PGP-encrypted messages, but I certainly wouldn't be able to keep messages for 60 days with only a MB or so to spare. Mark "Yes Judge, when we siezed their computer we found 300 MB of *kiddy porn* and plans for *terrorist attacks* [that we'd mailed to the in the last two weeks...]"

1 0

Re: 50 attacks on Netscape - please send the check
by Ray Cromwell 17 Dec '03

17 Dec '03

> > fc(a)all.net (Dr. Frederick B. Cohen) writes: > >50 Attacks: a.k.a. Why Not to Run Hot Java in your netscape (or other) browser: > > ... (drivel elided) > > This fellow seems to be systematically (if not deliberately) ignorant > about these things. I'm frequently seeing this same behavior by lots of people on this list and it's sad. There are people making claims about HotJava/Java that are obviously bogus if you even read the white paper, looked at the source code, or programmed a "Hello World" applet. The Java papers are an easy read. If you want to know about the implementation, read the source. At least criticize specifics about the implementation rather than speculating what they are and then proceeding to claim to have found a security hole in the implementation. I'm even more surprised when I see someone with a Phd acting like this. -Ray

2 1

Re: PGP interface for Mac--well...
by Steve Bryan 17 Dec '03

17 Dec '03

>Has anyone seen this yet? The only upload I've seen, on info-Mac, >unbinhexes into something called "My Preschool Demo," and that's pretty >much what it is. > >http://hyperarchive.lcs.mit.edu/HyperArchive/Archive/cmp/ > mac-pgp-control-10b1-as.hqx > Well I tried the next obvious place and it is actually there. Look at: /info-mac/app/edu/preschool-program-10-demo.hqx Voila, your pre-schooler is playing with MacPGP. Actually you're not quite home free yet. Right now I'm trying to use Anarchie to hunt down FaceSpan Extension v2.0.1. The specific URL given in the docs points to a rather unresponsive host.

1 0