December 2003 - cypherpunks-legacy

Re: Politics do not belong here
by Julietta 17 Dec '03

17 Dec '03

Jer- I'm sorry, but I feel so strongly about your message "Politics do not belong on this list" that I was compelled to reply... Where else should the poltical implications of encryption be discussed, if not amongst those who are most involved in its creation and proliferation? The political use and misuse of power is central to the issues regarding encryption, and these ramifications should be discussed as the technology is in its infancy. Encryption technology can be used as a tool to empower the individual, or it can be used as a means to lend a false security to the individual in his communications. If in fact the Clipper Chip with its easily obtainable (by government agencies) escrow keys is allowed to be implimented, we may in fact be assisting the government to effect a survelliance state of a maginitude never before seen in society. As American homes become host to "interactive" technologies, we need to realize the increased ability this brings for surveillance by both government and capitalistic enterprises. Encryption is one viable solution to re-instate the privacy equlibrium in the face of such a condition- this is where its power lies. Encryption, then, is not merely a mathematical tool, but also a sociological one; to discuss merely the technological and not the social and moral implications of this techology would be to not realize its full potential as a mediator to the coming state of "Big Brother is watching You". Politics, then, is not periferal but central to the discussion of encryption technology. Julie __________________________________________________________________________ Julie M. Albright Ph.D Student Department of Sociology University of Southern California albright(a)netcom.com

2 2

REMAIL: standardized remailer syntax
by nowhere＠bsu-cs.bsu.edu 17 Dec '03

17 Dec '03

Sameer writes: > Here's my suggestion.. > > Header pasting: > The '::' header pasting syntax should be available-- i.e. when >a message comes into a remailer with a body starting with '::' the >lines following until a blank line are pasted into the header. > > The '##' header pasting syntax-- when a remailer is sending >out a message, if the body begins with a '##' line then the lines >following that are pasted into the header of the outgoing message. > > Header commands: > "Anon-To","Request-Remailing-To": strips headers and sends the >message to the specified recipient. Both of my remailers (nowhere(a)bsu-cs.bsu.edu and remailer(a)chaos.bsu.edu) support all of the above as of 4/2/94. > "Encrypted: PGP": The message has a pgp block encrypted with >the remailer's key. The remailer will decrypt the pgp block before >acting furthur upon the message. Neither of my remailers supports encryption. The bsu-cs one has too small of a quota and I haven't compiled PGP for the chaos one yet. I will write more later, but basically what you need to know is this: 1. The bsu remailers no longer paste ANYTHING from a "::" header into the header of the outbound message. 2. They both support the "##" header pasting syntax now. The "##" block must come after the "::" block if both are being used or else the "::" block will be considered part of the body of the message. 3. They also support multiple recipients. You can place as many "Request-Remailing-To:" lines in the headers as you wish and it will individually address and send each one. 4. Full debug logging has been turned on until I can verify that both remailers are acting as they should. This form of logging includes a mirror of the message as it is received and a one-line message listing each recipient. 5. The C source is available via anonymous FTP at: chaos.bsu.edu:/pub/cypherpunks/remailer/chaels-remailer.tar.gz It should compile as long as you have getopt(). There is no fancy signal processing in this version. Note that there is nil documentation. This is not a release. Apparently my other posting got eaten somewhere between here and toad... Oh, well! Chael -- Chael Hall nowhere(a)bsu-cs.bsu.edu 00CCHALL(a)BSUVC.BSU.EDU nowhere(a)chaos.bsu.edu chall(a)bsu.edu

1 0

DEATH TO THE
by Hal 17 Dec '03

17 Dec '03

One thing worth noting about the burst of remailer messages is how much worse it could have been. Each message was sent to many remailers, with requests to send it on to many more. Potentially the message could be duplicated n-fold at each step, until horrendous numbers of messages were circulating through the remailer network and being sent to the other destinations. Luckily, this didn't happen, apparently because most remailer software does not support multiple recipients. But the lesson is that as people deploy new remailers and improve the software, "multiple recipients" should *not* be added as a feature, IMO. Doing that would make the network vulnerable to these kinds of geometric-growth attacks. It would be so easy to do it that people would probably be tempted to try just for kicks. So I think this feature should definately be left out of future remailer plans. Hal

1 0

REMAIL: standardized remailer syntax
by Hal 17 Dec '03

17 Dec '03

From: nowhere(a)bsu-cs.bsu.edu (Chael Hall) > Sameer writes: > > > Here's my suggestion.. > > > > Header pasting: > > The '::' header pasting syntax should be available-- i.e. when > >a message comes into a remailer with a body starting with '::' the > >lines following until a blank line are pasted into the header. > > > > The '##' header pasting syntax-- when a remailer is sending > >out a message, if the body begins with a '##' line then the lines > >following that are pasted into the header of the outgoing message. I like Sameer's goal of standardized syntax, but I have to admit that I find the :: and ## bit confusing, and hard to explain. The way Eric Hughes' original remailer worked was that the "remailer commands" were in the message header, up with Subject and In-Reply-To and such. However, many mailers won't let people put custom material there, so the "::" pasting token was invented to take the following lines and put them into the header before the remailer processed them. The effect was that you could put remailer commands after "::" and they would work. But there were also some situations in which the user might want to control message headers as they *leave* the remailer. For example, they might want to put a Reply-To to some anon pool so that they could receive reply messages. So Eric created the "##" pasting token for those. The remailers based on his scripts first look for "::" and add in any headers following it; then they process the message, looking for command lines in the header; then as they remail it they look for "##" and stick any following lines in the outgoing message header. This all makes sense but it makes for a complicated system. I think people would find it easier to understand an approach in which they put remailer commands at the top of their message, marked in some way to separate them from the rest of the message. "::" on a line by itself could indicate the beginning of a block of remailer commands, terminated by a blank line. Or, as an alternate syntax, each remailer command line could start with "::" followed by the text of the command. Both approaches have been used by different software on the net and they could be considered two different ways of expressing the same thing. This would get away from the add-to-header/process-header/add-to-header approach of the current Perl remailer scripts and use a simple one-step "process remailer commands" approach which I think would be simpler. You could still have all the functionality of the current approach (perhaps a paste-outgoing-header command could be used for the "##" functionality) in a package which is conceptually simpler (to me, at least). Another advantage of this approach is that you could make use of the order of the commands in the remailer block so that you could have finer control over what you are asking the remailer to do. > > Header commands: > > "Anon-To","Request-Remailing-To": strips headers and sends the > >message to the specified recipient. I would suggest abandoning one of "Anon-To" or "Request-Remailing-To", as they are redundant. I know above I suggested two redundant ways of specifying remailer commands; maybe that should be reduced to one, as well. > 1. The bsu remailers no longer paste ANYTHING from a "::" header > into the header of the outbound message. Many of the remailers pass Subject lines. I don't think they should. Chael's approach makes sense to me. The best thing is to have a way to set the subject as the message leaves the last remailer in the chain. (My "chain" program does this automatically.) > 3. They also support multiple recipients. You can place as many > "Request-Remailing-To:" lines in the headers as you wish and > it will individually address and send each one. I sent mail a few minutes ago (before seeing Chael's message) suggesting the danger of this in making it easy to create huge numbers of messages. > 4. Full debug logging has been turned on until I can verify that > both remailers are acting as they should. This form of logging > includes a mirror of the message as it is received and a > one-line message listing each recipient. We have had a lot of talk about logging. My feeling is that one should get security in using the remailer network by going through a number of machines in widely different regions. It should not, as was suggested here some time ago, be a matter of trusting any given remailer operator. Privacy is not a gift being provided by remailer operators to their users. It is still some- thing that the users must provide for themselves. The remailers are just a tool to help achieve that. Thanks to Chael for re-kindling this discussion. Hal

4 3

Re: tmp@netcom.com
by cfrye＠mason1.gmu.edu 17 Dec '03

17 Dec '03

I'm not sure what the time-delay features for the "nowhere" anonymous remailer ler are, but the messages that arrived last night all came through within a few minutes. Interestingly, the messages were sent at around 3:00 am, corsimilar to LD's posting patterns from before. I deleted the most recent postings, but if someone could send them to me, I'd like to run them through a grammar checker and compare the results to the message base I developed before. Curt

1 0

MAIL: prank
by Karl Lui Barrus 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >The Zimmerman prank---I'm sure not funny for him---hardens my line >further against anonymity online. At its best, as here, it is an >unholy nuisance. Why? If you think about it, the prank doesn't demonstrate why anonymity is bad - it could have been off with ordinary mail forgery. What is does demonstrate is the need for digital signatures and authentication. In the future you would just ignore an announcement of this sort if it doesn't have a valid digital signature. Karl L. Barrus klbarrus(a)owlnet.rice.edu -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLZ9wY4OA7OpLWtYzAQHV1gP+IXt0zpdjh+97V9I6SASc29dWW2JZR5QV kI7EJyk5e6/gacULgr+nkGz4KAPIImQ6M4+QNDjplxnRwrwrljSMPewqZLpd1REF kZWGC8rnKOxFlwuXamMCF8+0+3+XrGqCxD6H2WuOGVZ82nUc5fHO25nNDes0B2tp /nf9TI8+zYY= =kyRX -----END PGP SIGNATURE-----

