December 2003 - cypherpunks-legacy

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

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

17 Dec '03

At 6:45 PM 10/20/95, Rev. Mark Grant wrote: >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. In the U.S. at least, the Electronic Communications Privacy Act (ECPA) says that e-mail should not be looked at by third parties to a communication. Yes, there are all sorts of wrinkles, such as whether an employer may look at employee e-mail, blah blah. But I suspect the ECPA adequately protects a mail deliverer against charges such as Mark describes. ("But under the ECPA I am not allowed to look at this e-mail, so how can I held be liable for it?" Not even under Stratton-Oakmont is the deliverer or holder of e-mail held liable for content or effects--the Prodigy case involved the fact that Prodigy was moderating/censoring speech in public forums, so, the judge averred, Prodigy could not claim it had no duty to moderate or censor the speech of defamers. Roughly, as IANAL.) >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. Drives are cheap. I just saw a 1.2 GB for $195 (internal, PC). I suspect that anyone sweating over having only a MB to spare shouldn't be running a remailer. (Not a slam against Mark, just a statement that there are certain minimal capabilities I'd expect to see, and not having free disk space is a serious problem.) In any case, by the time "General Delivery Remailers" would be spreading, disk space will be even cheaper. And a coupon- or stamp-based remailer could of course then buy disk space as needed. (If a 1000 MB drive costs $300 and is written off over 3 years, then the storage cost is $0.10 per megabyte-year. For the average text message of about 20 KB, the cost to store it a year is $0.002. The cost to store it for 60 days is 6 times less. Even if disk drives cost more than I've quoted, the cost is tiny, tiny, tiny. Connection costs are likely to dominate. Large files may be a different matter--the math is easy to do--but these are seldom the targets of remailers to unsuspecting parties. In any case, easy to "expire" unretrieved larger files faster.) --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."

1 0

[reformatted] how secure can privasoft be?
by anonymous＠freezone.remailer 17 Dec '03

17 Dec '03

heres a version with eighty character lines: ============================================================================ How Secure Can PrivaSoft Be? Introduction PrivaSoft is a communication security product, and the user is entitled to know how secure it is. This document addresses the question of cryptographic strength of PrivaSoft. Export license regulations In some advanced countries, cryptographic products are categorized as "munitions" and their use, sale or exportation is controlled by local licensing regulations. PrivaSoft has obtained an export license from the governments of Israel and the USA. Licenses in other countries are obtained in coordination with the local distributors. The typical policy is to limit the allowable cryptographic strength of commercial products to a level that is strong enough for commercial purposes. The basic intention of this regulation is to protect the state from abuse of too strong cryptographic products by terrorists and criminals. Some countries do not practice such law because it is viewed as a denial of freedom of expression. PrivaSoft willfully complies with these regulations as it is a commercial product, and it is not intended for national security applications with its current key length which is the maximum legally allowable for commercial users. 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. The engine is proprietary, designed according to the rules of modern cryptology to make the best use of the allowable key length. Like other dependable cryptographic engines, the structure of the encryption software can be disclosed without compromising the security of the user. However, the coding and specific parameters of the mechanism are considered a trade secret and will be disclosed for the purpose of cryptoanalytic validation when necessary and under an appropriate non-disclosure non- competition agreement. The use of default keys When secret keys or passwords are used by laymen, there is always a conflict between security and convenience: The user tends to use fixed, easily memorized keys again and again, while the cryptoanalyst only waits for an opportunity to see many messages encrypted by the same key. PrivaSoft, being a secure commercial product must live in peace with both - allow the user to use a repetitive, default key, and deny the cryptoanalyst the pleasure of having many messages encrypted by one key. This is done by using the pseudo- random "key extension" feature which is described in the PrivaSoft user's guide. The information contents a clear message If a cryptographic product is properly designed, then the almost only way to crack it is to try all possible keys. If the process is done by a computer, the "cracking"" software must be taught to tell the correct key from the wrong keys. This can only be done if there are some properties of the decrypted message that are known a - priori. With the PrivaSoft analogue graphical encryption, and with the naturally noisy fax images, a significant portion of the page must be reconstructed, and a significant amount of mathematical correlation must be calculated between neighboring areas of the image, before the cracking software can tell whether the candidate key is wrong. This makes the cracking process much slower than in alphanumeric encryption of the text in a natural language. The 9 digit key, when applied to analogue, the graphical encryption is equivalent to a much longer key applied to alphanumeric encryption. The cryptographically oriented user can make it very much harder by some smart pre-processing of the image prior to its encryption. A simple example: For a short message, increasing the font size of the text by a factor of 10 will significantly increase the time required for breaking the encryption. Customized versions of PrivaSoft PrivaSoft is unique in being a one-stop product than can serve all types of modern correspondence, including E-mail, fax and paper printouts. Special applications that need and can obtain a license to use non-commercial cryptographic engines can be accommodated by special versions of PrivaSoft. The cryptographic engine can be customer-furnished and customer integrated, however - since in some areas the integration of this product with certain cryptographic engines may be considered "munitions", each customized version of the product has to be licensed separately in accordance with the laws of the territory where it was created and used. ==========================================================================

3 2

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

17 Dec '03

On Fri, 20 Oct 1995, Timothy C. May wrote: > Drives are cheap. I just saw a 1.2 GB for $195 (internal, PC). I suspect > that anyone sweating over having only a MB to spare shouldn't be running a > remailer. The trouble is, I can't just add a 1.2 GB disk to my ISP and use it, I have to pay monthly for more space. In addition, it would be time-limited to three months or so in any case, as I'm going to be travelling and wouldn't be able to support it. > (Not a slam against Mark, just a statement that there are certain minimal > capabilities I'd expect to see, and not having free disk space is a serious > problem.) Yeah, I was mostly intending it to be a proof-of-concept, not really as an operational remailer at this point. If it was available as a patch for Mixmaster, say, then anyone who wanted to run such a remailer and had the disk space available, would be able to do so. BTW, how would the ECPA apply to, say, bouncing non-PGP messages ? From the sound if it, doing that would be worse from a legal standpoint than not doing it, as it would imply I was censoring the mailfeed in some fashion. Mark

1 0