1 0

Positive uses for PGP
by Philip Zimmermann 17 Dec '03

17 Dec '03

To all PGP users: We've all heard arguments raised by the law enforcement and intelligence communities that PGP and other encryption technology can be used by criminals to hide their activities. This line of reasoning is being used to justify Government key escrow systems like Clipper, and to clamp down on encryption technology like PGP. It would be helpful to come up with real-world examples of how PGP has been used for good constructive purposes. Journalists sometimes ask me for examples of positive uses for PGP. But most of my fan mail from PGP users do not tell me what they are using it for. If you have any stories about how PGP is used for good purposes, I'd like to see them. Not just disaffected paranoid libertarians embracing it for the theoretical benefits for a free society. We need to be able to cite examples of real people using PGP for good ends. Human rights activists using it are a great example. But it doesn't have to be in the Nobel-Prize winning catagory of human endeavor (although that would be nice). It could just be any positive upbeat application that normal people can relate to in a positive way, so I can tell reporters about it. I'd like to hear (actually, see some email) from real people who are actually using PGP for good things. It could be for helping others, like protecting HIV patient records, or keeping psychological counseling records. Or conducting good wholesome business that must remain confidential. Or lawyers using it to maintain confidential records and communications with their clients. Or, it could be for your own personal life, but for wholesome upbeat uses, like sending love letters (you don't have to supply any actual love letters), or keeping your diary. For those that don't know what PGP is: Pretty Good Privacy (PGP) is a free software program that encrypts email using public key cryptography, allowing you to communicate securely with people you've never met, without the prior exchange of keys over secure channels. PGP has become the worldwide de facto standard for email encryption. It's available on many Internet FTP sites and BBS systems. Please send me some email (to prz(a)acm.org) with the subject line "Positive uses for PGP", so that I can quickly sort it out from the rest of my email. If it's a really good story, I may want to use it, so let me know if I can and if I can give reporters the information. You might not get a reply-- it depends on how much mail I get or how busy I am when you send it. There is no prize for the best story, but for what it's worth, I'll sign the public key of the person who submits the best story by Monday, April 11th. But keep sending stories after that date if you've got them. This notice can be copied and reposted on any newsgroup or mailing list that is likely to be familiar with PGP. Philip Zimmermann prz(a)acm.org

5 5

DEATH TO THE
by rjc＠gnu.ai.mit.edu 17 Dec '03

17 Dec '03

re: Hal's suggestion I don't think that banning multiple recipients solves the whole problem which is the spamming of the remailer network by cybervandals like Detweiler. What needs to be done is to create some system that "charges" remailer requests to the sender which then limits the size or frequency of their messages based on their ability to pay. For a play money system, the issue is, how do you distribute the play money accounts without letting spammers open up as many accounts as they like? (e.g. if Detweiler spends his one account dry with his cyberterrorism, how do we prevent him from opening up an unlimited number of accounts without trying to attach accounts to a user's e-mail address?) By making remailers charge users, and even other remailers on the network, we can also prevent rogue remailers from allowing Detweiler attacks through the network (since they'd have to pay for his traffic) Here's a nutty idea I had one night which would accomplish these goals and also encourage more people to run remailers: o each remailer upon being setup distributes a large but finite amount of digicash certificates. These certificates are one use only. The initial distribution and price system can be altered to tailor the usage of the remailer to the owner's wishes. o after the initial distribution, the remailer distributes a somewhat smaller amount of digicash each renewal period (probably once a week) This smaller amount is sufficient for casual use, but not abuse o if you want more than what a remailer is willing to give you, you must trade service for it. That is, you must set up your own remailer and issue some cash to the other remailer which can be redeemed for chaining service. Example: Bob was unsatisified with his $10 of Ann's remailer coupons, so he set up his own remailer and issued $100 worth of service to Ann, in return, she gave him $50 of service for her remailer. (obviously, her remailer is more popular and is more in demand so his is only worth 1/2 of hers. Ann could use bob's coupons to either chain requests through him, or she could sell them off to other remailer operators.) The hard part is making sure that Bob doesn't cheat, offer to run a remailer, issue $X worth of credit to Ann, and then just file her remail requests to /dev/null I'm hopeful that a "consumer reports" like organization will pop up which periodically tests remailers to make sure they aren't cheating. (besides, the remailer network itself should do such testing with fake traffic) Call it "the free market of remailers" Other issues: How to distribute coupons/stamps/dollars? First come first serve? Popularity/Reputation? Reputation market? We want to prevent people from collecting digicash certificates multiple times during distributions, but at the same time, we don't want to use their real e-mail address. So in a system where users can create as many identities as they wish, how can we achieve a fair distribution? The only thing I can think of is to distribute cash to users based on their reputation or trust level. If a Detweiler is found abusing remailers, operators simply stop giving him cash for their remailers. Remailers which sanction Detweilers end up paying for them in the long run. (either because he runs up the costs for the remailer to use other remailers on the network, or because the operator gets too many complaints from systems which it directly delivered Detweiler mail to) Anyway, limiting multiple recipients will stop geometric growth, but it won't prevent Detweiler from hacking up a script to send a hundred thousand remail requests posting to every newsgroup and mailing list out there. Remailers would also have to limit the amount of remailer requests allowed per day, but this would still allow Detweiler to spam up the system by preventing anyone else from using it (by running out the global quota) Some sort of authentication is needly, IMHO. -Ray -- Ray Cromwell | Engineering is the implementation of science; -- -- rjc(a)gnu.ai.mit.edu | politics is the implementation of faith. --

1 0

PGP remailers
by Mikolaj Habryn 17 Dec '03

17 Dec '03

Are there any remailers which provide you with an anonymous account to which other people may send messages, which are then forwarded to you in a PGP-encrypted form? MJH * * Mikolaj J. Habryn dichro(a)tartarus.uwa.edu.au * "Life begins at '040." PGP Public key available by finger * "Spaghetti code means job security!"

2 1

Code Obfuscation
by garet.jax＠nitelog.com 17 Dec '03

17 Dec '03

>ÿTimothy C. May adds: >Hal Finney writes: >> The other issue, which I know less about, is the possibility of cryptograph- >> ically strong obfuscated code. Mike Duvos first mentioned this. You could >> have an algorithm running on your own computer and have it be impossible to >> determine what it is doing, or (presumably) to effectively alter the >internals >> of the algorithm. >.....stuff detiled.. >> discussing here (self-decrypting code and such tricks), but rather some >> mathematically strong transformation has been done on the structure of the >> code to hide it in a cryptographically strong way. >> >Brad Cox, of Objective-C notoriety, and now at George Mason >University, has also been interested in this area of "complexifying" >code so that reverse engineering is difficult or impossible. Okay if you want to obfuscate your code on a much more secure level albeit with some execution penalty, build public key encryption into the CPU. One would simply compile the program and encrypt it using the public key of the chipset (680xx, 80x86, &c), then the CPU would decrypt and execute the code on the fly using its private key.

1 0

Cyberspace, Crypto Anarchy, and Pushing Limits
by tcmay＠netcom.com 17 Dec '03

17 Dec '03

Cyberspace, Crypto Anarchy, and Pushing Limits This messages touches on two topics of recent interest (to some) here: 1. Setting up payment systems for message transmission, to handle the issues of "mailbombing" and "flooding" in a more natural way (locality of reference, user of a service pays, avoidance of the "Morris Worm" explosion effects which could've happened with Detweiler bombed us, as Hal noted). 2. The general issue of "Cyberspace." This lies at the root of some recent disagreements here, and is worthy of more discussion. Crypto will make this a very real cusp issue in the next several years. Why debate it now? What could possibly come out of such a debate? It happens that I'm reading a wonderful new book by Kip Thorne, entitled "Black Holes and Space Warps." This is widely available in bookstores, in hardback only at this time. ($30, but it's a whopping big book, and I got it at Barnes and Noble for $24. Speaking of Barnes and Noble, the Santa Clara store is selling Li and Vitanyi's "Intro. to Kolmogorov Complexity" book for $44, before the 20% hardback discount, which may be a mispricingm, as I paid $60 for mine. Check it out if you're interested....I think there were two copies.) Thorne has spent 30 years studying gravitational collapse and black holes, and was a coauthor of the famed 1973 book on "Gravitation," which I got to use in a Xeroxed form for my general relativity class in 1973. The point? Thorne describes his involvement with Carl Sagan in working out the physics of time travel via wormholes. Thorne had an epiphany: however unlikely the engineering or financing of something is, there is something valuable to be gained in examining the absolute limits of what is possible without regard for engineering practicalities. Thus, he and his students looked into the implications of an extremely advanced civilization able to somehow hold open the mouth of a wormhole. The conclusions are fascinating and led to a new line of thinking about the structure of space-time. Pushing limits and seeing "ideal" behavior is invigorating. The connection to crypto is this: Perhaps we should be thinking more about the implicaitons and effects of strong crypto, digital money, ideal remailers, etc., assuming that certain practical problems that bedevil us today are, or soon will be, solved. To some extent we already do this, as when we discuss Chaum's ideal mixes in the same way engineer's discuss ideal op amps--a useful abstraction of behavior in the limit that lesser, real world implementations can then be contrasted with. And of course many of us have found Vernor Vinge's "True Names" to be an excellent (and quickly readable) treatment of how things could work in a world of fast, cheap, and secure communication. Other writers have seen things differently (e.g., "Shockwave Rider," "1984," "Snow Crash"). Here, to cut to the chase, are some brief statements of what I see as the "behavior in the limits." I won't elaborate on them right now. * "Pay as you go" is the natural way to handle most economic transactions. There are exceptions, of course, such as insurance, contracts for future perfomance, etc., but for the most part money is used to mediate immediate exchanges. For a timely example, why can your enemies not "junk mail bomb" you with truly large (tons) of junk mail? Junk mail, as we call it, is in relatively small volumes (at most a mailbox full, except for celebrities perhaps) because of one simple thing: someone has to pay for the delivery! There is no possibility of a "free" way to "Make 19 copies of this ton of garbabe and mail them to your enemies." That there is with software--the remailer bombing by Detweiler, the 1988 Morris Worm, the "Dave Rhodes" chain letters--is due to some flaws in the current Net model: - costs of message trasnmission are not directly borne by senders (encourage overuse by some of scarce resources, a la the "tragedy of the commons'). - sites and remailers will respond to "instructions" to send the message on, to make copies of it, etc. * I thus consider it imperative that we develop as quickly as we can the following: - payment systems for message transmission (I've argued for "digital postage" as a first and comparatively easy application of digital money, others have as well, and Ray Cromwell just today issued his own proposal....time we get going on this. And lest you think I'm calling for altruism here, I think some fortunes will be made in this area.) - anonymous or identity-obscuring protocols, a la Chaum. - a general move away from "commons"-oriented systems, which breed the notions of "fair access" and such. If the "problem" is that poor people cannot--it is alleged--afford a $17 a month Net connection (what Netcom charges, in about 25 cities and growing), then my solution would be to simply _subsidize_ their bill. (I'm not advocating this, nor do I think it wise to subsidize anyone's phone, Net, or dinner bills, but better this than "nationalizing" networks and thus creating more confusion and less efficiency for all.) * Connectivity will be altered dramatically, The "distance" in cyberspace is already uncorrelated to physical distance. (Hardly surprising, as this was apparent with the telephone. But a useful way of looking at cyberspace, as being a space of radically altered connectivities and distances.) * Local access to service, the phone or cable lines that reach the home or office, is a potential bottleneck. But once a connection is made to a local node where multiple competitors exist (that is, once beyond the local government-granted monopoly), the possibility of "censorship" decreases rapidly, for several reasons. - thus, push for "encrypted access" lines from a terminal node (home, office) to a point with unlimited connectivity. - this is the situation I now have with my PacBell line and Netcom: PacBell doesn't "care" what I use the local line for, and once outside, I can dial a less-censorious Netcom rather than a Big Brotherish AOL or Prodigy. * Cyberspace is infinitely colonizable. No limits to growth. (Assumption: realization of cyberspace is on various machines and networks, which are not free, nor infinite. But the "no limits" comes from ease with which those near a "boundary" can simply push out that boundary with more CPU resource, more networks, etc.). * Crypto means access to "regions" can be controlled by "owners": - "my house, my rules" enforced locally, without central State authority - esseentially unbreakable security (in crypto sense) * By the way, strong crypto is the "building material" of cyberspace...the mortar, the bricks, the support beams, the walls. Nothing else can provide the "permanence"...without crypto, the walls are subject to collapse at the first touch by a malicious person or agency. With crypto, not even a 100 megaton H-bomb can breach the walls. (If you think I'm exaggerating, do some calculations on the energy to break a 1000-decimal-digit modulus.) * No "zoning laws" will be needed, or possible, in cyberspace. (Neil Stephenson's "Snow Crash," while a wonderful and thought-provoking read, got it wrong here: cyberspace is too extensible and locally controllable.) * Physical location of cyberspace locations will be increasingly hard to pin down. A vast "labyrinth of rooms and corridors" might be physically instantiated on a computer in Malaysia, while a "virtual gambling hall" is being run via cryptographic cutouts (remailers) from someone's bedroom in Provo, Utah. * The talk about "access rules" is thus shown to be meaningless, unless the governments crack down on networks, crypto, and private systems in a way far beyond anything now being talked about. This is the "crypto anarchy" I have been writing about since 1988. Cyberspace will turn out to be a far vaster frontier than _anything_ we have seen so far. With "only" 10^70 or so particles in the entire universe, there's vastly more "space" (address space, key space, etc.) in even a relatively small set of digits. Cyberspace is mathematical space, and its spaciousness is truly unlimited. And we'll be moving our trade, our entertainment, and much of our lives into cyberspace a whole lot faster than we'll be slowly moving into low Earth orbit and beyond. In fact, I consider that I'm already half-way in. In a few years, with Mosaic-like one-touch connectivity, with a plethora of network choices, with secure remailers and similar tools to anonymize my transactions, I'll be so far in there'll be turning back. Enough for these remarks rigth now. I think it makes sense to take a slightly longer-range view of the inevitable trends, to see where we're going, to see what issues need more work. I hope some of you agree with me. --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."

3 2

Hi... :)
by lile＠netcom.com 17 Dec '03

17 Dec '03

I would like to join this alias/list. Please direct mee to the list server or wjhoever I need to talk to about getting added. thanks, -lile ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lile Elam | "Remember... No matter where you go, there you are." lile(a)netcom.com | Un*x Admin / Artist | Buckaroo Banzai ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Re: Web of Trust?
by norm＠netcom.com 17 Dec '03

17 Dec '03

At 9:17 3/30/94 -0800, Hal wrote: ... >In other words, if I want to communicate with joe(a)abc.com, I can only do so >if one of the signators of his key is a person I know. If not, I have no way >of judging the validity of his key. > >This belies simple interpretations of the "web of trust". I may have signed >A's key, A has signed B's, B has signed C's, C has signed D's, and D has signed >Joe's, but this is of no value unless I know D. Only then can I trust Joe's >key. Ideally, perhaps in cyberspace, one's public key is spread along with X's reputation, i.e. thru the same channels. When a reputation for X reaches you so does X's public key. You say that you want Henry Kissinger's public key. I respond that by whatever means you know that there exists such a person, you will (in cyberspace) already know his public key. The logical limit of this idea is that the public key becomes the name and the key authentication issue dissolves into the mist. We trust reputations because they reach us thru diverse paths. Public keys arriving thru diverse paths should likewise carry extra weight. As crypto becomes more common reputations will eventually belong more to public keys than to names. The question will then be not "What is Henry's public key?" but "What is the name of the person who knows the secret key that corresponds to this public key?". I suppose that Detwiler feared being unable to answer that question in specific cases. I don't. In the meantime, redundant webs that parallel the normal information webs thru which reputations propagate should provide public keys at least as reliable as the reputations themselves. One particular case is of interest. If you contract with me to process some of your secrets, I will agree not to divulge those secrets except under the protection of a one of a set of public keys that you give me. In such a case the web of trust model can be usefully employed and is not intrinsically limited in the number of levels.

1 0

VISA's digital cash
by Pat Farrell 17 Dec '03

17 Dec '03

Today's (April 3) Washington Post business section has an article on a consortium of VISA and banks working on a digital cash card. Did I sleep thru the messages, or has the list been scooped? Basic story is that the card is a smartcard, designed to be reused, and suitable for small quantities. Nothing in the article about what would prevent it from storing large amounts. No serious technical discussion either, but I infer that it is an online cash card. Pat Pat Farrell Grad Student pfarrell(a)gmu.edu Department of Computer Science George Mason University, Fairfax, VA Public key availble via finger #include <standard.disclaimer>

1 0

REMAIL: standardized remailer syntax
by Ian Smith 17 Dec '03

17 Dec '03

In reply to messsage <9404031518.AA06509(a)ah.com> of Sun, 3 Apr 94 08:18:37 -0700 regarding REMAIL: standardized remailer syntax Ok, I've been following this discussion with keen interest as someone who writes mail software and has written a "fairly clean" GUI interface to anonymous remailers, both encrypted and non-encrypted (although the differences to the user are not visible). All this talk of a standard syntax is great, but let me inject some notes from someone in the trenches doing this stuff: 1) Mail software authors would MUCH rather have the commands be in the header lines. If you are writing your own software, modifying header lines is easy. I understand that some people can't modify their headers due to their mail software, but ultimately this will be a chicken and egg problem if the simple header lines are proposed. If you make it easy for the mail software implementor, more software will be available with the capability (or at least patches to existing software). As for deleting subject lines, I think this reasonable to keep people doing potentially dumb things, but someway must be provided to allow people (and mailers) who understand what is going on to retain or insert new subject (header) lines. For example, my software presents a default subject line of "NONE" on anoymous mail (which I think is an ok substitute for ripping off the subject line), but if the user goes to the trouble of actually typing in a subject line it should be preserved in the resulting message. 2) MIME is a must. I just two days ago had my first user complaint that his MIME mail was "damaged" by the remailer. My user interface doesn't show people the details of MIME and he "just expected it to work". I've been considering hacks to use the :: to get the "Mime-Version" header back into the mail, but I have no idea what other shenanigans are going on with the remailer, and MIME parsers tend to be picky. An especially important area is the use of line feeds and carriage returns. I don't know how careful current remailers are to preserve the original message text at the line level, but that's going to be a big deal. Aside: I've been trying to figure out how to get a MIME message part to be a PGP signature in some reasonable way. It *should* work if the PGP sig is removed completely and the rest of the message stays intact. You should be able to concatenate them at the end and then use PGP to check it. Has anyone actually gotten this to work yet? PGP encrypted messages are a lot easier as they are self contained and fit nicely into the MIME paradigm. Also, does anyone out there know what the IANA registered types are for PGP? I heard that they were already registered, but I don't know the types. 3) I support Sameer's efforts as well as others for a standard syntax for all the commands of a remailer, but some of sort of simple syntax(es) are needed to allow users to "get their feet wet." My mailer allows you to just send anonymous mail (via hfinney, good job hal) without understanding/using PGP (or even knowing what it is). If you want to use the PGPed version of the remailers, I require (obviously) that you have my PGP interface set up. I went to a lot of trouble to create as simple a drag-n-drop interface to PGP as I could, but some people just don't want to learn it, so I had to "deal with it." This also allows people an "upgrade path" as they get more confident and interested in the use of remailers. I would very much like to present a GUI interface to a lot of other capabilities of remailers (such as chaining, the use of encrypted reply-to blocks, etc), but these are hard to implement in "clean" ways. Part of my philosophy in this is that sending anonymous mail MUST be just as easy as sending normal mail... it should look the same and work (basically) the same from the users point of view. Any new remailer syntax should consider how the mail program can implement/use the syntax is reasonable ways w.r.t. to a user who probably doesn't care about "the how" but just wants it to work. After saying all this, let me make some suggestions to make life easier for mail program authors: 1) All commands must be available without modifying the message body. This is especially important with respect to MIME mail messages whose body parts must be particularly formatted. I support E. Hughes suggestion about what the header lines should be for anon-remail, anon-post, etc. although this is not a big issue as long as there is a standard way to acess functionality. 2) When automated programs respond to mail messages, they should be formatted in ways to make it easy (preferably trivial) for programs to detect the message and its contents. Good example of this type of thing: Sameer's double blind server. It sends various kinds of control messages back to you.... it should be easy for a mail program author to detect these and take automated actions. Another example: Matt Ghio's anonymous ID allocator. Ideally these should be MIME messages with particular parts that indicate the results. I can assist people who would like to create MIME formats for their control messages. 3) Schemes and syntaxes which require multiple steps (stages) of user control should be avoided when possible (I realize this is not always possible). If a user can hit "compose" and type a mail message and then hit "send" to mail it, a very similar sequence should be preserved when using remailers. From a user interface point of view, forcing the user into some "sequenced steps" is irritating, especially in a GUI which has a very "unsequenced" way of doing things. hope this helps the discussion, ian --------------------------------------------------------------------------- "How soon is now?" ian smith, multimedia computing group, georgia tech, iansmith(a)cc.gatech.edu

1 0

Applied Cryptography Errata - Version 1.5.7
by schneier＠chinet.com 17 Dec '03

17 Dec '03

APPLIED CRYPTOGRAPHY ERRATA Version 1.5.7 - April 2, 1994 This errata includes all errors I have found in the book, including minor spelling and grammatical errors. Please distribute this errata sheet to anyone else who owns a copy of the book. Page xvii: Third paragraph, first line: "Part IV" should be "Part III". Page 1: First paragraph, fourth line: "receiver cannot intercept" should be "intermediary cannot intercept". Page 6: Sixth and seventh lines: "against symmetric" should be "against a symmetric". Page 8: Second paragraph, first line: "q code" should be "a code". Page 10: Second paragraph, fifth line: Reference "[744]" should be "[774]". Page 11: Second paragraph: "The rotations of the rotors are a Caesar Cipher" should be "Each rotor is an arbitrary permutation of the alphabet". Page 13: Third paragraph: Delete parenthetical remark. Fifth paragraph, first line: "Shift the key" should be "shift the ciphertext". Page 15: Section 1.3, first line: "Throughout the book use" should be "Throughout the book I use". Page 25: "Attacks Against Protocols," first paragraph: "the protocol iself" should be "the protocol itself". Page 27: "One-Way Functions," fourth paragraph: "For example, x^2" should be "For example, in a finite field x^2." Page 28: Third paragraph, third and fourth sentences should be "How to put mail in a mailbox is public knowledge. How to open the mailbox is not public knowledge." Page 30: Fourth line: "symmetric cryptosystems: by distributing the key" should be "symmetric cryptosystems: distributing the key". Page 30: "Attacks Against Public Key Cryptography," second paragraph: "The database also has to be protected from access by anyone" should be "The database also has to be protected from write access by anyone". Also: "substitute a key of his choosing for Alice's" should be "substitute a key of his own choosing for Bob's". Page 30: Last line: "substitute that key for his own public key" should be "substitute his own key for that public key". Page 32: Ninth line: Delete the word "encrypted". Page 34" "Signing Documents with..." First sentence: "too inefficient to encrypt long documents" should be "too inefficient to sign long documents". Page 36: Second line: "document encrypted with" should be "document signed with". "Multiple Signatures," step (4): "Alice or Bob sends" should be "Alice sends". Page 38: Fifth paragraph: "V_X = E_X and that S_X = D_X" should be "V_X = E_X and S_X = D_X". Page 40: Third line: "computer can exist" should be "computer can be". Second paragraph: Delete "should be runs of zeros and the other half should be runs of ones; half the runs". Page 44: Ninth line: "for Alice's" should be "for Bob's". Page 50: First step (3): "With Alice's public key" should be "with "Alice's" public key." Page 51: Step 5: "with what he received from Bob" should be "with what he received from Alice". Page 55: First step (2): At the end of the step, add: "He sends both encrypted messages to Alice." Page 58: Last line: "Alice, Bob, and Carol" should be "Alice, Bob, Carol, and Dave". Page 59: First line: "Alice, Bob, and Carol" should be "Alice, Bob, Carol, and Dave". Page 69: Last line: "tried to recover her private key" should be "tries to recover Alice's private key". Page 73: "Bit Commitment Using One-Way Functions," last paragraph: Second and third sentences should be "Alice cannot cheat and find another message (R_1,R_2',b'), such that H(R_1,R_2',b') = H(R_1,R_2,b). If Alice didn't send Bob R_1, then she could change the value of both R_1 and R_2 and then the value of the bit." Page 77: "Flipping Coins into a Well," first line: "neither party learns the result" should be "Alice and Bob don't learn the result". Third line: parenthetical remark should be: "Alice in all three protocols". Page 78: Step (1): "Alice, Bob, and Carol all generate" should be "Alice, Bob, and Carol each generate". Page 80: Second paragraph, second sentence. It should read: "A general n-player poker protocol that eliminates the problem of information leakage was developed in [228]." Page 90: Last paragraph: "step (3)" should be "step (4)". Page 91: Second line: "step (3)" should be "step (4)". Page 93: "Blind Signatures," first line: "An essential in all" should be "An essential feature of all". Page 98: First paragraph after protocol, fourth line: "to determine the DES key with the other encrypted message" should be "to determine the DES key that the other encrypted message was encrypted in." Page 115: "Protocol #2," third paragraph: "together determine if f(a,b)" should be "together determine f(a,b)". Page 121: Second paragraph: Delete the colon in the third line. Page 131: Fifth paragraph: "each capable of checking 265 million keys" should be "each capable of checking 256 million keys". Page 133: Table 7.2: Third number in third column, "1.2308" should be "0.2308". Page 134: Table 7.3: "1027" should be "10^27". Page 139: Indented paragraph: "could break the system" should be "could break the system within one year". Page 141: "Reduced Keyspaces," last sentence: "don't expect your keys to stand up" should be "don't expect short keys to stand up". Page 148: Eighth line: "2^24" should be "2^32". Page 156: Second paragraph: "blocks 5 through 10" should be "blocks 5 through 12". Page 157: Figure 8.2: "IO" should be "IV". Page 159: Figure 8.3: "IO" should be "IV". Page 161: Figure 8.5: "Decrypt" should be "Encrypt". Page 162: Figure 8.6: "Encipherment" diagram: Input should be "p_i" instead of "b_i", and output should be "c_i" instead of "p_i". "Decipherment" diagram: "Decrypt" should be "Encrypt". Page 164: Figure 8.7: "IO" should be "IV". Page 165: Last equation: There should be a "(P)" at the end of that equation. Page 167: Second paragraph, last line: "2^(2n-4)" should be "2^(2n-14)". Page 168: Figure 8.8: This figure is wrong. The encryption blocks in the second row should be off-centered from the encryption blocks in the first and third row by half a block length. The pads are half a block length. Page 174: Middle of page: Equations should be: k_2 = c'_2 XOR p', and then p_2 = c_2 XOR k_2 k_3 = c'_3 XOR p_2, and then p_3 = c_3 XOR k_3 k_4 = c'_4 XOR p_3, and then p_4 = c_4 XOR k_4 Page 175: Last paragraph, second line: "acting as the output function" should be "acting as the next-state function". Page 177: Diffie's quote, second to last line: "proposal to built" should be "proposal to build". Page 178: Figure 8.20: In "Node 2", the subscripts should be "D_2" and "E_3". Page 190: Fourth paragraph, last line: "to determine M" should be "to determine P". Page 191: First paragraph: "3.5" should be "6.8" in fourth line. "0.56" should be "0.15". "EBCDIC (Extended Binary-Coded Decimal Interchange Code)" should be "BAUDOT". "0.30" should be "0.76". "0.70" should be "0.24". Page 193: Second sentence: "Unicity distance guarantees insecurity if it's too small, but does guarantee security if it's high" should be "Unicity distance guarantees insecurity if it's too small, but does not guarantee security if it's high." Page 197: Third paragraph, fifth sentence: "Thus SATISFIABILITY is the hardest problem in NP" should be "Thus, there is no problem harder than SATISFIABILITY in NP". Page 198: Fourth paragraph from bottom, second sentence: "If a and b are positive and a is less than n, you can think of a as the remainder of b when divided by n" should be "If a and b are positive and b is less than n, you can think of b as the remainder of a when divided by n". Page 199: Middle of the page: In the sentence "Calculating the power of a number modulo a number", a should not be italicized. Page 201: First line of code: Remove "assuming x and y are > 0". Page 202: Middle of the page: In the sentence "Now, how do you go about finding the inverse of a modulo n?" "a" should be italicized. Page 206: Third line from bottom: "L(a,p) = -1 if a is a nonresidue mod p" should be "L(a,p) = -1 if a is a quadratic nonresidue mod p". Page 207: "Jacobi Symbol," formula: Variable "h" should be "a". Also, J(0,n) = 0. Page 209: Fourth paragraph: "If that value does not equal q" should be "If that value does not equal 1". Page 214: Last line: "n" should be "p". Lines 29, 30, and 31: "r" should be "a", and "gcd(p,r)" should be gcd(a,p)". Page 215: Lehman test, step 5: All three "(n-1)/2" should be exponents. Page 217: There should be an open parenthesis in front of the second "ln" in both exponents. Sixth paragraph: "Guassian" should be "Gaussian". Page 222: "Validation and Certification of DES Equipment," first line: "As part of the standard, the DES NIST" should be "As part of DES, NIST". Page 223: Second to last paragraph, last line. Reference "[472]" should be "[473]". Page 225: Figure 10.2: L_i is taken from R_(i-1) before the expansion permutation, not after. And "L_(i)-1" should be "L_(i-1)". Page 226: Third sentence: "bit 1 to bit 58, bit 2 to bit 50, bit 3 to bit 42, etc." should be "bit 58 to bit 1, bit 50 to bit 2, bit 42 to bit 3, etc." Page 227: Fourth line from bottom: "output positions that correspond" should be "output positions correspond". Page 228: Fourth paragraph, last line: "0 to 16" should be 0 to 15". Page 228: Fifth paragraph should read: "For example, assume that the input to the sixth S-box (that is, bits 31 through 36 of the XOR function) are 110010. The first and last bits combine to form 10, which corresponds to row 2 of the sixth S-box. The middle four bits combine to form 1001, which corresponds to column 9 of the same S-box. The entry under row 2, column 9 of S-box 6 is 0. (Remember, we count rows and columns from 0, and not from 1.) The value 0000 is substituted for 110010. Page 230: Fifth sentence: "bit 4 moves to bit 21, while bit 23 moves to bit 4" should be "bit 21 moves to bit 4, while bit 4 moves to bit 31". Second to last line: delete "The key shift is a right shift". Page 231: Table 10.9, sixth line: "80286" should be "80386". Page 233: The second two weak keys should be: 1F1F 1F1F 0E0E 0E0E 00000000 FFFFFFFF E0E0 E0E0 F1F1 F1F1 FFFFFFFF 00000000 Page 238: Next to last line before "Additional Results": "NSA's" should be "IBM's". Page 238: "Differential Cryptanalysis," third paragraph: "(1/16)^2" should be "(14/64)^2". Page 239: Figure 10.4: "14/16" should be "14/64". Page 242: Table 10.14: In "XORs by additions" line, "2^39,2^3" should be "2^39,2^31". In "Random" line, "2^21" should be"2^18- 2^20". In "Random permutations" line, "2^44-2^48" should be"2^33-2^41". Page 245: Line 11" "8 bits is" should be "8 bits was". Page 247: Section heading, "Cryptanalysis of the Madryga" should be "Cryptanalysis of Madryga". Page 250: The two functions should be: S_0(a,b) = rotate left 2 bits ((a+b) mod 256) S_1(a,b) = rotate left 2 bits ((a+b+1) mod 256) Note the difference in parentheses. Page 250: Figure 11.4: Note that a is broken up into four 8-bit substrings, a_0, a_1, a_2, and a_3. Page 251: Figure 11.6: The definitions for S_0 and S_1 are incorrect ("Y = S_0" and "Y = S_1"). See corrections from previous page. Also, "S1" should be "S_1". Page 254: "REDOC III," second sentence: "64-bit" should be "80- bit". "Security of REDOC III," second sentence: Delete clause after comma: "even though it looks fairly weak." Page 262: Figure 11.9: There is a line missing. It should run from the symbol where Z_5 is multiplied with the intermediate result to the addition symbol directly to the right. Page 263: Table 11.1: The decryption key sub-blocks that are Z_n^(m)-1 should be Z_n^((m)-1). Also, the second and third column of decryption key sub-blocks in rounds 2 through 8 should be switched. Page 264: First line: "107.8 mm on a side" shouldbe "107.8 square mm". Page 265: Figure 11.10: There is a line missing. It should run from the symbol where Z_5 is multiplied with the intermediate result to the addition symbol directly to the right. Pages 266-7: Since the publication of this book, MMB has been broken. Do not use this algorithm. Page 267: Sixth line from bottom: Reference should be "[256]". Page 269: "Skipjack." First paragraph. Reference should be "[654]". Page 270: "Karn." Third paragraph. Last sentence: "append C_r to C to produce" should be "append C_r to C_l to produce". Page 271: Middle of the page: "(for example, MD2, MD5, Snefru" should be "(for example, MD2, MD4, Snefru". Page 272: Second to last line: "But it is be analyzed" should be "but it is being analyzed". Page 275: Second to last paragraph: "Using 1028 bits" should be "using 1024 bits". Page 277: First lines: The correct street address is "310 N Mary Avenue" and the correct telephone number is "(408) 735-5893". Page 281: Third paragraph: The correct street address is "310 N Mary Avenue" and the correct telephone number is "(408) 735-5893". Page 283: Table 12.2: "PRIVATE KEY: d e^(-1)" should be "PRIVATE KEY: d = e^(-1)". Page 286: Third paragraph: "Eve gets Alice to sign y," "y" should be italicized. Second to last line: "Eve wants to Alice to" should be "Eve wants Alice to". Page 287: Last line: Wiener's attack is misstated. If d is less than one-quarter the length of the modulus, then the attack can use e and n to find d quickly. Page 288: The correct street address is "310 N Mary Avenue" and the correct telephone number is "(408) 735-5893". Page 289: The correct street address is "310 N Mary Avenue" and the correct telephone number is "(408) 735-5893". Page 292: Fifth line: "sqrt(x/v)" should be "sqrt(1/v)". Page 294: Second and third lines: "Bob" should be "Victor." Page 295: First line: "t random integers fewer than n" should be "t random numbers less than n". Page 297: Last line: "when" should be "where". Page 301: Middle of the page: Delete the sentence "Since the math is all correct, they do this step." Page 302: Fourth line from bottom: "a" should be in italics. Page 303: "Authentication Protocol," step (1): Add "She sends x to Victor." Page 305: Third paragraph, parenthetical remark: "NIST claimed that having DES meant that both that both the algorithm and the standard were too confusing" should be "NIST claimed that having DES mean both the algorithm and the standard was too confusing". Page 306: Eighth line: "cryptographers' paranoia" should be "paranoia". Page 307: "Description of the Algorithm": "p = a prime number 2^L bits long" should be "p = a prime number L bits long". "g = h^((p-1)/q)" should be "g = h^((p-1)/q) mod p". Page 309: Third line: "random k values and then precompute r values" should be "random k-values and then precompute r-values". Page 314: Protocol, step (1): "when" should be "where". Page 319: There should be a blank line before "discrete logarithm:" and another before "factoring:". Fourth line from the bottom: "depends more on the" should be "depends on more than the". Page 321: Third line: "when h" should be "where h". Page 322: Second paragraph: "over 500 pairs of people" should be "253 pairs of people". Page 326: In the definition of h_i, "H_(i-1)" should be "h_(i- 1)". Page 330: Definitions of FF, GG, HH, and II are wrong. These are correct: FF: "a = b + ((a + F(b,c,d) + M_j + t_i) <<< s)" GG: "a = b + ((a + G(b,c,d) + M_j + t_i) <<< s)" HH: "a = b + ((a + H(b,c,d) + M_j + t_i) <<< s)" II: "a = b + ((a + I(b,c,d) + M_j + t_i) <<< s)" Page 336: "HAVAL," sixth line: "160, 92, 224" should be "160, 192, 224". Page 339: "LOKI Single Block": In computation of Hi, drop final "XOR M_i". Page 340: "Modified Davies-Meyer": In computation of H_i, "M_i" should be subscripted. Page 342: "Tandem Davies-Meyer": In computation of W_i, "M_i" should be subscripted. Page 345: "Stream Cipher Mac", first line:" "A truly elegant MDC" should be "A truly elegant MAC". Page 347: Formula: "aX_(n1)" should be "aX_(n-1)". Second paragraph: "(For example, m should be chosen to be a prime number.)" should be "(For example, b and m should be relatively prime.)" Page 351: Second line of text: "they hold current" should be "they hold the current". Page 353: Third line: ">> 7" should be ">> 31". Fourth line: ">> 5" should be ">> 6". Fifth line: ">> 3" should be ">> 4". Eighth line: "(ShiftRegister)" should be "(ShiftRegister))". Tenth line: "< 31" should be "<< 31". Second paragraph: "are often used from stream-cipher" should be "are often used for stream-cipher". Page 356: Source code: "ShiftRegister = (ShiftRegister ^ (mask >> 1))" should be "ShiftRegister = ((ShiftRegister ^ mask) >> 1)". Page 360: Equation should not be "l(2^1-1)^(n-1)", but "l(2^l- 1)^(n-1)". Page 362: Figure 15.10: "LFSR-B" should be "LFSR-A" and vice versa. The second "a(t+n-1)" should be "a(t+n-2)", and the second "b(t+n-1)" should be "b(t+n-2)". Page 363: Fourth paragraph: "cellular automaton, such as an CSPRNG" should be "cellular automaton as a CSPRNG". Page 365: "Blum-Micali Generator": In the equation, "x_i" should be an exponent of a, not a subscript. Page 367: Sixth paragraph: "Ingmar" should be "Ingemar". Page 370: "Using "Random Noise," first paragraph, last line: "output 2 as the event" should be "output 0 as the event". Page 371: Sixth line: "access/modify times of/dev/tty" should be "access/modify times of /dev/tty". Page 371: "Biases and Correlations," third line: "but there many types" should be "but there are many types". Page 376: Seventh line: "send a message, M" should be "send a message, P". Page 391: Second protocol, step (1): "in his implementation of DES" should be "in his implementation of DSS". Next sentence: "such that r is either q quadratic" should be "such that r is either a quadratic". Page 402: First line: "when" should be "where". Line 18: "2^t" should be "2^(-t)". Page 406: Step (5): "i<j" should be i>j". Page 417: Last paragraph: "Kerberos is a service Kerberos on the network" should be "Kerberos is a service on the network". Page 421: Figure 17.2: In the top message "C" should be lower case. Page 435: "RIPEM": "Mark Riorden" should be "Mark Riordan". Page 436: "Pretty Good Privacy," third paragraph: Delete fourth sentence: "After verifying the signature...." Page 436: Pretty Good Privacy is not in the public domain. It is copyrighted by Philip Zimmermann and available for free under the "Copyleft" General Public License from the Free Software Foundation. Page 437: Fifth line: Delete "assess your own trust level". "Clipper," second paragraph: reference should be "[473]". Fourth paragraph: references should be "[473,654,876,271,57]". Page 438: Middle of page: reference should be "[654]". "Capstone," first paragraph: reference should be "[655]". Page 445: The IACR is not the "International Association of Cryptographic Research," but the "International Association for Cryptologic Research." This is also wrong in the table of contents. Source Code: The decrement operator, "--", was inadvertently typesetted as an m-dash, "-". This error is on pages 496, 510, 511, 523, 527, 528, 540, and 541. There may be other places as well. Page 472: Third line: "2, 18, 11" should be "22, 18, 11". Eighteenth line: "for( i = 0; i<<16; i++ )" should be "for( i = 0; i<16; i++ )". Page 473: Function "cpkey(into)". "while (from endp)" should be "while (from < endp)". Page 478: Fourth line: "leftt > 4" should be "leftt >> 4". Seventh line: "leftt > 16" should be "leftt >> 16". Twentieth line: "leftt > 31" should be "leftt >> 31". Page 508: Line 8: "union U_INTseed" should be "union U_INT seed". Page 531: "for( i = 0; i<; i++ )" should be "for( i = 0; i<2; i++ )". Page 558: "#defineBOOLEAN int" should be "#define BOOLEAN int", "#defineFALSE0" should be "#define FALSE 0", and "#defineTRUE(1==1)" should be "#define TRUE (1==1)". Page 564: "#define BOOLEANint" should be "#define BOOLEAN int", "#define FALSE0" should be "#define FALSE 0", and "#defineTRUE(1==1)" should be "#define TRUE (1==1)". Page 569: "rand() > 11" should be "rand() >> 11". Page 569: In "G13.H", "#define G13int" should be "#define G13 int". Page 572: Reference [45]: "Haglen" should be "Hagelin". Page 576: References [136] and [137]: "Branstead" should be "Branstad." Page 578: Reference [184] "Proof that DES Is Not a Group" should be "DES Is Not a Group." The correct page numbers are 512-520. Page 589: Reference [475]: The publisher should be E.S. Mittler und Sohn, and the publication date should be 1863. Page 601: References [835] and [836]: "Branstead" should be "Branstad." Page 602: Reference [842]: "Solvay" should be "Solovay". Page 603: Reference [878]: "Weiner" should be "Wiener." This errata is updated periodically. For a current errata sheet, send a self-addressed stamped envelope to: Bruce Schneier, Counterpane Systems, 730 Fair Oaks Ave., Oak Park, IL 60302; or send electronic mail to: schneier(a)chinet.com.

1 0

THOUGHT: International Electronic Declaration of Rights
by Robert A. Hayden 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Hi everyone. This is a fairly involved piece, so forgive me if I ramble a bit. I just finished reading Sterling's The Hacker Crackdown, and one of the statements he said in there struck a chord with me and got me to thinking. Paraphrasing, Bruce said soemthing along the lines of 'Cyberspace is a world unto itself, without borders or national identity.' Why is this important? Because at the same time we are witnessing the birth of Cyberspace (an archaic, and almost vulgar term, yet also most appropriate), we are also witnessing a terrifying and growing movement towards the heavy-handed regulation of this new world. In cyberspace, national borders are merely annoyances on the Information Superhighway, much like that one pothole you manage to hit every morning on your way to work or school. Yet, as the information future comes into existance, governments will seek to put up checkpoints and roadblocks to make sure information does not propogate. Thus, I had a thought. What if we took it upon ourselves to write an International Electronic Declaration of Rights? A single body of ideas (not necessarily founded upon the U.S. Bill of Rights) that will seek to define the underlying tone of this non-existant cyberspace. It would have to be no more that a few statements about what ideals and freedoms we feel are not only important, but also granted to us on the basis of being living beings. Hang on, don't run away yet. :-) What to do with it, you ask? How do we get a bunch of geek-written libertarian ideals to mean somehting? Well, assuming we come up with our Electrion Declaration of Rights, the next step would be to get various civil-liberty organizations (such as EFF, ACLU, CPSR, and others outside the US) to sign on as supporters. Then we pitch it to corporations and universities world-wide, and get them to sign on. Soon, public pressure would force governments to look at it as a Rights issue, and perhaps we get it adopted as bodies of law or some such (a UN resolution?). Ok ok, I'm _obviously_ getting quite ahead of myself, and I apologize. But think about it, I do not know of a single resolution or declaration of the rights a citizen of Cyberspace is granted. Yes, each country has their own rules, but cyberspace doesn't understand the concept of borders, and perhaps it never will. Furthermore, there is precedent for International declarations of this sort. The United Nations has a Declaration of Human Rights (ftp.eff.org :/pub/CAF/civil-liberty/human-rights.un) [Note, though, that I avoided the use of the term 'human' above' for reasons that any avid sci-fi reader should recognize :-)]. If we based our declaration on THAT declaration, as opposed to basing it on the U.S. Bill of Rights, it would be less likely to meet objections from people outside of the United States. In any case, among the rights I think that need to be established (and this is by no means a complete list, jsut what I came up with in the last few hours) Freedom to say what you wish without fear of retaliation Freedom to participate in any forum without fear of retaliation Fundamental right to personal privacy both in storage and in communication (therein lies the right to cryptography) Freedom to hold any religious views your wish, including no religion Freedom from having religious views the basis of policy Access will not be denied to a person without due process Policies will not be implemented on the basis of race, colour, creed, gender, sexual orientation, language, religion, political or other opinion, national or social status, property, birth, or other status. Oops, sorry, went a little overboard, but you get the point (actually, I like the 'access' one. It's actually pretty important.) In any case, we are on the esge of a new world here, and I fear that reactionary regulation will make it into a dreadful world to live in. Perhaps something like the above, coupled with a grassroots organizational effort that we have shown to be so successful in cyberspace will perhaps slow the regulational onslaught, or perhaps even turn it to freedoms advantage. I'd really like to hear your opinions on this. (BTW: I did not bring this up in EFF forums because I was concerned with 'Americanizing' this idea too much. Instead, it is my belief that if this was a more international effort, with US and other civil-liberty groups signing on AFTER, it may be more successful. Perhaps I'm wrong which case I will repost this into other forums). I appreciate your time. ____ Robert A. Hayden <=> hayden(a)krypton.mankato.msus.edu \ /__ -=-=-=-=- <=> -=-=-=-=- \/ / Finger for Geek Code Info <=> Political Correctness is \/ Finger for PGP 2.3a Public Key <=> P.C. for "Thought Police" - - -=-=-=-=-=-=-=- (GEEK CODE 1.0.1) GAT d- -p+(---) c++(++++) l++ u++ e+/* m++(*)@ s-/++ n-(---) h+(*) f+ g+ w++ t++ r++ y+(*) -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLZ8siZ3BsrEqkf9NAQGTQQP+IjRM5BAUWY6sVYIAOoiZgHSlOzS327Ap CMnJ2ngMNQdtHN3S7kMkatrb9QA/W4H/tKTsQRTjVz4wR9OKO4R1KwDKMBpOfDGk Y95hUbWlnpcZwuS2g2cvOqY+yfHyazbI34VrnU8jFA0jd4vNLxL5hILyNQR3RaOS FjiGtJy0LPI= =ToZ2 -----END PGP SIGNATURE-----

5 7

Re: PHILIP ZIMMERMAN ARRESTED [NOT!]
by Stewart Brand 17 Dec '03

17 Dec '03

The Zimmerman prank---I'm sure not funny for him---hardens my line further against anonymity online. At its best, as here, it is an unholy nuisance. Thanks for posting the correction, John. I'm moderating a panel with Zimmerman later this week, and would have been confused.

4 3

Re: THOUGHT: Internation
by jamiel＠sybase.com 17 Dec '03

17 Dec '03

At 1:42 PM 04/04/94 -0400, Duncan Frissell wrote: >To: cypherpunks(a)toad.com > > >T >Yes, the U.N. has quite a fascist declaration of rights. It includes >T >such chestnuts as a right to a job, a right to shelter, a right to >T >medical care, and the right of a country to control its press (cf. >T >the UNESCO fiasco). No thanks. > >Also, the right to two weeks paid vacation a year. > >As a self-employed individual, I want all you UN advocates out there to >pay for my two-week vacations since I've never had one. <g> > >DCF I don't want to start a huge debate on this, I just would like to know if those who object to this object on grounds of practicality or ideology (in other words, for example do you object because you don't believe everyone is *entitled* to a job, or because you think it is idealistic and silly to write something like this when everyone knows capitalism requires unemployment.)

1 0

Crunch Time
by Jeff Davis 17 Dec '03

17 Dec '03

Hi Folks, McCandlish forwarded my request for help before I go see a Federal Reserve Bank President Tuesday 5 April. Thanks to you all, esp Ms. Dekker of DigiCash. It's occured to me that Clipper could cripple US banking in the world financial market due to the 80% opposition exposed by the Time poll. If all my banking is digitized, my private key ensure's secrurity of transactions and authentication of user. If privacy of US Banks are comprimised by Clipper, why can't I bank in Switzerland? Hoenig, the KC Federal Reserve President will be in a public forum 10:00 MST 5 April. I would appreciate your comments on my reasoning with an eye on turning the Federal Reserve Anti-Clipper. It's crunch time folks, so I'll be reading my email up until 09:30 Tuesday. This is my private battle, so send your email to: <eagle(a)deeptht.armory.com> or <jldavis(a)nyx.cs.du.edu> -- PGP PUBLIC KEY via finger! JAFEFFM Speaking & Thinking For Myself! * eagle(a)deeptht.armory.com email info(a)eff.org * *** O U T L A W S On The E L E C T R O N I C F R O N T I E R **** ***** Committed to Free Public Internet Access for World Peace *****

1 0

Re: Cyberspace, Crypto Anarchy, and Pushing Limits
by Hal 17 Dec '03

17 Dec '03

A thought-provoking essay as usual from Tim. However, I see a contradiction between: > * Crypto means access to "regions" can be controlled by "owners": > > - "my house, my rules" enforced locally, without central State > authority and: > * Physical location of cyberspace locations will be increasingly hard > to pin down. A vast "labyrinth of rooms and corridors" might be > physically instantiated on a computer in Malaysia, while a "virtual > gambling hall" is being run via cryptographic cutouts (remailers) from > someone's bedroom in Provo, Utah. The problem I have is that it is not clear that cyberspace is a space, that one can identify regions which have boundaries, and which can be patrolled by owners. These physical, 2-D and 3-D concepts do not map well to cyberspace. Cyberspace is more of a mental conception, a meeting of the minds. It's not clear that it can be owned. For a concrete example, who owns the Cypherpunks list? Tim and Eric started it, Eric keeps the software working, and John Gilmore supplies the machine, as I understand it (apologies if I am leaving someone out). Do they own the list? What about the role of the contributors? Aren't they the ones who give the list value? (Granted, Tim, Eric and John have been some of the best contributors, but that is separate from their role, if any, as owners of the list.) Suppose, as Tim implies, that the list someday evolved to be some kind of virtual list, hosted on a flexible network of machines around the globe. Who would the owners be then? I would suggest that there would not nec- essarily be any. The list would be a voluntary meeting place for people who had certain interests. Its existance would be essentially defined by the commonality of that interest. It exists not in a cyberspace thought of as machines on a net of wires and fiber, but in a conceptual space that transcends the physical machines which support it. The issue of the ownership of cyberspace has similarities more to the ownership of intellectual property than of houses and roads and other physical objects, IMO. And the problems which arise when you try to fence off part of intellectual property space will also be a part of attempts to own cyberspace. Just another view - Hal

4 3

Re: PHILIP ZIMMERMAN ARRESTED [NOT!]
by dmandl＠lehman.com 17 Dec '03

17 Dec '03

> From: Stewart Brand <sbb(a)well.sf.ca.us> > > The Zimmerman prank---I'm sure not funny for him---hardens my line > further against anonymity online. At its best, as here, it is an > unholy nuisance. People have gotten anonymous death threats over the telephone and poison pen letters by mail. Are you against phone and mail anonymity? And this wasn't even such a destructive prank! And it was perpetrated on April 1. Doesn't seem like such a big deal to me. --Dave.

1 0

Re: Bekenstein Bound
by Jim choate 17 Dec '03

17 Dec '03

> > I know this is off topic, but as an astrophysicist I can't let it lie. > >First off, Black holes are singularities or points and have no volumes. > > Black Hole refers to the event horizon, the geometry is not nice inside that. > > > >Second, the 'surface' of the event horizon is a fractal and is therefore > >better represented by a volume. > > The 'surface' is not fractal. It is a simple bounded spheroid of finite area. > > > >Third, Black holes are not de-coupled from the rest of the universe, they > >emit 'Hawkings Radiation' which eventually leads to the evaporatio of every > >black hole, the bigger the faster. > > Blackholes evaporate through Hawking radiation the SMALLER the faster. > Stellar mass black holes will not evaporate in the age of the universe. > This radiation does not carry information about the interior. It is formed > from the quantum field just above the surface. > > > >Fifth, volume is not an issue because several accepted theories imply a > >'many worlds' type of reality. Some of these theories even allow a certain > > > >amount of information to leak between them. This occurs because when the > >Hamiltonian is constructed some states prevent or exclude other states and the > >state space turns out to be smaller than at first apparent. > > This is philosophy not physics. > > > >Sixth, everyone (incl. me initialy) was discussing QED in exclusion. This is > >completely incorrect. You must include QCD and it is a complete unknown at this > >point. When QED succeded because of Feynmann the tools were applied to the > >Quantuam Chromodynamics of Quarks and it has not solved any problems. > > I have no idea what you are trying to say here. > > -------------------------------------------------- > Lance Cottrell who does not speak for CASS/UCSD > loki(a)nately.ucsd.edu > PGP 2.3 key available by finger or server. > > "Love is a snowmobile racing across the tundra. Suddenly > it flips over, pinning you underneath. At night the ice > weasels come." > --Nietzsche > > > I appreciate your feedback. From what I have read of Hawkings and others work I would have to disagree w/ your statements that a black hole is equated w/ the event horizon. In every text (incl. the Hawkings book from the 70's on the subject) to makes a clear distinction. Several years ago (around '90) there was a whole raft of work dealing w/ the event horizon and the consensus that I got was that the event horizon was a fractal. Perhaps you would site some references where this theory is not accepted and a argumetn as to why it fails? What I am saying as far as QED/QCD is that w/o discussing both then the actions of electrons and photons are not quantum mechanical in the sense that they require statistical terms to describe their behaviour. Nowhere in Maxwells Equations is there a statistical term. If you know of a hole in the equations please let me know of it. I am not aware of any behaviour of electrons/photons which are not covered by these equations until hadrons are introduced.

2 1

wrong place at wrong time...
by tmp＠netcom.com 17 Dec '03

17 Dec '03

hello, whoever this `detweiler' person is you really seem to hate him. i appear to have been in the wrong place at the wrong time. would you like me to change my login name to something different so you don't confuse me with him? i think i heard it only costs $10 or so. yes, i do post from denver but i thought i heard detweiler was posting from somewhere else in colorado. (of course, geography is pretty meaningless in cyberspace.) yes, i am something of a newbie to this list. i heard about it out in talk.politics.crypto or something like that. i have also been reading up on your remailers from the public domain stuff out there (soda.berkeley.edu, etc.) the issues of `detweilering' do bring up some interesting questions. it seems to me that merely charging for access to remailers is not a sufficient deterrent (although it would have some effect). consider this argument: top-notch explosives can be very expensive, but that doesn't prevent terrorists from using them. in fact, it just has the effect of deterring the use of them by `casual' terrorists. wouldn't it be simpler to put limits on message propagation through a remailer? for example, limiting the volume of mail from a given source address? other interesting issues raised by `detweilering': hal finney forbids detweiler from using his remailer at any time. but (hello? is anyone home?) remailers operate on precisely the principle that names are irrelevant. how can you forbid anyone from doing something when you have no way of *identifying* them? how do you know what their mail aliases are? i wouldn't be surprised if hal finney censors *me* from his mailers just because he *suspects* that i am detweiler (ouch!). i think everyone here needs to be reminded why names were *invented*-- so that people can attribute actions to various individuals. it is `social ettiquete'. now, in some cases you may say that there is no need to attribute a name to an action (such as a posting) but then it seems you have no right to complain about `detweilers'. consider this-- suppose that i really hate t.c.may (this is just an example). i would like to screen my mailbox of everything he writes. but if he has dozens of imaginary aliases on netcom.com, each individually pretending to be a real person, how can i do this? it would be impossible. and don't say that the cost of multiple addresses would be a deterrent. what if he is a bored millionaire with nothing better to do? what if detweiler is a bored millionaire as well? apparently (from what i can determine) he seems to be endlessly entertained by harassing cypherpunks. and the criteria `that's an annoying post' is obviously not a very effective way of identifying him. so, `cypherpunks', you might consider the following problem. is it possible to have a system where there are multiple aliases allowed to a given person, and comparison between aliases (does alias1 == alias2) is permitted, but anonymity is generally preserved? one possibility is to remove screening one level from the users. that is, i tell a central server `stop sending me all posts generated by [alias1]'. if certain people suddenly disappear from my view that would be highly incriminating but not conclusive that they are all the same person. p.s. if detweiler is using the initials `tmp' (which he is judging by the FAQ piece that was reposted here) does anyone know what they stand for? p.p.s. can anyone tell me of recent press or media accounts of cypherpunk activity? thanks. p.p.p.s. try not to be so paranoid about `detweilers'. seems to me that if all he does is bang on a keyboard he is probably quite harmless. but then again, that's all that mitnick and morris did <g>

3 2

REMAIL: Ray's improved anonymous remailer
by Hal 17 Dec '03

17 Dec '03

I meant to reply to this several weeks ago, but was too busy then, so here are some comments now. From: rjc(a)gnu.ai.mit.edu (Ray) > Seeing as how everyone else is announcing their anonymous remailers, > I may as well announce mine which is nearing completion. The remailer > is written in Knuth's WEB using Perl so there is nice documentation. This sounds like an interesting approach. WEB is Knuth's methodology for creating self-documenting programming projects. You run them through a filter to create the executable code, Perl in this case. This should help portability and ease of support. > The remailer includes among other things, virtual addresses (handles), > padding/packetizing messages (splitting them up and sending pieces through > multiple remailer chains), chaining, mixing, a key-server, a list of > remailers server, a socket-server to bypass the sendmail queue and > get immediate error return, a stealth mode (delivery via direct SMTP or > socket instead of through the local sendmail), secure remailer network > (remailers sign and encrypt chained messages between each other), > fake remailer traffic, and other small features. The virtual handles are > fairly secure. They can be stored in the database as either plaintext real > email addresses, virtual addresses located elsewhere on the remailer network, > or SAEE cypherpunk remailer blocks (self-addressed encrypted envelope) These mostly sound like great features. The virtual addresses are something we have needed for a long time. The idea of keeping records of which remailers are responding should help with the use of the network, too. The one problem with this is that it might be tempting for the users to just trust the remailers to choose their chain paths. It would be much better for the user's own software to hook up, find out which remailers are operating, then choose a chain. Ray's software will allow this, but this function could be split off from the remailers to a specialized server, perhaps. I'm not sure about the advantages of remailers signing and encrypting messages between themselves. It seems to me that the network should work even without this. Ideally we don't want the remailer network to be too centralized and close-knit. It's better for them to be strangers to each other since if they coordinate their efforts they can defeat anonymity. > p.p.s. e-mail commands are of the same form as the extropian's mailing > list, backwards compatibility with the cypherpunks pasting token is not > supported. Why? All headers in the message are ignored (and in socket-mode, > there is no header anyway) and the prefered mode of operation is to encrypt > the body and the commands so no outside eyes can see the remail request > destination nor the message subject. This was one reason I suggested supporting both old-style CP and the extropians-style syntax ("::Anon-To"). As Ray suggests, in some cases we might not have message headers in the RFC822 sense. I think it is simpler to think about a message which has remailer commands at the top. > Socket mode provides a more secure form of operation by bypassing the > standard sendmail delivery mechanism allowing a message to be > piped directly to the remailer. In addition, the socket mode remailer > functions as an information server allowing clients to request > a publically networked list of public keys and up-to-date list of > \rem servers. The port number can be anything but I'm suggesting we all > agree to use port 2258. The number of sites which allow users to run socket servers is far smaller than the number which allow mail filters, so not many people will be able to use this feature. OTOH the mail-only sites are generally of low security and an owned-and-operated system should be able to use this feature. So it is definately a plus for those who can use it. > Upon connection to the remailer port, a greeting message will be sent to you > of the following form. On the first line is a general greeting message > which can be any string. On the next line is status information separated > by ``/''. The status information in order is: \verb|remailer_name|, > version, administrator e-mail address, and finally a list of flags. > The flags are single character upper case letters specifying > the following options. {\bf P} to specify that the machine is > privately owned and single-user, {\bf M} for mixing enabled, {\bf C} for > chaining, {\bf K} if the keyserver is turned on, {\bf E} if this remailer > only accepts encrypted messages, and {\bf S} if stealth mode is on. This is a good feature, but it should also be available from non-socket remailers. There should probably also be a "Help" command to tell how to use the remailer. (A lot of people already have these features.) > Virtual Addresses consist of a {\bf user handle} and an optional > {\bf remailer name} separated by `{\bf \#}' I used `\#' because I wanted > to differentiate virtual addresses from internet style addresses. > An example of a virtual address is ``darkmodem\#deepanon'' which > means that the message should be sent to the user connected with the > handle ``darkmodem'' through the remailer named ``deepanon'' You can > chain your own remailers by simply adding multiple remailer names to the > virtual address. For example, ``user\#remailer1\#remailer2\#remailer3'' > which will send the message first through remailer1, then remailer2, > then remailer 3, and finally to whoever happens to be connected with > ``user''. A special remailer name ``*'' is provided. Each instance of > ``*'' in a remailer chain will be replaced by a random remailer. > For example, ``darkmodem\#*#*#deepanon'' will first chain the message > through two random remailers and then finally to deepanon. The random > remailers chosen are not guaranteed to be unique. Ray had mentioned above that these user handles can also map to encrypted remailer strings. This way users don't have to trust any one remailer op- erator to keep their identity secret. This need for trust is one reason I am not enthusiastic about user#remailer1#remailer2#remailer3 as an address, although it is admirably concise and easy to use. The problem is that it exposes the path to the first remailer in the chain. I really feel that paths must use nested encryption to be of much value. Similarly, the darkmodem#*#*#deepanon requires the user to really trust the first remailer in the chain. Perhaps it deserves such trust, but I feel that a system which does not require such trust would be superior. (Again, Ray's proposal is broad enough that it will allow non-trust modes of operation, as I understand it; my main concern is that these other options are so easy that they will tempt people to be lazy and slip into modes where they are vulnerable to unscrupulous remailer operators.) I am really looking forward to seeing Ray's software. It sounds like a good package of functions. Hal

1 0