From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: whitakerNeternity.demon.co.uk.demon.co.uk ("Russell E. Whitaker") Date: Mon, 21 Sep 1992 13:24:27 +0000 Subject: Long but good: Hammill on encryption Message-ID: <717081867snx@eternity.demon.co.uk.demon.co.uk> MIME-Version: 1.0 Content-Type: text/plain The following is the text of a *very* interesting speech given in 1987 by mathematician Chuck Hammill. The Soviet Union is mentioned; while this may be a little dated, there's always China... and Cuba... and a few other places... Enjoy, Russell FROM CROSSBOWS TO CRYPTOGRAPHY: THWARTING THE STATE VIA TECHNOLOGY Given at the Future of Freedom Conference, November 1987 You know, technology--and particularly computer technology--has often gotten a bad rap in Libertarian cir- cles. We tend to think of Orwell's 1984, or Terry Gilliam's Brazil, or the proximity detectors keeping East Berlin's slave/citizens on their own side of the border, or the so- phisticated bugging devices Nixon used to harass those on his "enemies list." Or, we recognize that for the price of a ticket on the Concorde we can fly at twice the speed of sound, but only if we first walk thru a magnetometer run by a government policeman, and permit him to paw thru our be- longings if it beeps. But I think that mind-set is a mistake. Before there were cattle prods, governments tortured their prisoners with clubs and rubber hoses. Before there were lasers for eavesdropping, governments used binoculars and lip-readers. Though government certainly uses technology to oppress, the evil lies not in the tools but in the wielder of the tools. In fact, technology represents one of the most promis- ing avenues available for re-capturing our freedoms from those who have stolen them. By its very nature, it favors the bright (who can put it to use) over the dull (who can- not). It favors the adaptable (who are quick to see the merit of the new( over the sluggish (who cling to time- tested ways). And what two better words are there to de- scribe government bureaucracy than "dull" and "sluggish"? One of the clearest, classic triumphs of technology over tyranny I see is the invention of the man-portable crossbow. With it, an untrained peasant could now reliably and lethally engage a target out to fifty meters--even if that target were a mounted, chain-mailed knight. (Unlike the longbow, which, admittedly was more powerful, and could get off more shots per unit time, the crossbow required no formal training to utilize. Whereas the longbow required elaborate visual, tactile and kinesthetic coordination to achieve any degree of accuracy, the wielder of a crossbow could simply put the weapon to his shoulder, sight along the arrow itself, and be reasonably assured of hitting his tar- get.) Moreover, since just about the only mounted knights likely to visit your average peasant would be government soldiers and tax collectors, the utility of the device was plain: With it, the common rabble could defend themselves not only against one another, but against their governmental masters. It was the medieval equivalent of the armor- piercing bullet, and, consequently, kings and priests (the medieval equivalent of a Bureau of Alcohol, Tobacco and Crossbows) threatened death and excommunication, respec- tively, for its unlawful possession. Looking at later developments, we see how technology like the firearm--particularly the repeating rifle and the handgun, later followed by the Gatling gun and more advanced machine guns--radically altered the balance of interpersonal and inter-group power. Not without reason was the Colt .45 called "the equalizer." A frail dance-hall hostess with one in her possession was now fully able to protect herself against the brawniest roughneck in any saloon. Advertise- ments for the period also reflect the merchandising of the repeating cartridge rifle by declaring that "a man on horseback, armed with one of these rifles, simply cannot be captured." And, as long as his captors were relying upon flintlocks or single-shot rifles, the quote is doubtless a true one. Updating now to the present, the public-key cipher (with a personal computer to run it) represents an equiv- alent quantum leap--in a defensive weapon. Not only can such a technique be used to protect sensitive data in one's own possession, but it can also permit two strangers to ex- change information over an insecure communications channel--a wiretapped phone line, for example, or skywriting, for that matter)--without ever having previously met to exchange cipher keys. With a thousand-dollar com- puter, you can create a cipher that a multi-megabuck CRAY X-MP can't crack in a year. Within a few years, it should be economically feasible to similarly encrypt voice communi- cations; soon after that, full-color digitized video images. Technology will not only have made wiretapping obsolete, it will have totally demolished government's control over in- formation transfer. I'd like to take just a moment to sketch the mathemat- ics which makes this principle possible. This algorithm is called the RSA algorithm, after Rivest, Shamir, and Adleman who jointly created it. Its security derives from the fact that, if a very large number is the product of two very large primes, then it is extremely difficult to obtain the two prime factors from analysis of their product. "Ex- tremely" in the sense that if primes p and q have 100 digits apiece, then their 200-digit product cannot in gen- eral be factored in less than 100 years by the most powerful computer now in existence. The "public" part of the key consists of (1) the prod- uct pq of the two large primes p and q, and (2) one fac- tor, call it x , of the product xy where xy = {(p-1) * (q-1) + 1}. The "private" part of the key consists of the other factor y. Each block of the text to be encrypted is first turned into an integer--either by using ASCII, or even a simple A=01, B=02, C=03, ... , Z=26 representation. This integer is then raised to the power x (modulo pq) and the resulting integer is then sent as the encrypted message. The receiver decrypts by taking this integer to the (secret) power y (modulo pq). It can be shown that this process will always yield the original number started with. What makes this a groundbreaking development, and why it is called "public-key" cryptography," is that I can openly publish the product pq and the number x , while keeping secret the number y --so that anyone can send me an encrypted message, namely x a (mod pq) , but only I can recover the original message a , by taking what they send, raising it to the power y and taking the result (mod pq). The risky step (meeting to exchange cipher keys) has been eliminated. So people who may not even trust each other enough to want to meet, may still reliably ex- change encrypted messages--each party having selected and disseminated his own pq and his x , while maintaining the secrecy of his own y. Another benefit of this scheme is the notion of a "dig- ital signature," to enable one to authenticate the source of a given message. Normally, if I want to send you a message, I raise my plaintext a to your x and take the result (mod your pq) and send that. However, if in my message, I take the plaintext a and raise it to my (secret) power y , take the result (mod my pq), then raise that result to your x (mod your pq) and send this, then even after you have normally "decrypted" the message, it will still look like garbage. However, if you then raise it to my public power x , and take the result (mod my public pq ), so you will not only recover the ori- ginal plaintext message, but you will know that no one but I could have sent it to you (since no one else knows my secret y). And these are the very concerns by the way that are to- day tormenting the Soviet Union about the whole question of personal computers. On the one hand, they recognize that American schoolchildren are right now growing up with com- puters as commonplace as sliderules used to be--more so, in fact, because there are things computers can do which will interest (and instruct) 3- and 4-year-olds. And it is pre- cisely these students who one generation hence will be going head-to-head against their Soviet counterparts. For the Soviets to hold back might be a suicidal as continuing to teach swordsmanship while your adversaries are learning ballistics. On the other hand, whatever else a personal computer may be, it is also an exquisitely efficient copying machine--a floppy disk will hold upwards of 50,000 words of text, and can be copied in a couple of minutes. If this weren't threatening enough, the computer that performs the copy can also encrypt the data in a fashion that is all but unbreakable. Remember that in Soviet society publicly ac- cessible Xerox machines are unknown. (The relatively few copying machines in existence are controlled more inten- sively than machine guns are in the United States.) Now the "conservative" position is that we should not sell these computers to the Soviets, because they could use them in weapons systems. The "liberal" position is that we should sell them, in the interests of mutual trade and cooperation--and anyway, if we don't make the sale, there will certainly be some other nation willing to. For my part, I'm ready to suggest that the Libertarian position should be to give them to the Soviets for free, and if necessary, make them take them . . . and if that doesn't work load up an SR-71 Blackbird and air drop them over Moscow in the middle of the night. Paid for by private sub- scription, of course, not taxation . . . I confess that this is not a position that has gained much support among members of the conventional left-right political spectrum, but, af- ter all, in the words of one of Illuminatus's characters, we are political non-Euclideans: The shortest distance to a particular goal may not look anything like what most people would consider a "straight line." Taking a long enough world-view, it is arguable that breaking the Soviet govern- ment monopoly on information transfer could better lead to the enfeeblement and, indeed, to the ultimate dissolution of the Soviet empire than would the production of another dozen missiles aimed at Moscow. But there's the rub: A "long enough" world view does suggest that the evil, the oppressive, the coercive and the simply stupid will "get what they deserve," but what's not immediately clear is how the rest of us can escape being killed, enslaved, or pauperized in the process. When the liberals and other collectivists began to at- tack freedom, they possessed a reasonably stable, healthy, functioning economy, and almost unlimited time to proceed to hamstring and dismantle it. A policy of political gradualism was at least conceivable. But now, we have patchwork crazy-quilt economy held together by baling wire and spit. The state not only taxes us to "feed the poor" while also inducing farmers to slaughter milk cows and drive up food prices--it then simultaneously turns around and sub- sidizes research into agricultural chemicals designed to in- crease yields of milk from the cows left alive. Or witness the fact that a decline in the price of oil is considered as potentially frightening as a comparable increase a few years ago. When the price went up, we were told, the economy risked collapse for for want of energy. The price increase was called the "moral equivalent of war" and the Feds swung into action. For the first time in American history, the speed at which you drive your car to work in the morning be- came an issue of Federal concern. Now, when the price of oil drops, again we risk problems, this time because Ameri- can oil companies and Third World basket-case nations who sell oil may not be able to ever pay their debts to our grossly over-extended banks. The suggested panacea is that government should now re-raise the oil prices that OPEC has lowered, via a new oil tax. Since the government is seeking to raise oil prices to about the same extent as OPEC did, what can we call this except the "moral equivalent of civil war--the government against its own people?" And, classically, in international trade, can you imag- ine any entity in the world except a government going to court claiming that a vendor was selling it goods too cheaply and demanding not only that that naughty vendor be compelled by the court to raise its prices, but also that it be punished for the act of lowering them in the first place? So while the statists could afford to take a couple of hundred years to trash our economy and our liberties--we certainly cannot count on having an equivalent period of stability in which to reclaim them. I contend that there exists almost a "black hole" effect in the evolution of nation-states just as in the evolution of stars. Once free- dom contracts beyond a certain minimum extent, the state warps the fabric of the political continuum about itself to the degree that subsequent re-emergence of freedom becomes all but impossible. A good illustration of this can be seen in the area of so-called "welfare" payments. When those who sup at the public trough outnumber (and thus outvote) those whose taxes must replenish the trough, then what possible choice has a democracy but to perpetuate and expand the tak- ing from the few for the unearned benefit of the many? Go down to the nearest "welfare" office, find just two people on the dole . . . and recognize that between them they form a voting bloc that can forever outvote you on the question of who owns your life--and the fruits of your life's labor. So essentially those who love liberty need an "edge" of some sort if we're ultimately going to prevail. We obvi- ously can't use the altruists' "other-directedness" of "work, slave, suffer, sacrifice, so that next generation of a billion random strangers can live in a better world." Recognize that, however immoral such an appeal might be, it is nonetheless an extremely powerful one in today's culture. If you can convince people to work energetically for a "cause," caring only enough for their personal welfare so as to remain alive enough and healthy enough to continue working--then you have a truly massive reservoir of energy to draw from. Equally clearly, this is just the sort of ap- peal which tautologically cannot be utilized for egoistic or libertarian goals. If I were to stand up before you tonight and say something like, "Listen, follow me as I enunciate my noble "cause," contribute your money to support the "cause," give up your free time to work for the "cause," strive selflessly to bring it about, and then (after you and your children are dead) maybe your children's children will actu- ally live under egoism"--you'd all think I'd gone mad. And of course you'd be right. Because the point I'm trying to make is that libertarianism and/or egoism will be spread if, when, and as, individual libertarians and/or egoists find it profitable and/or enjoyable to do so. And probably only then. While I certainly do not disparage the concept of poli- tical action, I don't believe that it is the only, nor even necessarily the most cost-effective path toward increasing freedom in our time. Consider that, for a fraction of the investment in time, money and effort I might expend in try- ing to convince the state to abolish wiretapping and all forms of censorship--I can teach every libertarian who's in- terested how to use cryptography to abolish them unilaterally. There is a maxim--a proverb--generally attributed to the Eskimoes, which very likely most Libertarians have al- ready heard. And while you likely would not quarrel with the saying, you might well feel that you've heard it often enough already, and that it has nothing further to teach us, and moreover, that maybe you're even tired of hearing it. I shall therefore repeat it now: If you give a man a fish, the saying runs, you feed him for a day. But if you teach a man how to fish, you feed him for a lifetime. Your exposure to the quote was probably in some sort of a "workfare" vs. "welfare" context; namely, that if you genuinely wish to help someone in need, you should teach him how to earn his sustenance, not simply how to beg for it. And of course this is true, if only because the next time he is hungry, there might not be anybody around willing or even able to give him a fish, whereas with the information on how to fish, he is completely self sufficient. But I submit that this exhausts only the first order content of the quote, and if there were nothing further to glean from it, I would have wasted your time by citing it again. After all, it seems to have almost a crypto-altruist slant, as though to imply that we should structure our ac- tivities so as to maximize the benefits to such hungry beggars as we may encounter. But consider: Suppose this Eskimo doesn't know how to fish, but he does know how to hunt walruses. You, on the other hand, have often gone hungry while traveling thru walrus country because you had no idea how to catch the damn things, and they ate most of the fish you could catch. And now suppose the two of you decide to exchange information, bartering fishing knowledge for hunting knowledge. Well, the first thing to observe is that a transaction of this type categorically and unambiguously refutes the Marxist premise that every trade must have a "winner" and a "loser;" the idea that if one person gains, it must necessarily be at the "expense" of another person who loses. Clearly, under this scenario, such is not the case. Each party has gained some- thing he did not have before, and neither has been dimin- ished in any way. When it comes to exchange of information (rather than material objects) life is no longer a zero-sum game. This is an extremely powerful notion. The "law of diminishing returns," the "first and second laws of thermodynamics"--all those "laws" which constrain our possi- bilities in other contexts--no longer bind us! Now that's anarchy! Or consider another possibility: Suppose this hungry Eskimo never learned to fish because the ruler of his nation-state had decreed fishing illegal. Because fish contain dangerous tiny bones, and sometimes sharp spines, he tells us, the state has decreed that their consumption--and even their possession--are too hazardous to the people's health to be permitted . . . even by knowledgeable, willing adults. Perhaps it is because citizens' bodies are thought to be government property, and therefore it is the function of the state to punish those who improperly care for govern- ment property. Or perhaps it is because the state gener- ously extends to competent adults the "benefits" it provides to children and to the mentally ill: namely, a full-time, all-pervasive supervisory conservatorship--so that they need not trouble themselves with making choices about behavior thought physically risky or morally "naughty." But, in any case, you stare stupefied, while your Eskimo informant re- lates how this law is taken so seriously that a friend of his was recently imprisoned for years for the crime of "pos- session of nine ounces of trout with intent to distribute." Now you may conclude that a society so grotesquely oppressive as to enforce a law of this type is simply an affront to the dignity of all human beings. You may go far- ther and decide to commit some portion of your discretion- ary, recreational time specifically to the task of thwarting this tyrant's goal. (Your rationale may be "altruistic" in the sense of wanting to liberate the oppressed, or "egoistic" in the sense of proving you can outsmart the oppressor--or very likely some combination of these or per- haps even other motives.) But, since you have zero desire to become a martyr to your "cause," you're not about to mount a military campaign, or even try to run a boatload of fish through the blockade. However, it is here that technology--and in particular in- formation technology--can multiply your efficacy literally a hundredfold. I say "literally," because for a fraction of the effort (and virtually none of the risk) attendant to smuggling in a hundred fish, you can quite readily produce a hundred Xerox copies of fishing instructions. (If the tar- geted government, like present-day America, at least permits open discussion of topics whose implementation is re- stricted, then that should suffice. But, if the government attempts to suppress the flow of information as well, then you will have to take a little more effort and perhaps write your fishing manual on a floppy disk encrypted according to your mythical Eskimo's public-key parameters. But as far as increasing real-world access to fish you have made genuine nonzero headway--which may continue to snowball as others re-disseminate the information you have provided. And you have not had to waste any of your time trying to convert id- eological adversaries, or even trying to win over the unde- cided. Recall Harry Browne's dictum from "Freedom in an Unfree World" that the success of any endeavor is in general inversely proportional to the number of people whose persua- sion is necessary to its fulfilment. If you look at history, you cannot deny that it has been dramatically shaped by men with names like Washington, Lincoln, . . . Nixon . . . Marcos . . . Duvalier . . . Khadaffi . . . and their ilk. But it has also been shaped by people with names like Edison, Curie, Marconi, Tesla and Wozniak. And this latter shaping has been at least as per- vasive, and not nearly so bloody. And that's where I'm trying to take The LiberTech Project. Rather than beseeching the state to please not en- slave, plunder or constrain us, I propose a libertarian net- work spreading the technologies by which we may seize freedom for ourselves. But here we must be a bit careful. While it is not (at present) illegal to encrypt information when government wants to spy on you, there is no guarantee of what the fu- ture may hold. There have been bills introduced, for exam- ple, which would have made it a crime to wear body armor when government wants to shoot you. That is, if you were to commit certain crimes while wearing a Kevlar vest, then that fact would constitute a separate federal crime of its own. This law to my knowledge has not passed . . . yet . . . but it does indicate how government thinks. Other technological applications, however, do indeed pose legal risks. We recognize, for example, that anyone who helped a pre-Civil War slave escape on the "underground railroad" was making a clearly illegal use of technology--as the sovereign government of the United States of America at that time found the buying and selling of human beings quite as acceptable as the buying and selling of cattle. Simi- larly, during Prohibition, anyone who used his bathtub to ferment yeast and sugar into the illegal psychoactive drug, alcohol--the controlled substance, wine--was using technol- ogy in a way that could get him shot dead by federal agents for his "crime"--unfortunately not to be restored to life when Congress reversed itself and re-permitted use of this drug. So . . . to quote a former President, un-indicted co- conspirator and pardoned felon . . . "Let me make one thing perfectly clear:" The LiberTech Project does not advocate, participate in, or conspire in the violation of any law--no matter how oppressive, unconstitutional or simply stupid such law may be. It does engage in description (for educa- tional and informational purposes only) of technological processes, and some of these processes (like flying a plane or manufacturing a firearm) may well require appropriate li- censing to perform legally. Fortunately, no license is needed for the distribution or receipt of information it- self. So, the next time you look at the political scene and despair, thinking, "Well, if 51% of the nation and 51% of this State, and 51% of this city have to turn Libertarian before I'll be free, then somebody might as well cut my goddamn throat now, and put me out of my misery"--recognize that such is not the case. There exist ways to make your- self free. If you wish to explore such techniques via the Project, you are welcome to give me your name and address--or a fake name and mail drop, for that matter--and you'll go on the mailing list for my erratically-published newsletter. Any friends or acquaintances whom you think would be interested are welcome as well. I'm not even asking for stamped self- addressed envelopes, since my printer can handle mailing la- bels and actual postage costs are down in the noise compared with the other efforts in getting an issue out. If you should have an idea to share, or even a useful product to plug, I'll be glad to have you write it up for publication. Even if you want to be the proverbial "free rider" and just benefit from what others contribute--you're still welcome: Everything will be public domain; feel free to copy it or give it away (or sell it, for that matter, 'cause if you can get money for it while I'm taking full-page ads trying to give it away, you're certainly entitled to your capitalist profit . . .) Anyway, every application of these principles should make the world just a little freer, and I'm certainly willing to underwrite that, at least for the forseeable fu- ture. I will leave you with one final thought: If you don't learn how to beat your plowshares into swords before they outlaw swords, then you sure as HELL ought to learn before they outlaw plowshares too. --Chuck Hammill THE LIBERTECH PROJECT 3194 Queensbury Drive Los Angeles, California 90064 310-836-4157 [The above LiberTech address was updated June 1992, with the permission of Chuck Hammill, by: Russell Earl Whitaker whitaker@eternity.demon.co.uk Communications Editor 71750.2413@compuserve.com EXTROPY: The Journal of Transhumanist Thought AMIX: RWHITAKER Board member, Extropy Institute (ExI) [.sig revised 11 September 1992 /// Send mail to eternity node] -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAiqwg10AAAEEAMVNMI766ljeuW01xqXKYYV5lmDPvb+6dCQK3m1iBQdan0no pm35j1DIRp3UJZogAe5eimsQg1TALDhTq310OZs9+L6B/HxeX3+4BadIDad4g+xI lvaFY1Ut/hMdZNkw0tzNZOdUPiO4jYIyirReAUiMCm6jXzkTRITj7/vxxWtPAAUR tDNSdXNzZWxsIEUuIFdoaXRha2VyIDx3aGl0YWtlckBldGVybml0eS5kZW1vbi5j by51az4= =LOCL -----END PGP PUBLIC KEY BLOCK----- That's it from here. Over. Ono-Sendai Corporation From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Mon, 21 Sep 92 22:47:51 PDT To: cypherpunks@toad.com Subject: No Subject Message-ID: <9209220543.AA25094@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Welcome to the cypherpunks mailing list. We have a real mailing list now, and not just a mail alias on my account. Thanks to John Gilmore for space on hoptoad and Hugh Daniel for setting things up. Mail to the list members at cypherpunks@toad.com Request additions or deletions, talk to the list maintainer (me, Eric Hughes) at cypherpunks-request@toad.com Tell your friends about the list and have them join if they wish, and have them do the same, but please do not post the list address yet. We'd like to have a core group working before we advertise to avoid diffusion of interest at the outset. ---------------------- ANNOUNCEMENT Second Meeting -- October 10, 1992 The second meeting will be held at the new Cygnus offices. Exact address and directions to follow. We do not have an exact agenda yet, but one should be arriving in the next few days. Please mark you calendars now and start telling your friends. For this meeting and until further announced, we are using a transitive trust system for invitations. Invite anybody you want and let them invite anybody they want and so on. The crypto-anarchy game we tried out at the first meeting was as good a success as we could have hoped for from an untested idea. The game seems useful and fun enough to warrant continued play and play testing, so we'll be playing again at this and future meetings. We observed several interesting emergent behaviors in the first session, including resellers and reputation behaviors. We'll play a two hour session this time and discuss it afterwards. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: gnu Date: Tue, 22 Sep 92 12:17:43 PDT To: cypherpunks@toad.com Subject: Radio program on wiretaps and encryption: Wednesday at noon Message-ID: <9209221917.AA02319@toad.com> MIME-Version: 1.0 Content-Type: text/plain Newsgroups: sci.crypt,alt.privacy,alt.activism Subject: Radio program on wiretaps and encryption: Wednesday at noon Message-Id: <35449@hoptoad.uucp> Date: 22 Sep 92 19:15:19 GMT The Telecommunications Radio Project at KPFA is producing a series of thirteen hour-long radio programs on issues in communications. The first program is on the FBI's `Digital Telephony' e-z-wiretap proposal and the politics of encryption. The first half-hour will be an introduction and a panel discussion, featuring Jim Bidzos of RSA Data Security; Jim Kalstrom, head of investigative technology for the FBI; and me, representing the Electronic Frontier Foundation. You can phone in questions and comments in the second half of the show. The call-in number is: +1 800 464 5732 This program will be broadcast live on Wed, September 23, at noon, on these California stations: KPFA Berkeley KPFK Los Angeles KHSU Arcata These other stations will be picking up the broadcast, and probably transmitting it at a later time. Phone the station to find out when it's scheduled. KMUD Redway, California KCBL Sacramento, California KPBS San Diego, California WMNF Tampa, Florida KSUI Iowa City, Iowa KSAI Minneapolis, Minnesota KSMU Springfield, Missouri WCPN Cleveland, Ohio WYSO Yellow Springs, Ohio WBAI New York, New York WXXI Rochester, New York WEOS Geneva, New York KRCL Salt Lake City, Utah KPBX Spokane, Washington KUOW Seattle, Washington If you are not with in reach of a station that is broadcasting the Communications Revolution, please call your local station and pitch it to the program director. Have them call the Telecommincations Radio Project at KPFA, at +1 510 848 6767 x263 or x264. Future shows (Wednesdays at noon) will cover isses like how the concept of libraries is changing; what information is availible to (and held back from) the public; and electronic democracy where the voters can feed back directly to goverment agencies or change the outcome of an election via computer networks. Please tune in, and phone in good questions. See you in the airwaves! -- John Gilmore gnu@toad.com -- gnu@cygnus.com -- gnu@eff.org "It isn't given to us to know those rare moments when people are wide open and the lightest touch can wither or heal." From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Wed, 23 Sep 92 13:25:19 PDT To: cypherpunks@toad.com Subject: KPFA interview went well Message-ID: <9209232007.AA03117@netcom.com> MIME-Version: 1.0 Content-Type: text/plain This is my first test of this list...hope it works...and a brief opinion on the KPFA (etc.) interview with our own John Gilmore, representing the EFF, Jim Bidzos, of RSA Data Security, and Jim Kellstrom (sp?) of the FBI. I made a tape of it and can bring it to the 10/10/92 crypto meeting. John did an excellent job of raising the constitutional issues, while the FBI guy basically said "Trust us." Jim Bidzos of RSA Data Security didn't say much, as the thrust of the discussion was more on wiretapping and the proposed Digital Telephony bill, with not much of substance said about RSA and public key cryptography. I waited on the 1-800-464-5732 line to ask about the status of use of encryption, especially with RSA and RSA-like systems, but the show ran out of time before I could get on. This series seems timely. Every Wednesday at noon on KPFA. Check your local listings and the announcement list John sent out a few days ago. --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | RSA MailSafe Public Key: by arrangement From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nobody@soda.berkeley.edu Date: Wed, 23 Sep 92 17:28:41 PDT To: cypherpunks@toad.com Subject: New! Eric's Cheap Remailing Service. Free! Message-ID: <9209240027.AA27179@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Pssst. You don't know where you heard this. There's a new service available, and it's free. If you send mail to hughes@soda.berkeley.edu with a header line of the form Request-Remailing-To: then the software will strip off all the header lines (except the Subject: line) and remail it to the addressee of your choice. But there's this rumor that he's saving all the message that pass through. Damn. Mr. Crypto From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Mark Pesce Date: Thu, 24 Sep 92 00:45:30 PDT To: cypherpunks@toad.com Subject: Interesting post to alt.cyberpunk.tech Message-ID: <199209240744.AA20447@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Thought ya'll might be interested in this.... From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: cliff_stoll@harvard.edu Date: Wed, 23 Sep 92 22:53:12 PDT To: hughes@soda.berkeley.edu Subject: Fake Mail Message-ID: <9209240552.AA04259@atdt.org> MIME-Version: 1.0 Content-Type: text/plain Pssst! I have a nice fake mail program that interfaces with emacs. I'll send it along to anyone who wants it. PS: Have you seen my latest chocolate chip cookie recipe? Too bad about Martha. Maybe people like me are wed to science...and great cookies. ADFGVX From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pozar@kumr.lns.com (Tim Pozar) Date: Thu, 24 Sep 92 10:28:07 PDT To: tcmay@netcom.com (Timothy C. May) Subject: Re: KPFA interview went well In-Reply-To: <9209232007.AA03117@netcom.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Timothy C. May wrote: > This is my first test of this list...hope it works...and a brief > opinion on the KPFA (etc.) interview with our own John Gilmore, > representing the EFF, Jim Bidzos, of RSA Data Security, and Jim > Kellstrom (sp?) of the FBI. > [...] Thanks for your input. If anyone else wants to feed back to the program, they can send me email and I will pass it along to the producers. I am also the technical consultant to the show, so your mail will not be falling on deft ears... Tim -- Internet: pozar@kumr.lns.com FidoNet: Tim Pozar @ 1:125/555 UUCP: ...!uunet!kumr.lns.com!pozar Snail: Tim Pozar / KKSF / 77 Maiden Lane / San Francisco CA 94108 / USA Voice: +1 415 788 2022 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Thu, 24 Sep 92 11:10:30 PDT To: cypherpunks@toad.com Subject: No Subject Message-ID: <9209241809.AA23637@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain How to Make an Automated Remailer in Your Copious Spare Time with Easy to Find and Inexpensive Software Tools You May Have Lying Around. The basic remailer illustrates how to hook in automated software processing into the Unix mail system. Here are the basic elements. 1. .forward 2. slocal and .maildelivery 3. remail.perl 4. /usr/lib/sendmail -------------------------------------------- 1. .forward Unix mail provides a way to have accounts on many different machines but to receive all your mail in one place. That facility is the .forward file, which resides in the home directory. The file is one line long and contains the email address to which the mail will be forwarded. But the .forward file has another mode of operation. If the string begins with the pipe character '|', the mail will be piped through the program listed. Enclose the string with double quotes if you need spaces included. Here is my .forward file: "| /usr/local/lib/mh/slocal -user hughes" Thus all my mail gets processed by the slocal program, described next. I don't know where the man page for .forward is. Perhaps someone could provide a reference. --------- 2. slocal and .maildelivery The software system MH contains a bunch of useful tools for handling mail, only one of which we need. For details on MH, do 'man mh'. MH has a nice little mail hook processor called slocal. Its docs can be found by 'man mhook'. slocal can conditionally perform operations on mail messages and consider them either delivered or not. It allows multiple operations on individual mail messages. slocal reads the file .maildelivery when it starts up for instructions. Here is my .maildelivery file: # # field pattern action/ string # result (quote included spaces) # Request-Remailing-To "" pipe R "perl remail.perl" Request-Remailing-To "" file R archive.remailer The various pieces of the .maildelivery file are fully documented in the man page. I'll just explain what mine does. Each line describes one operation to be performed on each incoming mail message. Fields are separated by whitespace, so if you need to include spaces, use quotes. The first field, labelled field, is the mail header field to look for. slocal can selectively process on any header line. If the header line does not exist, then the mail does not match this line and no operation is performed. If the header line does exist, processing continues. The second field, pattern, is a text string to match with the contents of that header line, i.e. with everything after the colon. In my case, I put the empty string in, which matches everything. You need the pair of quotes to have a placeholder for the field contents. The next field, action, tells what to do with the message. 'pipe' sends the message to the standard input of the named program. 'file' appends the message to an archive or log file. A useful pipe command for testing is "tee foo", which makes a copy of the message in file foo, but does not append, so that you get an exact copy of what slocal is going to pass to your pipe. This allows testing of the pipe program without sending yourself mail all the time. The next field, result, tells what to do with the message after processing. I am currently using R for Regardless to indicate that this action should always be performed no matter what. The code R indicates that the mail should be considered not delivered after processing; thus slocal writes the mail back into my local spool and I see it as normal. Later, after I'm sick of looking at all the forwarded mail, I'll change this code to A, meaning if the processing succeeds, then the mail is considered delivered. The archive file will always remain R. The last field, string, is the parameter to the action. It is a file name or program. Use quotes to include spaces. The name of my mail processor is "perl remail.perl", which is to run the perl script remail.perl on the mail. The .maildelivery file is also the place to put encryption hooks to automatically decrypt the bodies of messages. More on that in a future version. --------- 3. remail.perl Perl is a wonderful language for doing all sorts of useful work like processing mail headers. Do 'man perl' for details, or get the O'Reilly book and really learn how to use it. The perl script, in summary, strips off the mail headers, saving the Subject: line, rewrites a new header, and appends the body of the previous message. Here is the script: --------- cut here --------- while (<>) { last if /^$/ ; $subject = $_ if /^Subject:/ ; if (/^Request-Remailing-To:/) { chop ; s/^.*:// ; $addressee = $_ ; } } #open( OUTPUT, ">foo" ) || die "Cannot open 'foo'." ; open( OUTPUT, "| /usr/lib/sendmail " . $addressee ) ; select( OUTPUT ) ; print "To:" . $addressee . "\n" ; print "From: nobody\n" ; print $subject ; print "Remailed-By: Eric Hughes \n" ; print "\n" ; while (<>) { } continue { print ; } --------- cut here --------- Here is a summary of the operation. To really understand this, you'll have to learn perl. The while loop processes standard input. 'last' terminates the loop as soon as a blank line is seen. A blank line separates the header from the body. The subject line, if seen, sets the subject variable to the whole subject line. The Request- header line has its final newline removed, the contents up to the colon substituted into nonexistence, and saves the rest in the addressee variable. Next the pipe to sendmail is opened and its output is selected so that all print commands will go to the pipe. There is a comment for a different output channel to the file foo which can be commented in for testing. Next the remailed header is constructed out of print statements. Lastly the rest of the standard input is passed through unmodified to the output channel. The while loop terminates when there is no more input. --------- 4. sendmail sendmail is the backend mailer; it expects complete mail messages and does not usually generate any line itself except for the first "From" (with no colon) line. Any header you construct will thus get passed through mostly unmodified. Hence you can put in any "From:" line you want and any other header info, such as my "Remailed-By:" line. sendmail expects the name of the addressee on its command line, otherwise it puts an "Apparently-To:" line in the header. Any mail processor which remails should probably go through sendmail, although it would also be possible to talk to an SMTP port directly, were you so motivated. MH also has some remailing programs; see 'man mhook'. --------- A few words for tinkerers. -- You can always send mail to yourself. Especially after you've done one kind of mail processing and want to pass the mail through the filters again. -- When getting started, create an empty .maildelivery file first and then get your .forward file working. Test it by sending messages to yourself. If you're not getting them, they are going into the bit bucket. All your other mail will as well, in this case, so if you can't afford to lose mail, do it right the first time or work on a spare account. -- Any mail slocal does not process will get delivered as normal. Running a remailer will not interfere with your other work. -- Remember to use quote marks. -- You don't need to be a sysadmin to run this kind of remailer. There is nothing, however, to prevent a sysadmin from running this sofware under an alias. The sysadmin is also a 'trusted user' to sendmail and can get rid of pesky "From"-no-colon lines. -- Perl has a random function which could be used to automatically choose various "From:" lines from a database. Remember to include yeltsy@kremvax.rus. -- postnews or inews could be substituted for sendmail. Different header lines would have to be created. Such a service could run in parallel with a remailer. You too can now repost to alt.sex.bondage! Enjoy. And watch for interesting improvements like encryption. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Thu, 24 Sep 92 11:13:21 PDT To: cypherpunks@toad.com Subject: The aural Tim Pozar In-Reply-To: Message-ID: <9209241811.AA23823@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Tim Pozar writes: >I am also the technical consultant to the show, so your mail will not be >falling on deft ears... Just for the record, Tim's _are_ deft, but they are _not_ deaf. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pozar@kumr.lns.com (Tim Pozar) Date: Thu, 24 Sep 92 16:42:21 PDT To: hughes@soda.berkeley.edu (Eric Hughes) Subject: Re: The aural Tim Pozar In-Reply-To: <9209241811.AA23823@soda.berkeley.edu> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Eric Hughes wrote: > Tim Pozar writes: > > >I am also the technical consultant to the show, so your mail will not be > >falling on deft ears... > > Just for the record, Tim's _are_ deft, but they are _not_ deaf. Thanks... :-) Tim -- Internet: pozar@kumr.lns.com FidoNet: Tim Pozar @ 1:125/555 UUCP: ...!uunet!kumr.lns.com!pozar Snail: Tim Pozar / KKSF / 77 Maiden Lane / San Francisco CA 94108 / USA Voice: +1 415 788 2022 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nobody@soda.berkeley.edu Date: Thu, 24 Sep 92 19:32:44 PDT To: cypherpunks@toad.com Subject: through mr. crypto Message-ID: <9209250231.AA10851@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain ** I am also the technical consultant to the show, so your mail will not be ** falling on deft ears... Awwww.... it wasn't that badly engineered. sho3t From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Mailer-Daemon@atdt.org (Mail Delivery Subsystem) Date: Thu, 24 Sep 92 16:49:37 PDT To: cypherpunks@toad.com Subject: Returned mail: Unable to deliver mail Message-ID: <9209242349.AB06629@atdt.org> MIME-Version: 1.0 Content-Type: text/plain ----- Transcript of session follows ----- 554 cypherpunks@toad.com... Recipient names must be specified ----- Unsent message follows ----- Return-Path: Received: by atdt.org (5.61+++/JLK-atdt) id AA06629; Thu, 24 Sep 92 19:49:05 -0400 Date: Thu, 24 Sep 92 19:49:05 -0400 From: cypherpunks@toad.com Message-Id: <9209242349.AA06629@atdt.org> To: cypherpunks@toad.com Subject: Information Brokers ____________________________________________________________________________ SYDNEY MORNING HERALD August 13 1992 HUGE TRADE IN PERSONAL FILES By MALCOLM BROWN Westpac, National Australia Bank, NRMA Insurance Ltd, Custom Credit and Citicorp are some of the big names in a damning report by the ICAC Assistant Commissioner, Mr Adrian Roden, QC, on the unauthorised release of confidential government information. Mr Roden found that there was a multi-million-dollar trade in such information which involved public servants, including police, and private inquiry agents. ""Information, from a variety of State and Commonwealth government sources and the private sector has been freely and regularly sold and exchanged for many years," he said. "NSW public officials have been heavily involved." Mr Roden heard 446 witnesses in public and private hearings over 168 days before compiling his 1,300-page report. Even so, he said, it was necessary to be selective; thousands of private and commercial inquiry agents had not examined. Mr Roden found that more than 250 people had participated in the illicit trade or had contributed to it. OOf these, 155 had engaged in corrupt conduct. A further 101 had engaged in conduct which allowed, encouraged or caused the occurrence of corrupt conduct. Many are NSW and Commonwealth public servants who sold information collected by the agencies where they work, including the Roads and Traffic Authority (RTA), police force, Telecom and Sydney County Council. The Attorney-General, Mr Hannaford, announced that the Director of Public Prosecutions had set up a task force to consider laying charges against more than 100 people named in the report. HHe said many of the public servants named could expect to lose their jobs and that the heads of all the government departments involved had been told to examine the report and take action against those involved. The Assistant Police Commissioner, Mr Col Cole, confirmed yesterday that five police officers had been suspended and announced that three task forces had been set up and computer security upgraded. Mr Hannaford foreshadowed the introduction of privacy legislation to make the unauthorised use of confidential information a criminal offence. The major banks said that they could not condone what their staff had done but said the staff had believed that they were acting in the best interests of their employers and the community. None of the banks was planning to sack staff found to be corrupt although several said the staff had been counselled or "educated". MMr Roden said the trade involved banks, insurance companies and other financial institutions which had provided "a ready market". The link was provided by private and commercial inquiry agents. With some banks, codes had been used to conceal the nature of the transactions. "As they have gone about their corrupt trade, commercial interest has prevailed over commercial ethics, greed ha~ prevailed over public duty; laws and regulations designed to protect confidentiality have been ignored," Mr Roden said. "Frequently the client, generally an insurance company, bank or other financial institution, ordered the information from the agent with a full appreciation of how it was to be obtained. ""The evidence disclosed that in the collection and recovery departments of a number of those institutions, it has long been standard practice to use confidential government information . . . as a means of locating debtors." Some finance and insurance companies had directed agents to keep all references to the trade off invoices and reports. "Some even directed that the agents falsely state the source of the information in their reports," Mr Roden said. "Some solicitors in private practice have sought and purchased confidential government information in circumstances in which they must have known that it could not have been properly obtained." Mr Kevin Rindfleish, an unlicensed private inquiry agent, had sold Department of Motor Transport/Roads and Traffic Authority and social security information "on a large scale". His principal client had been the ANZ Bank. AA private investigator, Mr Terence John Hancock, and his company, All Cities Investigations Pty Ltd, had sold confidential government information to the National Australia Bank and Westpac on a regular basis. Two employees of the NAB had used prior contacts to provide the bank with access to RTA, social security, Australia Post and immigration information. Between them, the employees also provided silent numbers and information on electricity consumers. The Advance Bank had "over a period of years" obtained information improperly released from the RTA, the Department of Social Security and the Department of Immigration. The practice was "known and approved at least to senior management level". New Zealand Insurance and Manufacturers Mutual had bought confidential government information from private investigators. NRMA Insurance Ltd and the Government Insurance Office were "found to have participated as freely in the illicit trade in confidential government information as their more commercially orientated competitors". "Evidence relating to NRMA Insurance Ltd established not only that it purchased confidential government information through private investigators, but also that investigators were required to obtain relevant government information by unauthorised means if they were to retain the company's work." EEsanda Finance Corporation Ltd had bought confidential information over at least 23 years. Custom Credit Corporation Ltd which had engaged in the illicit trade over "many years", had maintained false records to conceal how it obtained information. Alston de Zilwa, former underwriter and operations manager of Citicorp Ltd and later, Toyota Finance Australia Limited's credit operations manager, had established for each of the two companies a system for obtaining confidential information. The companies would seek information directly from employees of the DMA and RTA and pay a private inquiry agent, Mr Kevin Robinson, who would "launder" it, then invoice the companies for the corresponding sum. Mr Roden said that hundreds of thousands of dollars had changed hands in the trade uncovered. One agent had estimated that he had paid $40,000 to $50,000 a year for Social Security information alone. Another had said he received $100,000 over two years for government information. YYet another had, according to records, charged a bank $186,000 for "inquiry services" over a period of 18 months. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Judith Milhon Date: Fri, 25 Sep 92 03:02:38 PDT To: cypherpunks@toad.com Subject: secretions Message-ID: <199209251001.AA16909@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain "The alternative to mutual trust, which is indeed a risky gamble, is the security of the police state." -- Alan Watts This text may be published in MONDO2000 as my regular column, Irresponsible Journalism. Eric Hughes suggested the coda with the toad address, adding that it would be amusing to have it almost completely blotted by magic marker, as if inadequately censored. I don't want to be the venom in this toad. the idea is to draw in other useful minds. we can assume the WRONG PEOPLE already know the address. lady ada won't apologize for the gonzo wrapping for the ideas; she is concerned only that they be correct and clearly stated. clarifications, expansions, corrections are welcome. also abuse and threats, for that matter... any feedback, please feed me... THE CYPHERPUNK MOVEMENT by St. Jude I don't face-to-face all that much. And I don't like clubs. I was in the Black Hole for a reason: The Screamin' Memes were in town for one night only -- Thursday, of course. Thursday's the night, now that the weekend has annexed Fri. and Mon. I was lurking in the back, hoping not to see anybody, when the Jones brothers staked me out. Damn. They are deep into the street drugs. Keeping up with the Joneses is nigh impossible; their most trivial chitchat is an exercise in decryption. Eddy -- or maybe he was being Ellis that night -- was implying something about somebody when my right foot detonated down to its steel toe. I looked up -- way up -- to a face that wasn't there at all. Just a dome of black cloth, with goggles. Three-eyed goggles. Ah: a Chador. I'd heard of that. I screamed: "You stomped my foot FLAT!" "Sorry." "Are you okay?" "Oh maaaang." Many overlapping voices, all of them synthesized, blurted from above. Out of two tiny speakers hanging like earrings off a basketweave headband like a cop's belt. The head bowed, bringing it almost within biting range. "Gah. Ow. Ooo." Pretending to be demented with pain, I lurched deep into the Chador. But I was cool: I was rootling in there for clues. Ha! Male pheromones. Hardish male torso. I was jostling this lumpy equipment hanging off him, trying to get a good feel of it without alerting him. Nuh uh: _I_ meant electronics... what did _you_ think? Okay: I had some data to work with. Male with gadgets. Quelle surprise. "What the hell have you got on your feet? HORSESHOES?" A voice like rushing water: "Kothurni." The Chador shifted a little... and under his full black skirts I saw them: big weighted club-foot boots with concealed lifts, to disguise the wearer's height. Wicked. The pain and the espionage cleared my head. I was ready to deal. "So you're protecting your meat identity, right?" The Chador seemed to teeter a little. It goggled down at me as if I were a smear on a slide. Its third-eye goggle was a lens. Check. Out of the ambient murk loomed another Chador. Exactly the same height. Right. "How come you guys are in full drag?" "We're here for a... uh... party." The voice from the other Chador was a flanged saxophone, but I could swear it had a Texas accent. "Rubbish. You're having a cell meeting, right? " The near Chador, the one I had groped, seemed to teeter again. What sounded like a tape player on fast-forward came faintly from its interior. An earphone? The saxophone honked: "If I said I even understood what you meant, what kind of a chump would that make me?" "I could hazard a guess. I think you're cryptoanarchists -- what I'd call cypherpunks!" My Chador cracked up. I could tell. The farther one seemed to stiffen; I think it was giving me a hate stare. Hard to manage behind the whole 9 yards o' cloth. "Is that clever or what? I'm onto you like psilocybe on cowshit, dudes. You want to take over the world. Haha hahaha haaaaa." Both of them rocked back a little. I went in after them. "You want to talk encryption schemes? Let's talk cryptic. Tales from the cryp'ed. But make it fast: The Memes are comin' on." Oh, I was bluffing. I don't know much about cryptography. I was just 'tuding them from tech envy. Damn: Chadors. And me without the first widget. From the far guy came a cello, very suave: "The world has already been taken over. You may have noticed this. We're just trying to get some of it back." And the accent was -- Dutch? Bob's yr uncle. Gotcha. I hadn't been certain. Maybe chadors were now trendy club gear -- what do I know? "Hey -- that cello's another guy? How many you PACKIN' in there?" Out of my Chador a sawtooth rasped: "Variable. People are ringing in and out." "You're on line?" "This is a bridge. International." Sawtooth again. The cello resumed, an annoyed cello: "We don't believe in takeovers. In fact, we are working to make things UNTAKEOVERABLE." A theremin quivered, "And to make the world safe for anarchy. _We want the air-waves, baby_." It snickered across many frequencies. The Tejana saxophone chuckled, (and an eerie treat that was, too): "Problem is, how to guarantee privacy for pseudonyms. So you can have a pseudonymous economy." A toad croaked: "So, full-RSA encrypted EVERYTHING. No back doors. Secure digital money. Swiss bank accounts for the millions." The theremin: "A global monetary system that makes governments obsolete. Down come the governments. Goodbye the feds." It sang, whoopingly: "BYE BYE, LAWWww." Horrible broad-band snickering. The toad croaked: "Er... yes. Real freedom of speech, too. Libertech!" The Dutch cello was all business: "Okay, what does it take? You need real-time protocols to prove you own your pseudonym. And your pseudonyms have online reputations, via people you've done biz with -- like a distributed credit rating system. With maybe designated angels -- Fair Witnesses." I was charmed. "And you wear the chador when you face-to-face somebody who knows your handle!" The theremin wheeped: "Actually, unmasking your real identity could be the ultimate collateral -- your killable, _torturable_ body. Even without kids, you've got a hostage to fortune -- your own meat." I was reeling. "Oh yas yas. As Dylan said: 'They asked me for some collateral/ and I pulled down my pants'." Orchestral chuckles rained down on me. Was I an international hit? But at that exact moment The Memes hit the stage. The crowd did a 9.1 Richter lurch and the other Chador pitched onto my LEFT toe, maybe denting the steel. "AAIEEeeee. That's great COVERT GEAR you got there, guys. You couldn't sneak up on Helen Keller in a HAILSTORM." I was trying to spin down. "And dudes -- this is not the neighborhood for flashing the hardware. Getting rolled by winos is pretty LOW TECH." A spike-knuckled glove slithered out of the farther guy, clutching what looked, in the near-dark, like an electric razor. "_Gonna menace 'em with a clean shave_?" The sax: "Stunner. Bottom of the line. But." A hot line of pure energy cracked across its little trodes. Of course. Rushing water: "See ya." And they did a fade into the smoke. The Screamin' Memes were worthless. To hell with clubs. To hell with lots o' things, maybe. I am now sensing my roots, mahn; dey who are my bredren. Nerds. Nerds as mainstreamed by the grainy but still fetching Robt Redford in Sneakers... Nerds who will have their revenge at last, by making the online realer than our current regrettable reality... No, I'm not quite delusional. I've heard the cypherpunks are already distributing their encrypted email software, which is quick and slick. I might even join the revolution, which is, heh, already in progress. Yeah. Why not? Give me libertech or give me... _DES_? --------------------------------------------------------------------------- ------------------------- St. Jude, aka Lady Ada Lovelace, wrote "The Spook in the Machine" for MONDO #1, describing the enforcement of DES, the Data Encryption Scam with the handy backdoor. She can be reached online as stjude@well.sf.ca.us. Note: a definitely false rumor is now circulating that the revolutionists can be contacted via cypherpunks@toad.com. -------------------------------------------------------------------------- feed me? >jude< From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Fri, 25 Sep 92 11:37:12 PDT To: cypherpunks@toad.com Subject: the hopping remailer is done Message-ID: <9209251835.AA00599@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain The hopping remailer is finished. I wrote it this morning. The change to make a hopping remailer is very easy. Here's the new perl script: --------- cut here --------- while (<>) { last if /^$/ ; $subject = $_ if /^Subject:/ ; if (/^Request-Remailing-To:/) { chop ; s/^.*:// ; $addressee = $_ ; } } #open( OUTPUT, ">foo" ) || die "Cannot open 'foo'." ; open( OUTPUT, "| /usr/lib/sendmail " . $addressee ) ; select( OUTPUT ) ; print "To:" . $addressee . "\n" ; print "From: nobody\n" ; print $subject ; print "Remailed-By: Eric Hughes \n" ; # # check to see if there are header lines in the body to collapse # into the full header. # if ( $_ = <> ) { if (/^##$/) { # do nothing if the pasting token appears # the rest of the body will be directly appended # this allows for extra header lines to be added } else { # normal line print "\n" ; print $_ ; } } else { # empty body exit ; } while (<>) { } continue { print ; } --------- cut here --------- Short explanation. The 'print "\n" ;' line was moved inside the new if statement. The if statement reads a line of the body and stops the script if there is no body. The line read is tested to see if it contains the two characters "##" alone on the line. "##" is the ANSI C token pasting operator. If there is no pasting, a blank line is printed to mark the end of the header and the first line of the body is printed. If there is pasting, then the conditional does nothing, which has the effect that the body is appended directly onto the end of the header, allowing you to add more header lines after the header is rewritten. Here is a sample message that I sent myself after the new script was installed: --------- cut here --------- To: hughes Subject: multiple hops Request-Remailing-To: hughes ## X-Hop: 1 Request-Remailing-To: hughes ## X-Hop: 2 Request-Remailing-To: hughes ## X-Hop: 3 This is a test message of multiple hops. Eric --------- cut here --------- I received four pieces of mail after sending this to myself. The first was the actual letter, which is still delivering normally and not being filtered. The next two were the first and second remailings; they had X-Hop: 1 and 2. The last message was the final one, had X-Hop: 3 in its header and was delivered normally. At each stage, the header got rewritten and a new Request-Remailing-To: line inserted. When that mail got delivered, it was again rewritten, with a new remailing request. This process is extensible up to the 50K or so practical limitatation on mail size. Note that this system is not at all secure by itself. But if each message body were encrypted first, and the message first decrypted before the header re-write took place, the routing instructions as a whole would be hidden from prying eyes. That's the next project. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Mark Pesce Date: Fri, 25 Sep 92 16:27:24 PDT To: cypherpunks@toad.com Subject: Pointing out the obvious.... Message-ID: <199209252326.AA19540@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Hey, Kidz.... I don't mean to point out the obvious, but when you mention a certain scheme for secure transfer (3 initials, you guess), or a certain organization dedicated to keeping it from the public (3 initals, you guess again), THEY READ IT. OK? Did I make my point? If not, we're going to unsubscribe from this list like a bat out of hell. Over, OS Corp. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: not_root@nowhere.com Date: Fri, 25 Sep 92 17:27:32 PDT To: cypherpunks@toad.com Subject: Hints Message-ID: <9209260027.AA08573@atdt.org> MIME-Version: 1.0 Content-Type: text/plain Most internet traffic is archived (and later Grep'd) anyway. If you're really that worried about it, then we should have been speaking in Aramaic all this time, or using encrypted e-mail (and I'm sure traffic which mentions the characters "crypt" draws attention as well, and most of the msgs on this mailing list have already violated that one.) I'm interested to see the PGP addition to the re-mailer. -- Concerned, yet not overly unrealistic about it. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: "Fen Labalme" Date: Mon, 28 Sep 92 21:01:24 PDT To: "Cypher Punks" Subject: SEIZING THE MEDIA- A NETWOR Message-ID: <9209290409.AA25631@relay2.UU.NET> MIME-Version: 1.0 Content-Type: text/plain Mail*Link( Remote SEIZING THE MEDIA: A NETWORKER CONGRESS from PeaceNet ACTIV-L: Date: Sat, 26 Sep 1992 23:33:10 CDT Sender: Activists Mailing List From: "(Rich Winkel)" Subject: PAX: SEIZING THE MEDIA: A NETWORKER CONGRESS To: Multiple recipients of ACTIV-L /** gen.media: 141.0 **/ ** Topic: SEIZING THE MEDIA: NETWORKER CONGR ** ** Written 6:39 pm Sep 25, 1992 by openmedia in cdp:gen.media ** SEIZING THE MEDIA: A NETWORKER CONGRESS A weekend of activity to discuss, self-educate, and put into practice the creation of subversive media. 1:30pm Saturday 24 October to 6pm Sunday 25 October 1992 Media and resource exchange; slides, fax, posters, pamphlets, computer files, ideas, proposals, tactics Practical action on billboard improvement and removal; Big Art and postering E-mail and fax facility to receive material to be discussed and implemented during the weekend Documentation to all participants Materials supplied: photocopier reproduction/enlargement and the streets of Oxford Bloomin Arts, Princes Street, Cowley Road, Oxford, OX4, U.K. If you can't make it in person, you can take part in the Seizing the Media Congress by post, fax, E-mail. Send documents, comments, proposals, art, ideas, and posters. Post to: BM Jed, London WC1N 3XX, United Kingdom Fax to: (011 441) 0865 72 4317 E-Mail to: Eastoxcomcen@GN.APC.ORG Accommodation and other information are available from Friday night onwards. To make arrangements or get more information, get in touch with Oxfin between 1-4pm Mondays to Fridays at: (0865) 240545 >From the United States: 011 41865 240 545 Background: SEIZING THE MEDIA is the title of pamphlet written by the Immediast Underground and first released in Amsterdam , New York City, and Seattle in early 1992. The 26 pamphlet combines theory, graphics, research and proposals that examine: * Information control * Propaganda and advertising * CIA * Mind control * Immediast counter-offensives * tactics, subversive networking, public empowerment * multi-media * Public production libraries * the liberation of public space ...Just when Jesse Helms thought he made the world safe from poetic terrorism, along come the Immediasts, a cadre of media hackers who are fed up with the ecology of coercion that surrounds them. Their booklet SEIZING THE MEDIA proposes an all-out artistic assault on coercive communication, cultural monologue, and media control. They want all media insurgents to take back the airwaves with pirate radio, cable access TV, altering ads and billboards, and otherwise hacking the datasphere to break the spell of State/corporate media control. . . . from Gareth Branwyns STREET NOISE, Issue 7 of Mondo 2000 SEIZING THE MEDIA Version 1.1 is available for $3 from Open Media PO Box 2726 Westfield New Jersey 07091 USA THE IMMEDIAST UNDERGROUND is a centerless network of artists, writiers, hackers, culture jammers, pirate broadcasters, and posterists who connect with one another through information systems, mail art, networker congresses, and the underground press, and who communicate with the public through actions against all forms of coercive communication, space infringement, and media control. For more info contact: Immediast U. PO Box 2726 Westfield New Jersey 07091 USA DECENTRALIZED WORLD-WIDE NETWORKER CONGRESSES Since the beginning of the year, members of alternative info-nets, artists, insurgents, and cultural workers have been holding networker congresses, transnational engagements in cultural production, dialogue, collaborations, open exchange, subversive brainstorming, and collective disruptions of dominant culture. THE NETWORKER, A NEW PERCEPTION In societies where information is money and media is power, public access is as controlled as the corporate states grip on communication law, censorship, commerce, covert action and surveillance. In this context, uninhibited public communication, expression, and cultural production are acts of freedom, sovereignty, and defiance. Rooted in the drive to connect and exchange with others, Networker Congress engage in culture and media as the battleground for greater openness and freedom. MORE INFORMATION about NETWORKER CONGRESSES contact: H.R. Fricker Buro fur kunsterische Umtriebe CH 9043 Trogen Switzerland Retrofuturism PO Box 2278 Iowa City, Iowa 52244 Face of the Congress FaGaGaGa Po Box 1382 Youngstown, Ohio 44501 Peter Kaufman Bergenwissenstrasse 11 CH-8123 EbmatigenDecentralized Networker Congresses Switzerland Decentralized Networker Congresses Netshaker PO Box 978 Hanover, New Hampshire 03766 ** End of text from cdp:gen.media ** From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: postmastuh@dawkmastuh.guv Date: Thu, 1 Oct 92 14:35:52 PDT To: cypherpunks@toad.com Subject: Secure IRC Message-ID: <9210012143.AA00610@atdt.org> MIME-Version: 1.0 Content-Type: text/plain How about the idea of a secure Internet Relay Chat? A central server might maintain the list of everybody's Public Keys. If you wanted to broadcast a 'public' yet secure msg in a particular room making sure only participants in that room (and not eavesdroppers somewhere else on the wire) could read the msg you could encrypt your broadcast with the server's own Public Key. Send it. The Server receives it, decrypts it, then for each of the participants currently in this particular room, the server encrypts the msg with that person's Public Key and sends it. Private IRC msgs would be treated similarly, except that they'd be re-encrypted only once, for the intended private recipient. Anyone interested on working on this? 0r 1z 1t 2 layme? -- /|n0n1mu$ From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: omega@spica.bu.edu (The Omega) Date: Thu, 1 Oct 92 16:16:25 PDT To: cypherpunks@toad.com Subject: No Subject Message-ID: <9210012324.AA01012@spica.bu.edu> MIME-Version: 1.0 Content-Type: text/plain FOR IMMEDIATE RELEASE Contact: Nikki Draper (415) 322-3778 Computer Public Advocacy Group To Examine FBI Wiretap Scheme at October Annual Meeting. Palo Alto, Calif., October 1, 1992 -- Computer Professionals for Social Responsibility (CPSR), the national public interest organization based here, will take an in-depth look at its recent suit against the Federal Bureau of Investigation (FBI) during CPSR's 1992 Annual Meeting, October 17th and 18th at Stanford University in Palo Alto, Calif. CPSR Legal Counsel, David Sobel, will talk about the FBI suit for the first time since it was filed and moderate a panel discussion on the politics of cryptography at the annual meeting. The CPSR annual meeting is a provactive two-day conference that addresses critical issues facing society as a result of information technology. CPSR filed suit against the FBI in September, after the Bureau failed to make public documents that would justify the need for its new wiretap proposal. The FBI proposal would redesign the telephone network to make wiretapping easier. Recognizing the importance of cryptography policy, CPSR catalyzed a national debate earlier this year, as to whether or not the FBI and National Security Agency (NSA) should be involved in setting the technical standards for the computer and communications industry. The panel discussion will include a screening and discussion of film clips from the movie, Sneakers. Panelists include, Joan Feigenbaum, Technical Staff, Computing Principles Research, ATT Bell Labs, John Gilmore, founder of Cygnus Support, and Dave Banisar, CPSR Policy Analyst. CPSR's annual meeting will bring together computer scientists from across the country to examine the relationship between politics and technology. Other topics include: * Teledemocracy & Citizen Participation: Beyond the Electronic Town Meeting, This session is an election year look at the dangers and the opportunites of electronic democracy. Speaker, Susan G. Hadden, professor in the LBJ School of Public Affairs, University of Texas at Austin, an expert on telecommunications and citizen participation. * Everything's Digital! Media Convergence: Hope, Hype or Hell? This session examines the social implications of multimedia convergence which is the merging of computer, telephone, and video technology. Panel discussion with David Bunnell, Editor, New Media, Denise Caruso, Editor, Digital Media, and Howard Rheingold, Whole Earth Review * Envisioning Technology Policy in a Democratic Society; A panel of technologists looks at the development of American technology policy. Panelists include, Gary Chapman, The 21st Century Project, Judy Stern, CPSR/Berkeley, Claire Zvanski, SEIU Local 790. President of Interval Research, Dave Liddle, will be the keynote speaker at CPSR's awards banquet Saturday evening. Liddle will be speaking on the Computing in the 21st Century. IBM researcher, Barbara Simons will be presented with the 1992 Norbert Wiener Award for Social and Professional Responsibility in Computing. Founded in 1981, CPSR is a national, non-profit, public interest organization of computer scientists and other professionals concerned with the impact of computer technology on society. With offices in Washington, D.C. and Boston, CPSR's members provide the public and policy makers with expert testimony and assessments on the power, promise, and limitations of computer technology. For more information about CPSR call 415-322-3778 or send email to cpsr@csli.stanford.edu. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Fri, 2 Oct 92 00:53:02 PDT To: postmastuh@dawkmastuh.guv Subject: Re: Secure IRC Message-ID: <199210020800.AA21035@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Interesting ideas so far... Hey, anyone see the Quantum Crypto article in October Scientific AMerican? Of course the approach isn't practical at this point, and doing it over fiber optics won't be any better since the amplification along the way would raise the quantum process to the classical level and destroy its value... but even so, interesting as theory... -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Fri, 2 Oct 92 22:26:14 PDT To: cypherpunks@toad.com Subject: Re: Secure IRC Message-ID: <2554.2ACD2FF0@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain U> How about the idea of a secure Internet Relay Chat? I'm fairly interested... version 2 of PGP is generating some interest here in the FidoNet, though it has some serious problems, design problems. (It's "ASCII armor" method (ala UUENCODE) is delicate and fussy, for example). I am considering becoming and "introducer" for parts of FidoNet. I can't seem to get past the problems of how to assign reliability to public keys I receive over an unsecured email channel to begin with. No other method is practical. Alas, I can't take part in much it seems, the UFGATE was hobbled to intentionally prevent us FidoNet people from entering text into message headers (For example "Request-Remailing-To:"...) because we'd take over the planet or something I guess (we are apparently contagious). U> The Server receives it, decrypts it, then for each of the participants U> currently in this particular room, the server encrypts the msg U> with that person's Public Key and sends it. Doesn't this imply that the unencrypted message would have to travel from the originator to the server? Or do you mean to send to X I'd request X's public key from the server, then encrypt, etc? --- Msg V2.8 -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: omega@spica.bu.edu (The Omega) Date: Fri, 2 Oct 92 10:35:43 PDT To: cypherpunks@toad.com Subject: No Subject Message-ID: <9210021743.AA04199@spica.bu.edu> MIME-Version: 1.0 Content-Type: text/plain Hacking ingenuity... =================[ Cut Here ]==================== The /etc/passwd cracker service Have you ever been troubled by those DES encrypted passwords in the /etc/passwd file of your favourite machine ? Worry no more ! What's up ? Utopia now has a unique, probably the first in the world, password-hacking mailserver. This server compares the encrypted string in the /etc/passwd with a 3Mb dictionary, the gecos-field and username. The dictionary consists of +- 50.000 english words, +-50.000 dutch words, sf-authors, girlnames and some other stuff that people tend to use as passwords. The dictionary check is done by the very fast HADES hacking engine. I was surprised by the speed of hades ! The gecos and username scanning is done by the adapted berkeley hacker , this one also appends 0-9 to the end of the guess, and checks upper/lower case and words without vowels. How it works: You need access to some form of uucp/internet mail facilities to use the server. Fidonet-users can use the fido <-> internet gateway, a helpfile for this gateway can be found somewhere on utopia, and on many other systems in cyberspace. send your /etc/passwd to: cracker@utopia.hacktic.nl The cracker will automagically try to guess the passwords in the passwd file, and send you back any results it found to the E-mail adress the file came from. Illegal ? Ofcourse you yourselfe are entirely responsible for your actions, I really don't care what you do with any passwords from any hacked account. I trust you to only use this server for 'educational purposes' :) Read the boiler-plate on Utopia to have deeper insight in any legal-issues. Furthermore you should read the disclaimer that comes with the HADES password hacker. Thanks: Thanks go to Zakbar & Remote for making the HADES hacker, to ITSME for the msdos-berkeley hacker, to Rop for the original idea and to the cockroaches in my house for entertaining me in those early hours. ====================================================================== From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Judith Milhon Date: Sat, 3 Oct 92 18:45:12 PDT To: cypherpunks@toad.com Subject: public vs. private Message-ID: <199210040152.AA17760@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain marc suggests: >>I *am* a little worried about publicizing the whole thing; >>perhaps it's okay to make it a showpiece but >>the real stuff needs to be done in a much more private way. Consider the phage model (which I & my roommate efrem lipkin have been considering for a longish while, since Community Memory) : The bacteriophage virus replicates itself by injecting its own information into an existing system. The more copies of the phage, the worse for the bacteria etc etc. SO: in private, the planning, the designing, the coding... for public distribution as widely as possible. If the technology is intrinsically transformative, and if the process of distribution is engaging, even exciting, the revolution is next tuesday. hughes is hoping that remailers will pop up everywhere, even before the encryption upgrades arrive... heh. And the more designers and coders we rope in, via publicizing, to produce immediate lively replicating phages, the better. Not so? If not so, I'll shut up forthwith. StJude PS: also it mindfucks the idea of conspiracy. hee hee. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Sun, 4 Oct 92 14:46:44 PDT To: pozar@kumr.lns.com Subject: PGP echo conference... Message-ID: <2573.2ACF6745@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain Date: 03 Oct 92 17:22:42 From: Christopher Baker on 374/14 To: Tom Jennings on 125/111 Subj: PUBLIC_KEYS Echo announcement * Forwarded from 1:374/14, Rights On! in Titusville FL * Originally to All in the ECHO_REQ echo. attention all public-key encryption buffs: a new Echo has been started for discussion and distribution of public-key encryption info. since it was only born a couple hours ago, it is being distributed privately from 1:374/14 [9600+ HST/V32] and 1:374/26 [2400]. here are the details from the EListing: area PUBLIC_KEYS title Public-Key Encryption and Distribution Echo desc Provides a technical forum for discussion of public-key desc encryption techniques and programs and for the distribution desc of public-keys in FidoNet and other BBS and e-mail networks. desc PUBLIC_KEYS is Moderated by Christopher Baker at 1:374/14 desc [KeyID: 1024/4B9A59] and GK Pace at 1:374/26 [KeyID: desc 1024/B6B823]. The messages entered into the Echo are the sole desc responsibility of the person entering the messages. When in desc doubt about public-keys, contact the poster directly via Netmail. desc The Echo is open to anyone with an interest in public-key desc encryption issues and methods. The Echo Guidelines are contained desc in PUBKEYS.RUL available in ELRUL???.LZH as of 11/92. mod C.Baker/GK.Pace, 1:374/14 tot 2 vol 10/week dist LOCAL, ZONE1 SEEN 374/14 374/26 PATH 374/14 374/26 -30- here's the info from the .RUL file to be found in ELRUL as of 11/92: This is the PUBLIC_KEYS Echo. The purpose of the Echo is to provide a place to post and find public-keys for data encryption within FidoNet and elsewhere and to discuss data and software encryption and the various schemes thereof. This is a technical Echo with very few rules. Those very few rules are: 1. Stay on-topic. Topics of keys and encryption are welcome. Others are not. 2. No politics [except as it relates to privacy issues] and no religion. 3. No personal attacks, slurs or innuendo. Stick to issues not personalities. 4. No Private flagged messages in Echomail! Encrypted traffic using public-keys is permitted for the exercise so long as it is on-topic. 5. This Echo may be traveling around the world so try to be concise. Avoid excessive quoting for one-liner responses. 6. Be aware that Echomail is NOT secure. Don't take anything at face value. 7. The posts in this Echo are the sole responsiblity of the poster. If you need verification, use Netmail. 8. The Moderators will deal with off-topic traffic. Don't respond for them. Links to this Echo will only be curtailed when absolutely necessary so please don't make it necessary. [grin] The Moderators are Christopher Baker [KeyID: 1024/4B9A59 1992/10/03] and GK Pace [KeyID: 1024/B6B823 1992/09/28] at 1:374/14 and 1:374/26, respectively. It is recommended that public-keys be made available via Netmail or by file-request with the magic filename: PGPKEY and that the public-key provided for that request by given a distinctive filename using part or all of each provider's name and address. For example, on my system, a file-request of PGPKEY will give BAK37414.ASC to the requesting system. This will avoid duplicate overwriting and make it easier to track the keys. Using a standard magic filename will make it easier to find keys on different systems. This Echo is not currently on the Zone 1 Backbone distribution list but that is expected to change as soon as the word gets out. This Echo will be EListed in ELIST211 next month. Please feel free to announce and distribute this Echo to all interested participants in your area. Thanks. TTFN. Christopher Baker & GK Pace Moderators -30- any questions? anyone with Areafix already set for this system or for 1:374/26 may link in remotely. all others need to send a Netmail request. the Echo will be distributed privately until it is large enough for moving to the Zone 1 Backbone [or any other Backbones who want to get into it]. thanks. TTFN. Chris & GK * Origin: Rights On! - Announcing ANOTHER Echo? - Titusville_FL (1:374/14) * Forwarded by Christopher Baker on 1:374/14, Rights On! in Titusville FL -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Secret_Squirrel@Treehouse.ORG Date: Sat, 3 Oct 92 22:38:36 PDT To: cypherpunks@toad.com Subject: Nuts & Acorns Message-ID: <9210040546.AA10254@atdt.org> MIME-Version: 1.0 Content-Type: text/plain To: Tom Jennings >> Doesn't this imply that the unencrypted message would have to travel from the originator to the server? Or do you mean to send to X I'd request X's public key from the server, then encrypt, etc? << Not at all. In its simplest form: We'd have a single secure-IRC-server. It would have its own public key, which ever secure-IRC-client would know. When I want to send a secure broadcast msg, I type it, my client encrypts it with the public key of the secure-IRC-server, and transmits it. The server picks it up, decrypts it in memory, then re-encrypts that original msg with the public key of each paritxxx participant in the particular room I'm in. So, if there are ten participants in the room, and I want all of them to know something, but not anyone else who might be tapping ixxx wires or catching packets somewhere in the ether, then I'd send a single broadcast msg to the server; the server would end up sending ten differently encrypted msgs -- one to each participant, encrypted with each of the participants' public keys (which the secure-irc-server would have to maintain; it would function as a key-server.) To send a private msg across the secure-IRC, I'd indicate that it was a "/msg", the recipeixxx recipient, and again, encrypt it with the public key of the server. The server would learn who the recipient was, and rebroadcast my message to that person, in that person's public key. >> I am considering becoming and "introducer" for parts of FidoNet. I can't seem to get past the problems of how to assign reliability to public keys I receive over an unsecured email channel to begin with. No other method is practical. << Huh? I don't understand what you're pointing out. If I send you my public key -- even if I cc: dockmaster -- what does it matter that the NSA knows my public key (unoless they want to send me msgs, too)? The key itself is inherantly secure. Let your users decide on their public keys and register those keys with your key server. Not the other way around. Course, there's always the Kandinsky-Ogorov method of key exchange. To: St. Jude >> The bacteriophage virus replicates itself by injecting its own information into an existing system. The more copies of the phage, the worse for the bacteria etc etc. SO: in private, the planning, the designing, the coding... for public distribution as widely as possible. If the technology is intrinsically transformative, and if the process of distribution is engaging, even exciting, the revolution is next tuesday. << Providing the numbe r of cells you have access to and can anticipate influencyxxx incxxx influencing is large enough, and it isn't. Anyway, look, let's put our words into action. What makes code (programming, I mean) didxxx different from spoken language? The fact that you can communicate with a machine, and it will _act_ on what you say, no matter what. Theres beauty and there's magic in that. (And some of us have the same effect on people that we have on machines. ;-)) Instead of talking about all this, let's start doing it. What did I read the other day? "Hackers go where Angels fear to tread"? Let's have more ideas. This hopping remailer is exciting. So is passive encryption of electronic communications. When are we going totart xxx to start effecting de facto standards here? Once we start encrypting everything, then what? What do we do with this new tool? Communication of any kind (especially encrypted communication) presupposs that there are messages to be exchanged -- _ideas_! More ideas and less chatter. How can we have a revolution if we don't even know what we're trying to bring about? Maybe I was out of the loop. Maybe I was attending an Army/Navy game that day, but I don't know what we're trying to do here, exactly. What is this "revolution"? -- $33kr1t $kwurl. K.R.A.P. (K-Rad. A.SCII P.Ossee) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Sun, 4 Oct 92 18:59:32 PDT To: cypherpunks@toad.com Subject: Secure IRC In-Reply-To: <9210012143.AA00610@atdt.org> Message-ID: <9210050206.AA20902@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain The problem with central servers is that they are prone to single point failure. That failure may be computer down or key compromise. A good criterion for this kind of design is not to use central servers. This is almost always possible. (Or always possible, depending on who you ask.) There is also the question about getting permission to enter a room, which corresponds to an authentication or a key distribution or a voting algorithm or some sort. You need to know how you want that _social_ interaction to work before you design protocols. You should implement that sociality and test it without encryption to make sure it's what you want. Is this sounding familiar? Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Sun, 4 Oct 92 19:15:03 PDT To: cypherpunks@toad.com Subject: introducing public keys In-Reply-To: <2554.2ACD2FF0@fidogate.FIDONET.ORG> Message-ID: <9210050222.AA21567@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain >I am considering becoming and "introducer" for parts of FidoNet. I >can't seem to get past the problems of how to assign reliability to >public keys I receive over an unsecured email channel to begin with. >No other method is practical. Building a key distribution system takes time. Start off by having people mail you diskettes. Or if you don't mind typing, printouts. Carry copies of your public key to give to people in person. Get good security is not free, especially in terms of time. If you can personally receive via out-of-band channels the public key of another introducer, you can exchange all the certified keys you each possess. And then exchange those with another introducer you know. Introducers are not a special breed. Most people should certify others public keys, if only for redundancy. Remember, no one has ever set up a non-hierarchical public key distribution system to the general public. This is research. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Sun, 4 Oct 92 19:17:52 PDT To: cypherpunks@toad.com Subject: Mail headers In-Reply-To: <2554.2ACD2FF0@fidogate.FIDONET.ORG> Message-ID: <9210050225.AB21620@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain >Alas, I can't take part in much it seems, the UFGATE was hobbled to >intentionally prevent us FidoNet people from entering text into >message headers (For example "Request-Remailing-To:"...) because we'd >take over the planet or something I guess (we are apparently >contagious). You aren't the only one Tom. Apparently lots of Unix mail interfaces don't let you arbitrarily edit the header or add lines. I'm going to add a facility to make this possible for everyone. The design I have in mind uses only the message body. No need to touch the header. Announcements when it's finished. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Sun, 4 Oct 92 19:51:17 PDT To: cypherpunks@toad.com Subject: introducers In-Reply-To: <9210040546.AA10254@atdt.org> Message-ID: <9210050258.AA22363@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain >If I send you my public key -- even if I cc: dockmaster -- what does >it matter that the NSA knows my public key (unoless they want to send >me msgs, too)? The key itself is inherantly secure. Let your users >decide on their public keys and register those keys with your key >server. Not the other way around. Let's make this short. The basic problem with public key systems is to make sure that what _I_ think is my public key is the same thing as what _you_ think is my public key. If these are not the same, something is wrong. At worst, an interposer is getting all your mail, decrypting with one public key and encrypting with a different one. Servers, generally, are not desirable because they are too prone to communications filters of the above sort. For a more detailed reference, read the excellent introduction to the whole topic of public key distribution in the PGP 2.0 documentation. >Course, there's always the Kandinsky-Ogorov method of key exchange. Please elaborate. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Mon, 5 Oct 92 00:14:29 PDT To: cypherpunks@toad.com Subject: A statement of purpose Message-ID: <9210050721.AA01865@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain I've had a bunch of people ask me about the group and what it's up to. Accordingly, I drafted a small statement of purpose to send to folks. Please comment. Eric ---------------------- The cypherpunks list is a forum for discussion about technological defenses for privacy in the digital domain. Cypherpunks assume privacy is a good thing and wish there were more of it. Cypherpunks acknowledge that those who want privacy must create it for themselves and not expect governments, corporations, or other large, faceless organizations to grant them privacy out of beneficence. Cypherpunks know that people have been creating their own privacy for centuries with whispers, envelopes, closed doors, and couriers. Cypherpunks do not seek to prevent other people from speaking about their experiences or their opinions. The most important means to the defense of privacy is encryption. To encrypt is to indicate the desire for privacy. But to encrypt with weak cryptography is to indicate not too much desire for privacy. Cypherpunks hope that all people desiring privacy will learn how best to defend it. Cypherpunks are therefore devoted to cryptography. Cypherpunks wish to learn about it, to teach it, to implement it, and to make more of it. Cypherpunks know that cryptographic protocols make social structures. Cypherpunks know how to attack a system and how to defend it. Cypherpunks know just how hard it is to make good cryptosystems. Cypherpunks love to practice. They love to play with public key cryptography. They love to play with anonymous and pseudonymous mail forwarding and delivery. They love to play with DC-nets. They love to play with secure communications of all kinds. Cypherpunks write code. They know that someone has to write code to defend privacy, and since it's their privacy, their going to write it. Cypherpunks publish their code so that their fellow cypherpunks may practice and play with it. Cypherpunks realize that security is not built in a day and are patient with incremental progress. Cypherpunks don't care if you don't like the software they write. Cypherpunks know that software can't be destroyed. Cypherpunks know that a widely dispersed system can't be shut down. Cypherpunks will make the networks safe for privacy. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Mon, 5 Oct 92 01:23:23 PDT To: cypherpunks@toad.com Subject: Meeting Sat. Oct. 10, noon, Mt. View Message-ID: <9210050830.AA03692@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain ANNOUNCEMENT ============ Second Meeting Saturday, October 10, 1992 12:00 noon - 6:00 p.m. Cygnus Support offices 1937 Landings Drive Mountain View The second meeting of the cypherpunks will be Saturday at noon. John Gilmore has graciously provided us with a meeting space at the new Cygnus Support offices. These offices are so new, in fact, that Cygnus will not have moved in yet. This meeting will be bring-your-own-pillow (or chair), since it will be held in largely empty space. Directions are at the end of the message. Attendance is transitive trust, arbitrarily deep. Invite whoever you want, and let them do so also, and so on. Invite them also to join the mailing list. Do not, however, just post the announcement. Time for that will come. I'd like everyone who plans on attending the meeting to send me, hughes@soda.berkeley.edu, a message telling me so. I'd like to get a rough head count before Saturday for game planning. We are starting at noon because of popular demand. Eat beforehand or bring a burrito or something. It will be fine to eat during the first segment; it won't be any more disruptive than the game is. Bring your PGP public key for in-person key distribution, preferably on diskette. We'll need a portable PC or three to do key distribution; if you have one you can bring, post to the list and tell people. We realized after the first meeting that a strict schedule was nonsense. This meeting has a very informal schedule. Schedule -------- Starting at noon, we're going to play session two of the crypto-anarchy game, in which players try to conduct business under the watchful eyes of others. We want to play for two hours and then have discuss experiences afterward for about an hour. Some of the improvements over last time will be flatter denominations of money, wider distribution of commodities, more watchers (governmental and otherwise), and perhaps some pre-printed forms. We'll take a break to regroup for about ten or twenty minutes. For the second half we'll talk about the security of remailers. I'll lead the discussion. We'll be designing protocols and analyzing attacks and defenses. I've done this with DigiCash for electronic money protocols, and remailers are much easier, but still probably more than an afternoon's discussion. We'll do this until six or so, when people will have to start leaving. Everyone who wants to will go out for dinner. I don't know the restaurants down there; perhaps someone could suggest one? Directions ---------- It's at 1937 Landings Drive, Mt. View. 101 to Amphitheatre Parkway (the bay side of Rengstorff Ave), go right at the first light, pass a right turn, and just before the road crests a tiny hill, turn right into the Landings complex. We're in Building H. -- Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: "Fen Labalme" Date: Mon, 5 Oct 92 12:39:37 PDT To: "Eric Hughes" Subject: Re: A statement of purpose Message-ID: <9210051947.AA29863@relay1.UU.NET> MIME-Version: 1.0 Content-Type: text/plain Subject: RE>A statement of purpose I am way excited to see this all coming together! It's like a 13-year- old dream-come-true! This is a great statement of purpose, though I might leave "DC-nets" out (since many won't know what that means) and perhaps replace it with the only slightly-less-cryptic "information-theoretically-secure networks", or some such. $0.02 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: "Fen Labalme" Date: Mon, 5 Oct 92 14:13:51 PDT To: "Cypher Punks" Subject: SEIZING THE MEDIA Message-ID: <9210052121.AA03803@relay2.UU.NET> MIME-Version: 1.0 Content-Type: text/plain Subject: SEIZING THE MEDIA [ this is a resend I originally sent this to cypherpunks@toad.com on 28 Sep, but I haven't seen it yet, so apologies up front if you see it twice... Fen ~~~ ] FYI... from PeaceNet ACTIV-L: Date: Sat, 26 Sep 1992 23:33:10 CDT Sender: Activists Mailing List >From: "(Rich Winkel)" Subject: PAX: SEIZING THE MEDIA: A NETWORKER CONGRESS To: Multiple recipients of ACTIV-L /** gen.media: 141.0 **/ ** Topic: SEIZING THE MEDIA: NETWORKER CONGR ** ** Written 6:39 pm Sep 25, 1992 by openmedia in cdp:gen.media ** SEIZING THE MEDIA: A NETWORKER CONGRESS A weekend of activity to discuss, self-educate, and put into practice the creation of subversive media. 1:30pm Saturday 24 October to 6pm Sunday 25 October 1992 Media and resource exchange; slides, fax, posters, pamphlets, computer files, ideas, proposals, tactics Practical action on billboard improvement and removal; Big Art and postering E-mail and fax facility to receive material to be discussed and implemented during the weekend Documentation to all participants Materials supplied: photocopier reproduction/enlargement and the streets of Oxford Bloomin Arts, Princes Street, Cowley Road, Oxford, OX4, U.K. If you can't make it in person, you can take part in the Seizing the Media Congress by post, fax, E-mail. Send documents, comments, proposals, art, ideas, and posters. Post to: BM Jed, London WC1N 3XX, United Kingdom Fax to: (011 441) 0865 72 4317 E-Mail to: Eastoxcomcen@GN.APC.ORG Accommodation and other information are available from Friday night onwards. To make arrangements or get more information, get in touch with Oxfin between 1-4pm Mondays to Fridays at: (0865) 240545 >From the United States: 011 41865 240 545 Background: SEIZING THE MEDIA is the title of pamphlet written by the Immediast Underground and first released in Amsterdam , New York City, and Seattle in early 1992. The 26 pamphlet combines theory, graphics, research and proposals that examine: * Information control * Propaganda and advertising * CIA * Mind control * Immediast counter-offensives * tactics, subversive networking, public empowerment * multi-media * Public production libraries * the liberation of public space ...Just when Jesse Helms thought he made the world safe from poetic terrorism, along come the Immediasts, a cadre of media hackers who are fed up with the ecology of coercion that surrounds them. Their booklet SEIZING THE MEDIA proposes an all-out artistic assault on coercive communication, cultural monologue, and media control. They want all media insurgents to take back the airwaves with pirate radio, cable access TV, altering ads and billboards, and otherwise hacking the datasphere to break the spell of State/corporate media control. . . . from Gareth Branwyns STREET NOISE, Issue 7 of Mondo 2000 SEIZING THE MEDIA Version 1.1 is available for $3 from Open Media PO Box 2726 Westfield New Jersey 07091 USA THE IMMEDIAST UNDERGROUND is a centerless network of artists, writiers, hackers, culture jammers, pirate broadcasters, and posterists who connect with one another through information systems, mail art, networker congresses, and the underground press, and who communicate with the public through actions against all forms of coercive communication, space infringement, and media control. For more info contact: Immediast U. PO Box 2726 Westfield New Jersey 07091 USA DECENTRALIZED WORLD-WIDE NETWORKER CONGRESSES Since the beginning of the year, members of alternative info-nets, artists, insurgents, and cultural workers have been holding networker congresses, transnational engagements in cultural production, dialogue, collaborations, open exchange, subversive brainstorming, and collective disruptions of dominant culture. THE NETWORKER, A NEW PERCEPTION In societies where information is money and media is power, public access is as controlled as the corporate states grip on communication law, censorship, commerce, covert action and surveillance. In this context, uninhibited public communication, expression, and cultural production are acts of freedom, sovereignty, and defiance. Rooted in the drive to connect and exchange with others, Networker Congress engage in culture and media as the battleground for greater openness and freedom. MORE INFORMATION about NETWORKER CONGRESSES contact: H.R. Fricker Buro fur kunsterische Umtriebe CH 9043 Trogen Switzerland Retrofuturism PO Box 2278 Iowa City, Iowa 52244 Face of the Congress FaGaGaGa Po Box 1382 Youngstown, Ohio 44501 Peter Kaufman Bergenwissenstrasse 11 CH-8123 EbmatigenDecentralized Networker Congresses Switzerland Decentralized Networker Congresses Netshaker PO Box 978 Hanover, New Hampshire 03766 ** End of text from cdp:gen.media ** From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Secret_Squirrel@Treehouse.COM Date: Mon, 5 Oct 92 21:40:53 PDT To: cypherpunks@toad.com Subject: List Message-ID: <9210060448.AA02547@atdt.org> MIME-Version: 1.0 Content-Type: text/plain comp-privacy@pica.army.mil I am the moderator of the Computer Privacy Digest. The computer Privacy Digest is an Internet mailing list that is dedicated to the discussion of how technology impacts privacy. This list is gatewayed into the moderated USENET newsgroup comp.society.privacy. In lot of ways it is a subsection on the risks digest but it concentrates on the risks of technology on privacy. The charter is: comp.society.privacy Effects of technology on privacy (Moderated) This newsgroup is to provide a forum for discussion on the effect of technology on privacy. All too often technology is way ahead of the law and society as it presents us with new devices and applications. Technology can enhance and detract from privacy. This newsgroup will be gatewayed to an internet mailing list. Submissions go to: comp-privacy@pica.army.mil and administrative requests go to comp-privacy-request@pica.army.mil. Moderator: Dennis G. Rears MILNET: drears@pica.army.mil UUCP: ...!uunet!cor5.pica.army.mil!drears INTERNET: drears@pilot.njin.net USPS: Box 210, Wharton, NJ 07885 Phone(home): 201.927.8757 Phone(work): 201.724.2683/(DSN) 880.2683 USPS: SMCAR-FSS-E, Bldg 94, Picatinny Ars, NJ 07806 ----------------------[ Cut Here ]------------------ I , Secret Squirrel, am merely cross-posting the above. I have nothing to do with it, and am in now xxx no way connected with comp-privacy. Just thought it might interest someone here. Quakka! From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Tue, 6 Oct 92 15:11:44 PDT To: cypherpunks@toad.com Subject: re: Nuts & Acorns Message-ID: <2654.2AD20C59@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain > To: Tom Jennings tj>> I am considering becoming and "introducer" for parts of FidoNet. I can't seem to get past the problems of how to assign reliability to public keys I receive over an unsecured email channel to begin with. No other method is practical. << >>?? Huh? I don't understand what you're pointing out. If I send you my public key -- even if I cc: dockmaster -- what does it matter that the NSA knows my public key (unoless they want to send me msgs, too)? << Not my worry. What I meant was, how do I know htat the keyfile I received from "John Smith @ net address" really is his, and not some faker. Short of physically getting key disks from someone face to face (flatly im-possible here), I don't know. The assurance of course is the social system: if someone sends me a message and keyfile, "here's my file, my name is Eric Hughes", and I distribute it... I can think of no way to prevent this, other than let a social system detect and repair -- "HEY THATS NOT ME!!!" form the 'real' you would raise a flag... and an audit trail at the introducers site (dangerous...!) might help. Anyhoo, that's what I meant. --- RM version 0.-1 (watch out) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: "Fen Labalme" Date: Tue, 6 Oct 92 18:15:28 PDT To: "Cypher Punks" Subject: crypto bibliography Message-ID: <9210070123.AA01922@relay2.UU.NET> MIME-Version: 1.0 Content-Type: text/plain Subject: crypto bibliography By anonymous ftp from rsa.com: Fen ~~~ @inproceedings{agnew, author = "Agnew, G.B. and Mullin, R.C. and Vanstone, S.A.", year = 1988, title = "A secure public key protocol based on discrete exponentiation", booktitle = "Advances in Cryptology --- Eurocrypt '88", publisher = "Springer-Verlag", address = "Berlin"} @book{bamford, author = "Bamford, J.", year = 1982, title = "The Puzzle Palace", publisher = "Houghton Mifflin", address = "Boston"} @article{barlow, author = "Barlow, J.P.", year = 1992, month = "July", title = "Decrypting the puzzle palace", journal = "Communications of the ACM", volume = 35, number = 7, pages = "25--31"} @article{beauchemin, author = "Beauchemin, P. and Brassard, G. and Crepeau, C. and Goutier, C. and Pomerance, C.", year = 1988, title = "The generation of random numbers that are probably prime", journal = "J. of Cryptology", volume = 1, pages = "53--64"} @inproceedings{berson, author = "Berson, T.A.", year = 1992, title = "Differential cryptanalysis mod $2^{32}$ with applications to {MD5}", booktitle = "Advances in Cryptology --- Eurocrypt '92", publisher = "Springer-Verlag", address = "Berlin", note = "To appear"} @inproceedings{biham-feal, author = "Biham, E. and Shamir, A.", year = 1991, title = "Differential cryptanalysis of {F}eal and {N}-hash", booktitle = "Advances in Cryptology --- Eurocrypt '91", publisher = "Springer-Verlag", address = "Berlin"} @inproceedings{biham-full-des, author = "Biham, E. and Shamir, A.", year = 1993, title = "Differential cryptanalysis of the full 16-round {DES}", booktitle = "Advances in Cryptology --- Crypto '92", publisher = "Springer-Verlag", address = "New York", note = "To appear"} @article{bishop, author = "Bishop, M.", year = 1991, title = "Privacy-enhanced electronic mail", journal = "Internetworking: Research and Experience", volume = 2, pages = "199--233"} @inproceedings{blum-g, author = "Blum, M. and Goldwasser, S.", year = 1985, title = "An efficient probabilistic public-key encryption scheme which hides all partial information", booktitle = "Advances in Cryptology --- Crypto '84", pages = "289--299", publisher = "Springer-Verlag", address = "New York"} @inproceedings{brandt, author = "Brandt, J. and Damgard, I.", year = 1993, title = "On generation of probable primes by incremental search", booktitle = "Advances in Cryptology --- Crypto '92", publisher = "Springer-Verlag", address = "New York", note = "To appear"} @book{brassard, author = "Brassard, G.", year = 1988, title = "Modern Cryptology", publisher = "Springer-Verlag"} @book{bressoud, author = "Bressoud, D.M.", year = 1989, title = "Factorization and Primality Testing", publisher = "Springer-Verlag", address = "New York"} @article{brickell-survey, author = "Brickell, E.F. and Odlyzko, A.M.", year = 1988, title = "Cryptanalysis: {A} survey of recent results", journal = "Proceedings of the IEEE", volume = 76, pages = "578--593"} @inproceedings{brickell-rsa-hardware, author = "Brickell, E.F.", year = 1989, title = "A survey of hardware implementations of {RSA}", booktitle = "Advances in Cryptology --- Crypto '89", publisher = "Springer-Verlag", address = "New York", pages = "368--370"} @unpublished{buhler, author = "Buhler, J.P. and Lenstra, H.W. and Pomerance, C.", year = 1992, title = "Factoring integers with the number field sieve", note = "To appear"} @article{burmester, author = "Burmester, M.V.D. and Desmedt, Y.G. and Beth, T.", year = 1992, title = "Efficient zero-knowledge identification schemes for smart cards", journal = "Computer Journal", volume = 35, pages = "21--29"} @inproceedings{campbell, author = "Campbell, K.W. and Wiener, M.J.", year = 1993, title = "Proof that {DES} is not a group", booktitle = "Advances in Cryptology --- Crypto '92", publisher = "Springer-Verlag", address = "New York", note = "To appear"} @article{canfield, author = {Canfield, E.R. and Erd\"{o}s, P. and Pomerance, C.}, year = 1983, title = "On a problem of Oppenheim concerning `Factorisatio Numerorum'", journal = "J. Number Theory", volume = 17, pages = "1--28"} @manual{X.509, author = "{CCITT (Consultative Committee in International Telegraphy and Telephony)}", year = 1988, title = "Recommendation X.509: The Directory---Authentication Framework"} @manual{etebac, author = "{Comit\'{e} Fran\c{c}ais d'Organisation et de Normalisation Bancaire}", year = 1989, title = "Echanges T\'{e}l\'ematiques entre les Banques et leurs Clients, Standard ETEBAC 5, v1.1", address = "Paris"} @manual{gao-edi, author = "{Comptroller General of the United States}", year = 1991, month = "December 13,", title = "Matter of {National Institute of Standards and Technology} --- {Use} of Electronic Data Interchange Technology to Create Valid Obligations", note = "File B-245714"} @article{coppersmith-o-s, author = "Coppersmith, D. and Odlyzko, A.M. and Schroeppel, R.", year = 1986, title = "Discrete logarithms in {GF(p)}", journal = "Algorithmica", volume = 1, pages = "1--15"} @article{coppersmith, author = "Coppersmith, D.", year = 1987, title = "Cryptography", journal = "IBM J. Res. Develop.", volume = 31, number = 2, month = "March", pages = "244--248"} @techreport{improving-security-UNIX, author = "Curry, David A.", year = 1990, title = "Improving the Security of Your {UNIX} System", institution = "{SRI} International", number = "ITSTD-721-FR-90-21", address = "Menlo Park, CA", month = "April"} @techreport{davida, author = "Davida, G.", year = 1982, title = "Chosen signature cryptanalysis of the RSA public key cryptosystem", number = "TR-CS-82-2", institution = "Dept of EECS, University of Wisconsin, Milwaukee"} @book{davies-and-price, author = "Davies, D.W. and W.L. Price", year = 1984, title = "Security for Computer Networks: {An} Introduction to Data Security in Teleprocessing and Electronic Funds Transfer", publisher = "John Wiley \& Sons", address = "New York"} @manual{green-book, author = "{Department of Defense}", title = "{CSC-STD-002-85}: Department of Defense ({DoD}) Password Management Guidelines", year = 1985} @manual{orange-book, author = "{Department of Defense}", title = "{DoD 5200.28-STD}: Department of Defense ({DoD}) Trusted Computer System Evaluation Criteria ({TCSEC})", year = 1985} @article{diffie-hellman, author = "Diffie, W. and Hellman, M.E.", year = 1976, title = "New directions in cryptography", journal = "IEEE Transactions on Information Theory", volume = "IT-22", pages = "644--654"} @article{diffie-hellman-des, author = "Diffie, W. and Hellman, M.E.", year = 1977, title = "Exhaustive cryptanalysis of the {NBS Data Encryption Standard}", journal = "Computer", volume = 10, pages = "74--84"} @article{Diffie-Hellman-Intro, author = "Diffie, W. and M.E. Hellman", year = 1979, month = "March", title = "Privacy and authentication: {An} introduction to cryptography", journal = "Proceedings of the IEEE", volume = 67, number = 3, pages = "397--427"} @article{diffie-10yrs, author = "Diffie, W.", year = 1988, title = "The first ten years of public-key cryptography", journal = "Proceedings of the IEEE", volume = 76, pages = "560--577"} @article{elgamal, author = "ElGamal, T.", year = 1985, title = "A public-key cryptosystem and a signature scheme based on discrete logarithms", journal = "IEEE Transactions on Information Theory", volume = "IT-31", pages = "469--472"} @inproceedings{fiat, author = "Fiat, A. and Shamir, A.", year = 1987, title = "How to prove yourself: {Practical} solutions to identification and signature problems", booktitle = "Advances in Cryptology --- Crypto '86", pages = "186--194", publisher = "Springer-Verlag", address = "New York"} @article{goldwasser, author = "Goldwasser, S. and Micali, S.", year = 1984, title = "Probabilistic encryption", journal = "J. of Computer and System Sciences", volume = 28, pages = "270--299"} @inproceedings{gordon, author = "Gordon, D.M. and McCurley, K.S.", year = 1993, title = "Massively parallel computation of discrete logarithms", booktitle = "Advances in Cryptology --- Crypto '92", publisher = "Springer-Verlag", address = "New York", note = "To appear"} @inproceedings{haber, author = "Haber, S. and Stornetta, W.S.", year = 1991, title = "How to time-stamp a digital document", booktitle = "Advances in Cryptology --- Crypto '90", publisher = "Springer-Verlag", address = "New York", pages = "437--455"} @article{hastad, author = "Hastad, J.", year = 1988, title = "Solving simultaneous modular equations of low degree", journal = "SIAM J. Computing", volume = 17, pages = "336--241"} @article{hellman, author = "Hellman, M.E.", year = 1980, title = "A cryptanalytic time-memory trade off", journal = "IEEE Transactions on Information Theory", volume = "IT-26", pages = "401--406"} @manual{iso9796, author = "{International Standards Organization}", title = "IS 9796: Information technology, security techniques: digital signature scheme giving message recovery", address = "Geneva, Switzerland"} @book{kahn, author = "Kahn, D.", year = 1967, title = "The Codebreakers", publisher = "Macmillan Co.", address = "New York"} @article{kaliski, author = "Kaliski Jr., B.S. and Rivest, R.L. and Sherman, A.T.", year = 1988, title = "Is the Data Encryption Standard a group?", journal = "J. of Cryptology", volume = 1, pages = "3--36"} @article{Kaliski-one-way-permutations, author = "{Kaliski Jr.}, Burton S.", year = 1991, title = "One-Way Permutations on Elliptic Curves", journal = "Journal of Cryptology", volume = 3, pages = "187--199"} @manual{MD2, author = "Kaliski, B.", year = 1992, month = "April", title = "RFC 1319: The {MD2 Message-Digest Algorithm}", organization = "Internet Activities Board"} @manual{rfc1114, author = "Kent, S. and J. Linn", year = 1989, month = "August", title = "RFC 1114: Privacy Enhancement for Internet Electronic Mail: Part {II} -- Certificate-Based Key Management", organization = "Internet Activities Board"} @book{knuth, author = "Knuth, D.E.", year = 1981, title = "The Art of Computer Programming", edition = "2nd", volume = 2, publisher = "Addison-Wesley", address = "Reading, Mass."} @article{koblitz-ecc, author = "Koblitz, N.", year = 1987, title = "Elliptic curve cryptosystems", journal = "Mathematics of Computation", volume = 48, pages = "203--209"} @book{koblitz, author = "Koblitz, N.", year = 1987, title = "A Course in Number Theory and Cryptography", publisher = "Springer-Verlag", address = "New York"} @inproceedings{lai, author = "Lai, X. and Massey, J.L.", year = 1991, title = "A proposal for a new block encryption standard", booktitle = "Advances in Cryptology --- Eurocrypt '90", pages = "389--404", publisher = "Springer-Verlag", address = "Berlin"} @article{lamacchia, author = "LaMacchia, B.A. and Odlyzko, A.M.", year = 1991, title = "Computation of discrete logarithms in prime fields", journal = "Designs, Codes and Cryptography", volume = 1, pages = "47--62"} @article{landau, author = "Landau, S.", year = 1988, title = "Zero knowledge and the {Department of Defense}", journal = "Notices of the American Mathematical Society", volume = 35, pages = "5--12"} @article{lenstra-ecm, author = "Lenstra Jr., H.W.", year = 1987, title = "Factoring integers with elliptic curves", journal = "Ann. of Math.", volume = 126, pages = "649--673"} @incollection{lenstra-survey, author = "Lenstra, A.K. and Lenstra Jr., H.W.", year = 1990, title = "Algorithms in number theory", editor = "van Leeuwen, J.", booktitle = "Handbook of Theoretical Computer Science", volume = "A", publisher = "MIT Press/Elsevier", address = "Amsterdam"} @inproceedings{lenstra-nsf, author = "Lenstra, A.K. and Lenstra Jr., H.W. and Mannasse, M.S. and Pollard, J.M.", year = 1990, title = "The number field sieve", booktitle = "Proc. of the 22nd Annual ACM Symposium on the Theory of Computing", publisher = "ACM Press"} @inproceedings{lenstra-ppmpqs, author = "Lenstra, A.K. and Manasse, M.S.", year = 1991, title = "Factoring with two large primes", booktitle = "Advances in Cryptology --- Eurocrypt '90", pages = "72--82", publisher = "Springer-Verlag", address = "Berlin"} @manual{RFC-1113, author = "Linn, J.", year = 1989, month = "August", title = "RFC 1113: Privacy Enhancement for Internet Electronic Mail: Part {I} -- Message Encipherment and Authentication Procedures", organization = "Internet Activities Board"} @manual{RFC-1115, author = "Linn, J.", year = 1989, month = "August", title = "RFC 1115: Privacy Enhancement for Internet Electronic Mail: Part {III} -- Algorithms, Modes and Identifiers", organization = "Internet Activities Board"} @article{merkle-hellman, author = "Merkle, R.C. and Hellman, M.E.", year = 1978, title = "Hiding information and signatures in trapdoor knapsacks", journal = "IEEE Transactions on Information Theory", volume = "IT-24", pages = "525--530"} @article{merkle-hellman-multiple, author = "Merkle, R.C. and Hellman, M.E.", year = 1981, title = "On the security of multiple encryption", journal = "Communications of the ACM", volume = 24, pages = "465--467", month = "July"} @article{messmer, author = "Messmer, E.", year = 1992, title = "{NIST} stumbles on proposal for public-key encryption", journal = "Network World", volume = 9, number = 30, month = "July 27,"} @inproceedings{miller, author = "Miller, V.S.", year = 1986, title = "Use of elliptic curves in cryptography", booktitle = "Advances in Cryptology --- Crypto '85", pages = "417--426", publisher = "Springer-Verlag", address = "New York"} @manual{des-77, author = "{National Bureau of Standards}", year = 1977, month = "January", title = "FIPS Publication 46: Announcing the Data Encryption Standard"} @manual{des-modes, author = "{National Bureau of Standards}", year = 1980, title = "FIPS Publication 81: {DES} Modes of Operation", month = "December"} @manual{des-88, author = "{National Bureau of Standards}", year = 1988, month = "January", title = "FIPS Publication 46-1: Data Encryption Standard"} @manual{nist-dss, author = "{National Institute of Standards and Technology (NIST)}", year = 1992, title = "Publication {XX}: Announcement and Specifications for a Digital Signature Standard (DSS)", month = "August 19,"} @manual{nist-shs, author = "{National Institute of Standards and Technology (NIST)}", year = 1992, title = "Publication {YY}: Announcement and Specifications for a {Secure Hash Standard} (SHS)", month = "January 22,"} @article{dss-discuss, author = "{National Institute of Standards and Technology (NIST)}", year = 1992, title = "The {Digital Signature Standard}, proposal and discussion", journal = "Communications of the ACM", volume = 35, number = 7, pages = "36--54", month = "July"} @book{computers-at-risk, author = "National Research Council, System Security Study Committee and others", year = 1991, title = "Computers at Risk: {Safe} Computing in the Electronic Age", publisher = "National Academy Press", address = "Washington, DC"} @inproceedings{odlyzko, author = "Odlyzko, A.M.", year = 1984, title = "Discrete logarithms in finite fields and their cryptographic significance", booktitle = "Advances in Cryptology --- Eurocrypt '84", pages = "224--314", publisher = "Springer-Verlag", address = "Berlin"} @manual{oiw, author = "{OSI Implementors' Workshop}", year = 1992, title = "Draft Working Implementation Agreements For Open Systems Interconnection Protocols", publisher = "NIST", address = "Gaithersburg, Maryland", month = "June"} @article{pohlig-hellman-dlog, author = "Pohlig, S.C. and Hellman, M.E.", year = 1978, title = "An improved algorithm for computing logarithms over $GF(p)$ and its cryptographic significance", journal = "IEEE Transactions on Information Theory", volume = "IT-24", pages = "106--110"} @article{pollard1, author = "Pollard, J.", year = 1974, title = "Theorems of factorization and primality testing", journal = "Proc. Cambridge Philos. Soc.", volume = 76, pages = "521--528"} @article{pollard2, author = "Pollard, J.", year = 1975, title = "{Monte Carlo} method for factorization", journal = "BIT", volume = 15, pages = "331--334"} @techreport{rabin, author = "Rabin, M.O.", year = 1979, title = "Digitalized signatures as intractable as factorization", institution = "MIT", number = "MIT/LCS/TR-212"} @article{rsa, author = "Rivest, R.L. and A. Shamir and L. Adleman", year = 1978, month = "February", title = "A method for obtaining digital signatures and public-key cryptosystems", journal = "Communications of the ACM", volume = 21, number = 2, pages = "120--126"} @inproceedings{rivest-md4, author = "Rivest, R.L", year = 1991, title = "The {MD4} message digest algorithm", booktitle = "Advances in Cryptology --- Crypto '90", pages = "303--311", publisher = "Springer-Verlag", address = "New York"} @inproceedings{rivest-prob-prime, author = "Rivest, R.L.", year = 1990, title = "Finding four million random primes", booktitle = "Advances in Cryptology --- Crypto '90", pages = "625--626", publisher = "Springer-Verlag", address = "New York"} @incollection{rivest-survey, author = "Rivest, R.L.", year = 1990, title = "Cryptography", editor = "van Leeuwen, J.", booktitle = "Handbook of Theoretical Computer Science", volume = "A", publisher = "MIT Press/Elsevier", address = "Amsterdam"} @manual{rfc-md5, author = "Rivest, R.L.", year = 1992, title = "{RFC} 1321: The {MD5 Message-Digest Algorithm}", month = "April", organization = "Internet Activities Board"} @article{rivest-dss-response, author = "Rivest, R.L.", year = 1992, title = "Response to {NIST}'s Proposal", journal = "Communications of the ACM", volume = 35, pages = "41--47", month = "July"} @manual{PKCS-5, author = "{RSA Data Security, Inc.}", year = 1991, month = "June", title = "PKCS \#5: Password-Based Encryption Standard", note = "Version 1.4"} @book{computer-security-basics, author = "Russell, Deborah and G.T. Gangemi Sr.", year = 1991, title = "Computer Security Basics", publisher = "O'Reilly and Associates", address = "Sebastopol, CA"} @inproceedings{schnorr, author = "Schnorr, C.P.", year = 1990, title = "Efficient identification and signatures for smart cards", booktitle = "Advances in Cryptology --- Crypto '89", pages = "239--251", publisher = "Springer-Verlag", address = "New York"} @book{protecting-information, author = "Schweitzer, James A.", year = 1983, title = "Protection Information in the Electronic Workplace: A Guide for Managers", publisher = "Prentice-Hall", address = "Reston, VA"} @article{silverman, author = "Silverman, R.D.", year = 1987, title = "The multiple polynomial quadratic sieve", journal = "Math. Comp.", volume = 48, pages = "329--339"} @article{smid-des, author = "Smid, M.E. and Branstad, D.K.", year = 1988, title = "The {Data Encryption Standard}: {Past} and future", journal = "Proceedings of the IEEE", volume = 76, pages = "550--559"} @inproceedings{smid, author = "Smid, M.E. and Branstad, D.K.", year = 1993, title = "Response to comments on the {NIST} proposed {Digital Signature Standard}", booktitle = "Advances in Cryptology --- Crypto '92", publisher = "Springer-Verlag", note = "To appear"} @manual{australia, author = "{Standards Australia}", year = 1990, title = "AS 2805.6.5.3: Electronic Funds Transfer --- Key Management"} @book{cuckoo's-egg, author = "Stoll, Cliff", year = 1989, title = "The Cuckoo's Egg: Tracing a Spy Through the Maze of Computer Espionage", publisher = "Doubleday", address = "New York"} @article{wiener, author = "Wiener, M.J.", year = 1990, title = "Cryptanalysis of short {RSA} secret exponents", journal = "IEEE Trans. Information Theory", volume = 36, pages = "553--558"} From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tribble@xanadu.com Date: Tue, 6 Oct 92 17:44:27 PDT To: uunet!shearson.com!pmetzger@uunet.UU.NET Subject: Nuts & Acorns In-Reply-To: <9210062244.AA07304@newsu.shearson.com> Message-ID: <9210062358.AA08087@xanadu.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain In the future I imagine several companies that seel public keys for individuals. Depending on how much risk of forgery you can tolerate, you just buy an individuals public key from several of these companies. Then they must all collude to fool you. dean From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Tue, 6 Oct 92 18:30:07 PDT To: cypherpunks@toad.com Subject: Nuts & Acorns In-Reply-To: <9210062244.AA07304@newsu.shearson.com> Message-ID: <9210070137.AA15880@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Perry: >This does mean that a lot of the time until people have built up >catenative assembleges of keys sufficent to form a "chain of trust" >for unknown people that they will simply have to do without >certification of the other person's identity. Isn't that the way life >usually is, though? In large part the electronic environment is already pseudonymous. I don't know most Usenet posters personally and never will. I have no need to personally verify their identities; in fact, I don't even want to. But for someone I'm going to deal with over a period of time, I do want to make sure that it's the same person I'm dealing with each time. And if I never happen to meet this person face to face, or need to know anything about this person as a physical being, so be it. All I really care about is persistence, not identity. In the elctronic world, all you have are persistent pseudonyms. Most of them, true, are still linked to physical people, but there is no particular reason why that need continue. I think the changeover point will be this. As soon as there is money flowing through the networks which is tied only to pseudonyms and not to physical people, then you'll see a _lot_ more virtual-only identities. When you can conduct business and get paid for it, there's a big difference. When some of your data has negotiable cash value, you'll see privacy and security get *important*. And most of these identities will have regular sounding names. Handles, a la the underground, are more a mark of social identity than of anonymity. The best camouflage is not to draw attention to yourself. When most of the world is personal, look personal. Who will ever know? Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Tue, 6 Oct 92 15:59:23 PDT To: Tom.Jennings@f111.n125.z1.fidonet.org Subject: Nuts & Acorns In-Reply-To: <2654.2AD20C59@fidogate.FIDONET.ORG> Message-ID: <9210062244.AA07304@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: Tom.Jennings@f111.n125.z1.fidonet.org (Tom Jennings) >Not my worry. What I meant was, how do I know htat the keyfile I >received from "John Smith @ net address" really is his, and not some >faker. Short of physically getting key disks from someone face to >face (flatly im-possible here), I don't know. This is like asking "how do I get a bullet to stop in mid air and launch itself back into the bullet casing in the breech of the gun". You don't. Obviously, the only way to trust a key enough to certify it is to actually get it in person and verify identity. This is often impractical, but so what? If people want to communicate and the only assurance your signature gives them is that you got a copy of the keys by email, they might as well just email each other they keys and live knowing that the messages they are sending are to possibly non-securely identified people. Signed introduced keys should be reserved for times when you can actually add real information by claiming the key is really owned by the person who claims it. This does mean that a lot of the time until people have built up catenative assembleges of keys sufficent to form a "chain of trust" for unknown people that they will simply have to do without certification of the other person's identity. Isn't that the way life usually is, though? Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hollander Date: Tue, 6 Oct 92 22:34:13 PDT To: Eric Hughes Subject: Re: Nuts & Acorns In-Reply-To: <9210070137.AA15880@soda.berkeley.edu> Message-ID: <9210070541.AA23855@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain >In the elctronic world, all you have are persistent pseudonyms. Most >of them, true, are still linked to physical people, but there is no >particular reason why that need continue. Instead of thinking of keys as things belonging to people, we can think of people as things associated with keys. In fact, we just need to shift the focus to be entirely on the keys, and leave the people out of it. e From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Wed, 7 Oct 92 16:46:07 PDT To: cypherpunks@toad.com Subject: re: introducers Message-ID: <2715.2AD37337@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain U> Detection of tampering is plenty good enough, I think, for U> a _network_ policy of key distribution. For most people, U> it will work fine. I guess I had to come at this from the backside. You are right. Accepting keys over the network will provide reasonably well-sealed envelopes. It won't provide notarized, hand-delivered security, but that's not what's needed *usually*. U> For personal use, for people I know, I'm going to rely on U> personally U> exchanged keys. Exactly. * Origin: World Power Systems / FidoNews (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: whitaker@eternity.demon.co.uk (Russell E. Whitaker) Date: Thu, 8 Oct 92 01:04:18 PDT To: cypherpunks@toad.com Subject: Hammill on public key Message-ID: <1439@eternity.demon.co.uk> MIME-Version: 1.0 Content-Type: text/plain FROM CROSSBOWS TO CRYPTOGRAPHY: THWARTING THE STATE VIA TECHNOLOGY Given at the Future of Freedom Conference, November 1987 You know, technology--and particularly computer technology--has often gotten a bad rap in Libertarian cir- cles. We tend to think of Orwell's 1984, or Terry Gilliam's Brazil, or the proximity detectors keeping East Berlin's slave/citizens on their own side of the border, or the so- phisticated bugging devices Nixon used to harass those on his "enemies list." Or, we recognize that for the price of a ticket on the Concorde we can fly at twice the speed of sound, but only if we first walk thru a magnetometer run by a government policeman, and permit him to paw thru our be- longings if it beeps. But I think that mind-set is a mistake. Before there were cattle prods, governments tortured their prisoners with clubs and rubber hoses. Before there were lasers for eavesdropping, governments used binoculars and lip-readers. Though government certainly uses technology to oppress, the evil lies not in the tools but in the wielder of the tools. In fact, technology represents one of the most promis- ing avenues available for re-capturing our freedoms from those who have stolen them. By its very nature, it favors the bright (who can put it to use) over the dull (who can- not). It favors the adaptable (who are quick to see the merit of the new( over the sluggish (who cling to time- tested ways). And what two better words are there to de- scribe government bureaucracy than "dull" and "sluggish"? One of the clearest, classic triumphs of technology over tyranny I see is the invention of the man-portable crossbow. With it, an untrained peasant could now reliably and lethally engage a target out to fifty meters--even if that target were a mounted, chain-mailed knight. (Unlike the longbow, which, admittedly was more powerful, and could get off more shots per unit time, the crossbow required no formal training to utilize. Whereas the longbow required elaborate visual, tactile and kinesthetic coordination to achieve any degree of accuracy, the wielder of a crossbow could simply put the weapon to his shoulder, sight along the arrow itself, and be reasonably assured of hitting his tar- get.) Moreover, since just about the only mounted knights likely to visit your average peasant would be government soldiers and tax collectors, the utility of the device was plain: With it, the common rabble could defend themselves not only against one another, but against their governmental masters. It was the medieval equivalent of the armor- piercing bullet, and, consequently, kings and priests (the medieval equivalent of a Bureau of Alcohol, Tobacco and Crossbows) threatened death and excommunication, respec- tively, for its unlawful possession. Looking at later developments, we see how technology like the firearm--particularly the repeating rifle and the handgun, later followed by the Gatling gun and more advanced machine guns--radically altered the balance of interpersonal and inter-group power. Not without reason was the Colt .45 called "the equalizer." A frail dance-hall hostess with one in her possession was now fully able to protect herself against the brawniest roughneck in any saloon. Advertise- ments for the period also reflect the merchandising of the repeating cartridge rifle by declaring that "a man on horseback, armed with one of these rifles, simply cannot be captured." And, as long as his captors were relying upon flintlocks or single-shot rifles, the quote is doubtless a true one. Updating now to the present, the public-key cipher (with a personal computer to run it) represents an equiv- alent quantum leap--in a defensive weapon. Not only can such a technique be used to protect sensitive data in one's own possession, but it can also permit two strangers to ex- change information over an insecure communications channel--a wiretapped phone line, for example, or skywriting, for that matter)--without ever having previously met to exchange cipher keys. With a thousand-dollar com- puter, you can create a cipher that a multi-megabuck CRAY X-MP can't crack in a year. Within a few years, it should be economically feasible to similarly encrypt voice communi- cations; soon after that, full-color digitized video images. Technology will not only have made wiretapping obsolete, it will have totally demolished government's control over in- formation transfer. I'd like to take just a moment to sketch the mathemat- ics which makes this principle possible. This algorithm is called the RSA algorithm, after Rivest, Shamir, and Adleman who jointly created it. Its security derives from the fact that, if a very large number is the product of two very large primes, then it is extremely difficult to obtain the two prime factors from analysis of their product. "Ex- tremely" in the sense that if primes p and q have 100 digits apiece, then their 200-digit product cannot in gen- eral be factored in less than 100 years by the most powerful computer now in existence. The "public" part of the key consists of (1) the prod- uct pq of the two large primes p and q, and (2) one fac- tor, call it x , of the product xy where xy = {(p-1) * (q-1) + 1}. The "private" part of the key consists of the other factor y. Each block of the text to be encrypted is first turned into an integer--either by using ASCII, or even a simple A=01, B=02, C=03, ... , Z=26 representation. This integer is then raised to the power x (modulo pq) and the resulting integer is then sent as the encrypted message. The receiver decrypts by taking this integer to the (secret) power y (modulo pq). It can be shown that this process will always yield the original number started with. What makes this a groundbreaking development, and why it is called "public-key" cryptography," is that I can openly publish the product pq and the number x , while keeping secret the number y --so that anyone can send me an encrypted message, namely x a (mod pq) , but only I can recover the original message a , by taking what they send, raising it to the power y and taking the result (mod pq). The risky step (meeting to exchange cipher keys) has been eliminated. So people who may not even trust each other enough to want to meet, may still reliably ex- change encrypted messages--each party having selected and disseminated his own pq and his x , while maintaining the secrecy of his own y. Another benefit of this scheme is the notion of a "dig- ital signature," to enable one to authenticate the source of a given message. Normally, if I want to send you a message, I raise my plaintext a to your x and take the result (mod your pq) and send that. However, if in my message, I take the plaintext a and raise it to my (secret) power y , take the result (mod my pq), then raise that result to your x (mod your pq) and send this, then even after you have normally "decrypted" the message, it will still look like garbage. However, if you then raise it to my public power x , and take the result (mod my public pq ), so you will not only recover the ori- ginal plaintext message, but you will know that no one but I could have sent it to you (since no one else knows my secret y). And these are the very concerns by the way that are to- day tormenting the Soviet Union about the whole question of personal computers. On the one hand, they recognize that American schoolchildren are right now growing up with com- puters as commonplace as sliderules used to be--more so, in fact, because there are things computers can do which will interest (and instruct) 3- and 4-year-olds. And it is pre- cisely these students who one generation hence will be going head-to-head against their Soviet counterparts. For the Soviets to hold back might be a suicidal as continuing to teach swordsmanship while your adversaries are learning ballistics. On the other hand, whatever else a personal computer may be, it is also an exquisitely efficient copying machine--a floppy disk will hold upwards of 50,000 words of text, and can be copied in a couple of minutes. If this weren't threatening enough, the computer that performs the copy can also encrypt the data in a fashion that is all but unbreakable. Remember that in Soviet society publicly ac- cessible Xerox machines are unknown. (The relatively few copying machines in existence are controlled more inten- sively than machine guns are in the United States.) Now the "conservative" position is that we should not sell these computers to the Soviets, because they could use them in weapons systems. The "liberal" position is that we should sell them, in the interests of mutual trade and cooperation--and anyway, if we don't make the sale, there will certainly be some other nation willing to. For my part, I'm ready to suggest that the Libertarian position should be to give them to the Soviets for free, and if necessary, make them take them . . . and if that doesn't work load up an SR-71 Blackbird and air drop them over Moscow in the middle of the night. Paid for by private sub- scription, of course, not taxation . . . I confess that this is not a position that has gained much support among members of the conventional left-right political spectrum, but, af- ter all, in the words of one of Illuminatus's characters, we are political non-Euclideans: The shortest distance to a particular goal may not look anything like what most people would consider a "straight line." Taking a long enough world-view, it is arguable that breaking the Soviet govern- ment monopoly on information transfer could better lead to the enfeeblement and, indeed, to the ultimate dissolution of the Soviet empire than would the production of another dozen missiles aimed at Moscow. But there's the rub: A "long enough" world view does suggest that the evil, the oppressive, the coercive and the simply stupid will "get what they deserve," but what's not immediately clear is how the rest of us can escape being killed, enslaved, or pauperized in the process. When the liberals and other collectivists began to at- tack freedom, they possessed a reasonably stable, healthy, functioning economy, and almost unlimited time to proceed to hamstring and dismantle it. A policy of political gradualism was at least conceivable. But now, we have patchwork crazy-quilt economy held together by baling wire and spit. The state not only taxes us to "feed the poor" while also inducing farmers to slaughter milk cows and drive up food prices--it then simultaneously turns around and sub- sidizes research into agricultural chemicals designed to in- crease yields of milk from the cows left alive. Or witness the fact that a decline in the price of oil is considered as potentially frightening as a comparable increase a few years ago. When the price went up, we were told, the economy risked collapse for for want of energy. The price increase was called the "moral equivalent of war" and the Feds swung into action. For the first time in American history, the speed at which you drive your car to work in the morning be- came an issue of Federal concern. Now, when the price of oil drops, again we risk problems, this time because Ameri- can oil companies and Third World basket-case nations who sell oil may not be able to ever pay their debts to our grossly over-extended banks. The suggested panacea is that government should now re-raise the oil prices that OPEC has lowered, via a new oil tax. Since the government is seeking to raise oil prices to about the same extent as OPEC did, what can we call this except the "moral equivalent of civil war--the government against its own people?" And, classically, in international trade, can you imag- ine any entity in the world except a government going to court claiming that a vendor was selling it goods too cheaply and demanding not only that that naughty vendor be compelled by the court to raise its prices, but also that it be punished for the act of lowering them in the first place? So while the statists could afford to take a couple of hundred years to trash our economy and our liberties--we certainly cannot count on having an equivalent period of stability in which to reclaim them. I contend that there exists almost a "black hole" effect in the evolution of nation-states just as in the evolution of stars. Once free- dom contracts beyond a certain minimum extent, the state warps the fabric of the political continuum about itself to the degree that subsequent re-emergence of freedom becomes all but impossible. A good illustration of this can be seen in the area of so-called "welfare" payments. When those who sup at the public trough outnumber (and thus outvote) those whose taxes must replenish the trough, then what possible choice has a democracy but to perpetuate and expand the tak- ing from the few for the unearned benefit of the many? Go down to the nearest "welfare" office, find just two people on the dole . . . and recognize that between them they form a voting bloc that can forever outvote you on the question of who owns your life--and the fruits of your life's labor. So essentially those who love liberty need an "edge" of some sort if we're ultimately going to prevail. We obvi- ously can't use the altruists' "other-directedness" of "work, slave, suffer, sacrifice, so that next generation of a billion random strangers can live in a better world." Recognize that, however immoral such an appeal might be, it is nonetheless an extremely powerful one in today's culture. If you can convince people to work energetically for a "cause," caring only enough for their personal welfare so as to remain alive enough and healthy enough to continue working--then you have a truly massive reservoir of energy to draw from. Equally clearly, this is just the sort of ap- peal which tautologically cannot be utilized for egoistic or libertarian goals. If I were to stand up before you tonight and say something like, "Listen, follow me as I enunciate my noble "cause," contribute your money to support the "cause," give up your free time to work for the "cause," strive selflessly to bring it about, and then (after you and your children are dead) maybe your children's children will actu- ally live under egoism"--you'd all think I'd gone mad. And of course you'd be right. Because the point I'm trying to make is that libertarianism and/or egoism will be spread if, when, and as, individual libertarians and/or egoists find it profitable and/or enjoyable to do so. And probably only then. While I certainly do not disparage the concept of poli- tical action, I don't believe that it is the only, nor even necessarily the most cost-effective path toward increasing freedom in our time. Consider that, for a fraction of the investment in time, money and effort I might expend in try- ing to convince the state to abolish wiretapping and all forms of censorship--I can teach every libertarian who's in- terested how to use cryptography to abolish them unilaterally. There is a maxim--a proverb--generally attributed to the Eskimoes, which very likely most Libertarians have al- ready heard. And while you likely would not quarrel with the saying, you might well feel that you've heard it often enough already, and that it has nothing further to teach us, and moreover, that maybe you're even tired of hearing it. I shall therefore repeat it now: If you give a man a fish, the saying runs, you feed him for a day. But if you teach a man how to fish, you feed him for a lifetime. Your exposure to the quote was probably in some sort of a "workfare" vs. "welfare" context; namely, that if you genuinely wish to help someone in need, you should teach him how to earn his sustenance, not simply how to beg for it. And of course this is true, if only because the next time he is hungry, there might not be anybody around willing or even able to give him a fish, whereas with the information on how to fish, he is completely self sufficient. But I submit that this exhausts only the first order content of the quote, and if there were nothing further to glean from it, I would have wasted your time by citing it again. After all, it seems to have almost a crypto-altruist slant, as though to imply that we should structure our ac- tivities so as to maximize the benefits to such hungry beggars as we may encounter. But consider: Suppose this Eskimo doesn't know how to fish, but he does know how to hunt walruses. You, on the other hand, have often gone hungry while traveling thru walrus country because you had no idea how to catch the damn things, and they ate most of the fish you could catch. And now suppose the two of you decide to exchange information, bartering fishing knowledge for hunting knowledge. Well, the first thing to observe is that a transaction of this type categorically and unambiguously refutes the Marxist premise that every trade must have a "winner" and a "loser;" the idea that if one person gains, it must necessarily be at the "expense" of another person who loses. Clearly, under this scenario, such is not the case. Each party has gained some- thing he did not have before, and neither has been dimin- ished in any way. When it comes to exchange of information (rather than material objects) life is no longer a zero-sum game. This is an extremely powerful notion. The "law of diminishing returns," the "first and second laws of thermodynamics"--all those "laws" which constrain our possi- bilities in other contexts--no longer bind us! Now that's anarchy! Or consider another possibility: Suppose this hungry Eskimo never learned to fish because the ruler of his nation-state had decreed fishing illegal. Because fish contain dangerous tiny bones, and sometimes sharp spines, he tells us, the state has decreed that their consumption--and even their possession--are too hazardous to the people's health to be permitted . . . even by knowledgeable, willing adults. Perhaps it is because citizens' bodies are thought to be government property, and therefore it is the function of the state to punish those who improperly care for govern- ment property. Or perhaps it is because the state gener- ously extends to competent adults the "benefits" it provides to children and to the mentally ill: namely, a full-time, all-pervasive supervisory conservatorship--so that they need not trouble themselves with making choices about behavior thought physically risky or morally "naughty." But, in any case, you stare stupefied, while your Eskimo informant re- lates how this law is taken so seriously that a friend of his was recently imprisoned for years for the crime of "pos- session of nine ounces of trout with intent to distribute." Now you may conclude that a society so grotesquely oppressive as to enforce a law of this type is simply an affront to the dignity of all human beings. You may go far- ther and decide to commit some portion of your discretion- ary, recreational time specifically to the task of thwarting this tyrant's goal. (Your rationale may be "altruistic" in the sense of wanting to liberate the oppressed, or "egoistic" in the sense of proving you can outsmart the oppressor--or very likely some combination of these or per- haps even other motives.) But, since you have zero desire to become a martyr to your "cause," you're not about to mount a military campaign, or even try to run a boatload of fish through the blockade. However, it is here that technology--and in particular in- formation technology--can multiply your efficacy literally a hundredfold. I say "literally," because for a fraction of the effort (and virtually none of the risk) attendant to smuggling in a hundred fish, you can quite readily produce a hundred Xerox copies of fishing instructions. (If the tar- geted government, like present-day America, at least permits open discussion of topics whose implementation is re- stricted, then that should suffice. But, if the government attempts to suppress the flow of information as well, then you will have to take a little more effort and perhaps write your fishing manual on a floppy disk encrypted according to your mythical Eskimo's public-key parameters. But as far as increasing real-world access to fish you have made genuine nonzero headway--which may continue to snowball as others re-disseminate the information you have provided. And you have not had to waste any of your time trying to convert id- eological adversaries, or even trying to win over the unde- cided. Recall Harry Browne's dictum from "Freedom in an Unfree World" that the success of any endeavor is in general inversely proportional to the number of people whose persua- sion is necessary to its fulfilment. If you look at history, you cannot deny that it has been dramatically shaped by men with names like Washington, Lincoln, . . . Nixon . . . Marcos . . . Duvalier . . . Khadaffi . . . and their ilk. But it has also been shaped by people with names like Edison, Curie, Marconi, Tesla and Wozniak. And this latter shaping has been at least as per- vasive, and not nearly so bloody. And that's where I'm trying to take The LiberTech Project. Rather than beseeching the state to please not en- slave, plunder or constrain us, I propose a libertarian net- work spreading the technologies by which we may seize freedom for ourselves. But here we must be a bit careful. While it is not (at present) illegal to encrypt information when government wants to spy on you, there is no guarantee of what the fu- ture may hold. There have been bills introduced, for exam- ple, which would have made it a crime to wear body armor when government wants to shoot you. That is, if you were to commit certain crimes while wearing a Kevlar vest, then that fact would constitute a separate federal crime of its own. This law to my knowledge has not passed . . . yet . . . but it does indicate how government thinks. Other technological applications, however, do indeed pose legal risks. We recognize, for example, that anyone who helped a pre-Civil War slave escape on the "underground railroad" was making a clearly illegal use of technology--as the sovereign government of the United States of America at that time found the buying and selling of human beings quite as acceptable as the buying and selling of cattle. Simi- larly, during Prohibition, anyone who used his bathtub to ferment yeast and sugar into the illegal psychoactive drug, alcohol--the controlled substance, wine--was using technol- ogy in a way that could get him shot dead by federal agents for his "crime"--unfortunately not to be restored to life when Congress reversed itself and re-permitted use of this drug. So . . . to quote a former President, un-indicted co- conspirator and pardoned felon . . . "Let me make one thing perfectly clear:" The LiberTech Project does not advocate, participate in, or conspire in the violation of any law--no matter how oppressive, unconstitutional or simply stupid such law may be. It does engage in description (for educa- tional and informational purposes only) of technological processes, and some of these processes (like flying a plane or manufacturing a firearm) may well require appropriate li- censing to perform legally. Fortunately, no license is needed for the distribution or receipt of information it- self. So, the next time you look at the political scene and despair, thinking, "Well, if 51% of the nation and 51% of this State, and 51% of this city have to turn Libertarian before I'll be free, then somebody might as well cut my goddamn throat now, and put me out of my misery"--recognize that such is not the case. There exist ways to make your- self free. If you wish to explore such techniques via the Project, you are welcome to give me your name and address--or a fake name and mail drop, for that matter--and you'll go on the mailing list for my erratically-published newsletter. Any friends or acquaintances whom you think would be interested are welcome as well. I'm not even asking for stamped self- addressed envelopes, since my printer can handle mailing la- bels and actual postage costs are down in the noise compared with the other efforts in getting an issue out. If you should have an idea to share, or even a useful product to plug, I'll be glad to have you write it up for publication. Even if you want to be the proverbial "free rider" and just benefit from what others contribute--you're still welcome: Everything will be public domain; feel free to copy it or give it away (or sell it, for that matter, 'cause if you can get money for it while I'm taking full-page ads trying to give it away, you're certainly entitled to your capitalist profit . . .) Anyway, every application of these principles should make the world just a little freer, and I'm certainly willing to underwrite that, at least for the forseeable fu- ture. I will leave you with one final thought: If you don't learn how to beat your plowshares into swords before they outlaw swords, then you sure as HELL ought to learn before they outlaw plowshares too. --Chuck Hammill THE LIBERTECH PROJECT 3194 Queensbury Drive Los Angeles, California 90064 310-836-4157 [The above LiberTech address was updated June 1992, with the permission of Chuck Hammill, by: Russell Earl Whitaker whitaker@eternity.demon.co.uk Communications Editor 71750.2413@compuserve.com EXTROPY: The Journal of Transhumanist Thought AMIX: RWHITAKER Board member, Extropy Institute (ExI) [.sig revised 11 September 1992 /// Send mail to eternity node] -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAiqwg10AAAEEAMVNMI766ljeuW01xqXKYYV5lmDPvb+6dCQK3m1iBQdan0no pm35j1DIRp3UJZogAe5eimsQg1TALDhTq310OZs9+L6B/HxeX3+4BadIDad4g+xI lvaFY1Ut/hMdZNkw0tzNZOdUPiO4jYIyirReAUiMCm6jXzkTRITj7/vxxWtPAAUR tDNSdXNzZWxsIEUuIFdoaXRha2VyIDx3aGl0YWtlckBldGVybml0eS5kZW1vbi5j by51az4= =LOCL -----END PGP PUBLIC KEY BLOCK----- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: hughes (Eric Hughes) Date: Thu, 8 Oct 92 08:41:35 PDT To: whitaker@eternity.demon.co.uk Subject: Subscribe In-Reply-To: <1480@eternity.demon.co.uk> Message-ID: <9210081541.AA03134@toad.com> MIME-Version: 1.0 Content-Type: text/plain You are subscribed. Next time, please use the cypherpunks-request@toad.com address for administrative matters. Tell your friends this as well. Your request got sent out to the whole list, not a tragedy, but an annoyance. I met Max More at a party about a month ago. I suspect he might be interested in the list. Do you have an e-mail address for him? Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Thu, 8 Oct 92 08:57:23 PDT To: cypherpunks@toad.com Subject: Subscriptions, etc. In-Reply-To: <9210081541.AA03134@toad.com> Message-ID: <9210081604.AA15870@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Yow! I'm a hypocrite! Now _I_ forgot to look at the reply line. Damn. Diligence, diligence. -------------------------------------------- In other news, the list membership is up to 60 people and one local newsgroup gateway. I have five more to add, some of whose addresses I have to find out. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Thu, 8 Oct 92 18:48:59 PDT To: cypherpunks@toad.com Subject: re: Subscribe Message-ID: <2733.2AD49634@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain My public key. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQBNAirHIV8AAAECAOE6hyvBZUslVOgi12u6d7/6yMIXX4aKIRcfV3wa/ysHl+ul d4agC1YW+YimYeA+/bXOBxH/Y/KRzT/tLvUlcRcABRG0MVRvbSBKZW5uaW5ncyA8 dG9takBmaWRvc3cuZmlkb25ldC5vcmcsIDE6MTI1LzExMT4= =dADc -----END PGP PUBLIC KEY BLOCK----- My public key ring, signed with my secret key: -----BEGIN PGP MESSAGE----- Version: 2.0 owF1l3VU0/v/xzeGtCBwQUJ0ICI5OqUbJEYb1IQx5tgGYwMpBamBpNJggAEoKiAq HVe6Q0pC8tKO0tH8JlcO9/zO+f7zOe/P+4/3eb8fz+erogA2VKcAol9lmDs0ViA/ L3mdBQIDmKkA47t9zTtBybMxWgRHMzFr/pgLHXIsVYQW+yWb94wbYdAYS7nw5gXk tzbBbHO1QSuNTpl6zzKU6rVWOs0L/b1mEemAWCrRwlAHAABIDWgwlYrbWbw2XoaW b3zZCgv3S3HuqqopxwsyjKNvnaK98dRo/hV6Ox7arP/466UMMPCHYzTqTKh1rbiS 1ZsgvHKm2lZ1yF6go9O90lO5hqdz74QuG6b8CnexkThg53Mdluod7XCds1a/WBp7 Xya6xBFoGMOAee6kzK4bNk3aXWtAmQNOsRYCtUpkLQne3nAPD7AeBGznjsTDUHAc WNX3z0oTjofjMEi8H8QVjsZiIC5YCAGlXggERf1GdEb0q7TgCSIoBVHmkotkeXv7 wBdZ+vc9HTNJVPM5qilvhegDL2Z7KQqkrg2KqvY62YPiIgH0LUX1U2w40Y0H7dkP 6IQU8pEIZ2u+QmBkOsCUSrQCLkWhRAWoFd3nfF4WwjkvsHSRCOBxjHXGkt84zP0z 3E4S/fmqExOsl8b8/iwnQ3WehZ0f3oKXv9ico4CslM61J1fdzp1ADzjFXgjUKxHV xsFcwToQsKmLDgyH9wOruilIK0Iw0jLyEH9piBvSFYuB4yFYHOI/j+s1en7yuBYG 4KHRaiu3KqlnBPkWqz/et99F20etH4q0Vfhp6qzazcxcSQph6Cvc1aIKK+zVi6vJ mnip4yXJHMydlhEbQtXLPdp99DiKBT69wx5ZoC290jPdNzgivHs0yK4l/nzkfq0f 1BLPyS17+2Yo4m6DWNncJsekp2Yy6Lai6an4GOI9Uufyt6oJDn5W9zjaJNvUWFTz 5f26W/QMjJy9mbJBqtG1+yCSfOD7gyIFe9ZT2RduNXjs3ezVZTOSihVLHI+9d7ND QHaXptgqKk1Hudju+5EFKHCs3GG+GPBVCNiCgMRgKGwU5eWlKHCkFChwNP8XHNUT OGZtwD0GI70XrQ9scaP9V1Bhwqki38qz/OueQwMg/PxpyQJVwj+5lLkftublBGrL B8jTaESJNXgtMcdPU13YNCMWddocUuBEAZJ/H909OIxGK1l6X824DgQWeIMO9Ssz B+x+yVuwfiTr1vYvGrVofdLjWYmWHJHJA9pn7yTowWSVW7q7aiIm74w4zOEGdPvq cVlgj/vJXjrL5c/O1PCeU7s1J/B1FdgXdCCfwOv9md592Tk9eVcNkkd+I7/PBR9m nQ27cu7Sd+OQIMIAW4MgZ3HlpOE9Sc1oVMACDJNSCAw/0q1D4uBItw8yzSNTRVVW lyzWIxhXUMMLLEB3wdB8odektdZtldT7KtzskVy2LORr6UK6XdyY6UJrZjXjZjnH tH3hUO2FEV5pwbJgIjzaN2YoyT863BMsmPlB5FbllWdmQcm8HDFUdNl5jz+sqJKt 1Z8YM9x8+KLQwdwZWmwqnHhM5Y9uwjruOKQ3HuvpTglZ7X8DV1pFVlFOUlruf6oG OlHtLjfw0PLjZG/BCzK1SI1vhjiPNnTZznJmse6cOACATdLs5ZG468ZB4Js+75TK XrTchGTiYY6XPI1hSssa5705G1GkQ3+iWodLK5fdzFjRp9KLQKBAHOhAnriXXJQy FVIkN43v9napcZDl8y8oXj6IW9mj3mfJnmWEpRo79F+OGzdee62QCqEb7is3LKo5 WLxjvWZ0ge5qOAF7jb0iSymCdlguFyhG6nFWJnF2pEz3Y+Yrg/9Cv3vtzvH99kWR LsyZogpGUaXxlehAKV2mZ1E9MpWYSzZ2YW8oqh1fTVHsxFDdAGpAiBqogyeyhm9W newGI52/mRrTCHwwHttXWkTeY+F+5/bMGPDWwVryS/reEoeDFOOFpyy58ULzLP4s aqgLS09Sc+AVfTg9dpsuZkHHAwdnSY2cH60/eCdo32KCmdBXP2x0SqNyBoP4Ncf2 y4Q0xi8h9MY5tRRrt00ULeEPH/g9gm8eG6oRnnhkqOokL5Uh1Wx7bbnlgc2R+tux A2MDlQ5Fm9+5C8jNYtSTgRsLL/VmGBwjuvQ1Enerrpfq5IARUjliVfiVImx2z/6D zDqJnzwrUn8F8U7Evghd3rE0RQwtrxdDYu/+uO2J3resQRh64qM3LjcCWXP753Oc xy3+ubuE8D0W7I+h5AyugqEwFzgYfPNfH8kogFURKE/KlqabjAIEQ9n7/+nS4chc /2JuYTzBvC5IDUhq5jHkNs1ZbJ8dDOYWncgvzX2/edjrbUy/sYDAF4qsVCjEx7IW uZ0TNVdX6TCydOeSJeQ2xRv7OFQvZpIj6ek8BPGetr4IuXq6r9PyXMvYxz5EIYc1 jR+wxzf621YCnFFXF06nQocYM4WfJT4ZSOUaXco73A7IFYfSWfON24h/OHLAke+b 9dJPfG9fADzUbD9dmcokouzeHcA8uiLxmH4f6VbBa3ul+cKGrRT1evFHTvbMT+rD aiUp4irCTSv1xb8mmk/jsuzvWNIl2xqfQx6n8sJa6JGCn5QDV6inTilsxRn/uPcQ LFYM7rPOiN8Y1iaJlSWNJKQMvtbf1x1fHP7UuMY2FJNlzy6VuPD+RgmmQ2HwYRnt 1qFY2VC7W14InkaEkSVg8TM7m/irMy8QdnFSbGPqp8O4thAlbGPNz28R8okt2XxV 5+832PRLTKrg6NzEDBDLGeC6PwqKaeFuwzFgAwjYBI7B+4OFTfTMrG+Arcz1re20 LPUkdPVs9UzMoaaUXZGTrNAkmH9CR8mXCjAAEe8dbGJY5rKaDsgwebcmEXm13yCn 9kuW7YKUbZcd5IUmKS/ANjR7dUQsq3bepF3NNfBCxCgHFxHjfy07lJPumA56XfyI TlF08KdZVsBTr0QBnfk6zkDlUM27zx0jpHbFndmIKx+fxbjVMefPaIfS3AYZvawr +xiUKfrQwZ+upF/UZxgU8zJl7N1hqwNHZO66S0Fvrat/EO3CbE5jT8H6JHeK5t68 jNWzXzx1uVKK7MgvX6YDhQdYEi0TSNuG7e+nCOPMhwgy4xEdQIk41B3pgfQEW0LA N5BoNByHhv0ud544f01vGAIOcUG4QgguMBwE7kqgJE2qKEDSka+VgCe+FssHbXV+ oq66Y0OqrOpFJwewcHtIHeb+lW/jAZZ1fGdVGGILlZR5sXyIETX3j5ogXxp6Fz8A SI7XV88Mbbhi9tXZqMwiSO5UCHcjv555jDIdaYs6dUlgZZ5/IIMgJI0/97M0hTtn kXpHS9L3Llogw0YtIEKCY8yfOFjB0q8E5wpxumF1ktiwlnKbrYCQ2DmBYSBQeZca UIPfzekEvjArlVkXfjPK2/7ImKUJo2v9LkXcqT1jiGSqv/OrsJLQMa87t90DzZE3 M83vfGJEjs64+lgozqYaVfz0nz7ZzWQkEzlpLXaGND2HnWicumZHY5JU5VAbnfO5 qev6za2e5zK0slMO5qUyFqf7P+7HH8b0VVusZ7cVpN0CUygfCe9Rl34kfOvo63Wp 5lzJBvcGtLYoaQvW4br0cmYSH2OUWrKjcfPsT7OMei5L1I2w1UrPDoWA/a3bSCN7 ePnk8+Q4JpVnAUFljz4rMAkTeVmrUfRjWue/LQRV7psqI091E1t6t4ggpXKVYDF9 6A1G5nBhbAIkRSUyabE7ZzsPfEzlj/CXKe0fBoUFm1C+cG9KSwsGq3r8WWu6+SIh BB8YBONB0Rzwhyx6PeHYPEDg32dBh56kM6ba98TNjJ7SQh4u9rguw/TPbwIOB9+0 sc6+lvoSxpbgJ2DEs9GU9vXMd+dc26Ud2SeiDRq3yltFZPYtOCDcDlJBFQ+TJ/Pq eLZpAttoJYgCAAM+K/ox4zNCC2L3OnjoO05/CzAK5jQ3cX6Y5tkW5Vy1Sp+2VBB3 TaF80vCHz5djsgEyOUdkB9A6Ff2eHHnfHZLnyAmu6JT64F/0nQ/DtDuuu0+xYq/U +PCThgaejv6T9cuZKWm3uwT9j4ENbDV7lc8SgTx758O396XVF0PFx5I81MJ+8LDE oZvESyeizkS3lWnF9QgHlpWYmr4ynuBWPi8r8tye/iyrFzithC7KlWWH9fXC4/Qg gz9kL0F/TwhgAwL+TywhCHhpTRdvCIyAImCQEJgLBOP/H64v/FJPuL5rBO0xPDP6 fMXXP+1KYuEXF2n4XTDI7HK7z3oTYc6pwBY6q/Jlxmv/3mYv+9Y3oroG3mknwbkP wkCMrAiPfaRcnevPt/iy1SsBz/DRiFVr/IOzlUVZNKu80vny+iki46ZndSLsld6N cSUDhc73AUZuleTStbYuJImZnDUt21TZytkyq3fElTJwRKv7HA0cnSDo9pqPwtZo 1N1mZVYoiT1UNuWAq++D00jKdZQNiZYZCszzMYmq4pG7Zqxre7H6i+V3bsWJ8bLq YcM9f3aFn3+48BvCcDg/sDbB2x2serTWdIF54z3gEBwSAYN4+PyHySvOgZMozrcH 7bHsVfudH8o2bbbsUx7gJ9LAMY9+PH/70SSC0469ZUvjka0Wo8/dphvOC0yuqqkH gxkT9TRFzzkFL35t2yEtzrHlaU7NtTa/KFtGPUSM0ZCHHkBE7hNZcB+ZErsaclbh spFIZE3NFukLtt5QBuXXL5uzmujPVxOapmZvnVXOJmcRfswka/0thQnwAJKwH2ji /i1F4+a1CQ3J89XGD4De/QH1m47wkp/mfmhit05i6JuKBhGUn7+ayqZDN2fDtoEZ lfSuBuNkzegt6ot/mAgYw2EYCQ8swRNsAEN6eFCmsNu//zRd3LE4gjfEDfcfKLme yBMo8zKgXeraS7HL4fLmOjYKBsy43OokkT2N2KSgIAvo6/uBxovmj7UA270X1S4j YVBwPDd7rJ4Wc05p/kjgazcBCIe//Wj8Feq6UfnZJkSLE/OmTfdIVoH0ivZ8mTC+ QaHH++KF6q2poNO8jubXP9hngsx00IRfo+oV33rKJ8pVbcKrgqRsjqE08TsdGWVS JVKsDn71kvW8wCCq3Ldmp/nvs04R0fxnL9gF8hyK0aYuvfSNeMZoy7lNfAWbUN// 2EnLeuiynnhcaY+gRJZIW2PRYGM4BoPEILzBqngs+vZR7+7t+982SxwsrUKZVSWl paXVTxqu7kmFk8KUWAA6ULvRnFfH4g8W+rxedV/+U4NLstbrbaeKgy3JPZocrviW V2kIhyqaEnKb44yEWetCu8nbsyX2uwkPRpnSnMSU83c+Gy4oNlrwfit2f6MLZakn B+1Y2vMzEbPuJDJR65VVeXHNqOtcH3NsTO3fZyYHbBwYDrro5jH+/ZdeLDMne8NA ykllagu7dTINZB+ADi1HJZW6uqP3emf7FWW73L14X9xhjEXWbvRM9w4OgnSQ5Kz+ c9mndfo17s54z6ArCrzc2papTIM+FBfWhSgbPyXq185szIC/P1GuW+2HDvavbGbf +2Q7PnBtRGg41yt+TLVpNRGprWrRZv+zcJQYnpQhH867VgBSXIrJ+C5rZZ3JQrna /wE= =irCz -----END PGP MESSAGE----- * Origin: World Power Systems / FidoNews (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: whitaker@eternity.demon.co.uk (Russell E. Whitaker) Date: Thu, 8 Oct 92 07:04:56 PDT To: cypherpunks@toad.com Subject: Subscribe Message-ID: <1480@eternity.demon.co.uk> MIME-Version: 1.0 Content-Type: text/plain SUBSCRIBE To human overseer: Please subscribe me to the cypherpunks list... Thanks, Russell Earl Whitaker whitaker@eternity.demon.co.uk Communications Editor 71750.2413@compuserve.com EXTROPY: The Journal of Transhumanist Thought AMiX: RWHITAKER Board member, Extropy Institute (ExI) [.sig revised 1 October 1992 /// Send mail to eternity node] -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAiqwg10AAAEEAMVNMI766ljeuW01xqXKYYV5lmDPvb+6dCQK3m1iBQdan0no pm35j1DIRp3UJZogAe5eimsQg1TALDhTq310OZs9+L6B/HxeX3+4BadIDad4g+xI lvaFY1Ut/hMdZNkw0tzNZOdUPiO4jYIyirReAUiMCm6jXzkTRITj7/vxxWtPAAUR tDNSdXNzZWxsIEUuIFdoaXRha2VyIDx3aGl0YWtlckBldGVybml0eS5kZW1vbi5j by51az4= =LOCL -----END PGP PUBLIC KEY BLOCK----- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: whitaker@eternity.demon.co.uk (Russell E. Whitaker) Date: Thu, 8 Oct 92 09:15:02 PDT To: cypherpunks@toad.com Subject: Apologies for newbie mistake Message-ID: <1499@eternity.demon.co.uk> MIME-Version: 1.0 Content-Type: text/plain I apologize for having sent my SUBSCRIBE request to the list-at-large... I'm setting up a new mail client, and {{excuse}mumble}. Russell Earl Whitaker whitaker@eternity.demon.co.uk Communications Editor 71750.2413@compuserve.com EXTROPY: The Journal of Transhumanist Thought AMiX: RWHITAKER Board member, Extropy Institute (ExI) [.sig revised 1 October 1992 /// Send mail to eternity node] -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAiqwg10AAAEEAMVNMI766ljeuW01xqXKYYV5lmDPvb+6dCQK3m1iBQdan0no pm35j1DIRp3UJZogAe5eimsQg1TALDhTq310OZs9+L6B/HxeX3+4BadIDad4g+xI lvaFY1Ut/hMdZNkw0tzNZOdUPiO4jYIyirReAUiMCm6jXzkTRITj7/vxxWtPAAUR tDNSdXNzZWxsIEUuIFdoaXRha2VyIDx3aGl0YWtlckBldGVybml0eS5kZW1vbi5j by51az4= =LOCL -----END PGP PUBLIC KEY BLOCK----- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Thu, 8 Oct 92 19:40:31 PDT To: cypherpunks@toad.com Subject: Oct. 10 RSVP's Message-ID: <9210090247.AA02476@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain As of tonight, Thursday 10, the Saturday meeting is in two days. I'd like to get RSVP's from everyone who plans to attend, so that I know how many are going to be there. SEND ONE EVEN IF YOU THINK I KNOW THAT YOU'RE COMING! I can't keep everyone's attendance plans straight. Thanks. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Thu, 8 Oct 92 23:56:11 PDT To: cypherpunks@toad.com Subject: New feature of the remailer Message-ID: <9210090703.AA26448@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain New! Just finished. Fidonet support. Dumb mailer support. Incoming header line pasting. Here's what's going on. There are a lot of mailers, the Fidonet gateway in particular, which don't allow you to put arbitrary header lines in your outgoing messages. Previously people using these systems couldn't use the remailer because they couldn't put the necessary "Request-Remailing-To:" in the header. Now they can. Instead of putting header lines into actual header, I now support a syntax which allows header lines to be _added_ to the header on incoming mail. These extended header lines are in the body of the message proper, but a filter on incoming mail effectively adds them to the header. This allows anybody who can send me mail with a reasonably unmangled body to use any feature of the remailer that should ever get written. Example: ------- cut here ------- To: hughes@soda.berkeley.edu From: Secret_Squirrel@treehouse.com Subject: Mrs. Tree's secret recipe for pinole :: Request-Remailing-To: Crusader_Rabbit@rocky.moosylvania.org I just paid $2600 for this recipe [etc. etc.] [...] ------- cut here ------- If "::" is on the first body line all by itself, whatever lines follow up to the first blank line will be appended to the header when it is scanned for special instruction lines. This new feature is completely modular. It doesn't (seem to) break any of the other existing features. I'll post the source with an explanation tomorrow. In the meantime, try it out. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Peter Shipley Date: Fri, 9 Oct 92 00:14:13 PDT To: Eric Hughes Subject: Re: New feature of the remailer In-Reply-To: <9210090703.AA26448@soda.berkeley.edu> Message-ID: <9210090721.AA09749@edev0.TFS> MIME-Version: 1.0 Content-Type: text/plain Now what is needed is a user interface/script for submitting mail. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Peter Shipley Date: Fri, 9 Oct 92 01:42:20 PDT To: cypherpunks@toad.com Subject: my key Message-ID: <9210090849.AA09798@edev0.TFS> MIME-Version: 1.0 Content-Type: text/plain Here is my casual key, for a more secure key please contact an authorized dealer near you (Eric Hughes or I). -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQA9AirUzbUAAAEBfjC3p5COEUMJ3xzrq4sJCTaU5MgvzC94tp8yxxBJeKUGo7xx gMShBCnIZp+xlFiyxQAFE7QYUGV0ZXIgTSBTaGlwbGV5IChjYXN1YWwptCZQZXRl ciBNIFNoaXBsZXkgPHNoaXBsZXlAYmVya2VsZXkuZWR1Pg== =/Dhz -----END PGP PUBLIC KEY BLOCK----- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Fri, 9 Oct 92 09:43:05 PDT To: cypherpunks@toad.com Subject: The technical explanation of "::" incoming header pasting Message-ID: <9210091650.AA12173@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain There's a new feature in the remailing software. Some people can't add arbitrary header fields because of mailer or gateway restrictions. This restricts them from using the remailer. I have added a facility to allow new header fields to be pasted onto the end of a header when the mail arrives. This effectively happens before processing by the remailer software. These new fields exist during transit in the message body, where they remain untouched. Only after the message is delivered to my account does this operator take effect. Syntax: If the first line of the body is the two characters "::", then the following lines are appended to the header, up to the next blank line. Here's how it works. First of all, here's my new .maildelivery file: ------- cut here ------- # # field pattern action/ string # result (quote included spaces) # Request-Remailing-To "" pipe R "perl remailer/remail.perl" Request-Remailing-To "" file R remailer/archive * "" pipe R "/usr/local/lib/mh/rcvtty -biff" * "" pipe ? "perl remailer/incoming.header.perl" ------- cut here ------- Comments are indicated by #. The Request-Remailing-To lines have been there. The second of the makes an archive for debugging purposes. It will go eventually. The third field, "*", indicates all fields, it runs 'rcvtty' on my mail; this replaces the function of biff, since mail is getting piped to slocal now, disabling biff. The last line is the important one. It says "If the mail hasn't been delivered by now, run the incoming header rewrite script on it. If that doesn't work, continue trying to deliver it." Now here's the trick. slocal has no way of taking the output of the rewrite and continuing to process it. (It should. It would make this whole job easy.) So in order to continue processing, you need to redeliver the mail. You could invoke sendmail and mail it back to yourself, but that would mangle the existing header. So the thing to do is to recursively invoke slocal from within the perl script. Here's the perl script to do all this: ------- cut here ------- # First read in the whole header. # We check for the Second-Pass: line to detect infinite loops. while (<>) { last if /^$/ ; exit 1 if /^Second-Pass:/ ; $header .= $_ ; } # We have just read the last line in the header. # Now we check to see if there is a pasting operator. if ( ( $_ = <> ) && /^::$/ ) { while (<>) { last if /^$/ ; $header .= $_ ; } } else { # There is either an empty body or no pasting operator # Thus exit with a return code of 1 to indicate that # the mail has not been delivered. exit 1 ; } # There was a header pasting operator. # So we open 'slocal' as a pipe, effectively redelivering the mail # back to ourselves. #open( OUTPUT, ">foo" ) ; open( OUTPUT, "| /usr/local/lib/mh/slocal -user hughes" ) ; select( OUTPUT ) ; # print a "From " line to satisfy slocal @weekdays = ( "Sun","Mon","Tue","Wed","Thu","Fri", "Sat" ) ; @months = ( "Jan","Feb","Mar","Apr","May", "Jun","Jul","Aug","Sep","Oct","Nov","Dec" ) ; ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime ; printf "From hughes %s %s ", @weekdays[ $wday ], @months[ $mon ] ; printf "%2d %02d:%02d:%02d 19%d\n", $mday, $hour, $min, $sec, $year ; # Now just print out the message print $header ; print "Second-Pass:\n" ; print "\n" ; while (<>) { } continue { print ; } ------- cut here ------- Here's how the perl script works. The first loop reads lines from the existing header. When it sees a blank line (regexp /^$/) it terminates the loop. If it sees a field "Second-Pass", it knows it has filtered this message before and exits with a return code indicating that the mail has not been delivered. The variable $header is appended with the current header line. $header contains the whole header when the loop terminates. Properly speaking, the Second-Pass test is not necessary to detect infinite loops. Since the pasting operator gets removed during the rewrite, the script won't return an exit status of 0 more times than the pasting operator appears. But should something get screwed up, such as a different module adding pasting commands (how? I don't know), the Second-Pass test should prevent infinite recursion. The next statement reads another line from the input file. This line is the first line of the message body. If this line is the pasting operator, then header lines are accumulated in $header as before until a blank line. The difference is that these header lines are being read from the body of the message. If there is no pasting operator, the script exits undelivered. At this point we now have to redeliver the message back to ourselves. We first open slocal as the output pipe. The next section is a kludge. It turns out that slocal strips off the out-of-band "From " (no colon) line that the mail delivery system uses. In other words, the message which slocal pipes into its pipes is not identical to the message it itself received. This means that slocal cannot be directly recursed. What this section does is to create a "From " line to make slocal happy. It calls localtime() and then formats those numbers into the proper form. It turns out that slocal will deliver this mail without the "From " line, even to /usr/spool/mail, but it doesn't do so properly. On my system, in added some delimiters which I think I've tracked down to the 'mtstailor' file, namely mmdelivery1 and mmdelivery2. Since these are not null on my system, there's some garbage added which screws up separation of the spool file into messages. Adding a "From " line fixes that. This misbehavior may not be so surprising, considering that slocal was "meant" to be invoked only in a .forward file. Now we print the variable $header which contains the whole header, including newlines. Using a single string removes the need for an array. We added the Second-Pass line and a blank line for the end of the header. The final loop prints out the rest of the message body. There is another way to proceed to get the same functionality. One could write a filter to translate the first occurrence only of \n\n::\n into \n. We could then pass the message through this filter before slocal saw it. And for now, that would do the same thing. But suppose we want more that one rewrite rule active? Then you would only be able to apply each rewrite rule exactly once in fixed order. You want to be able to rewrite a message and then apply all the rewrite rules again. At least one other rewrite rule is planned: automatic decryption. Since decrypting a message will completely change the body, and since some of the header fields may need to be hidden, you have to be able to decrypt the body and then paste on header lines. But since you need to indicate an encrypted body by a header line (well, not really, but it's more reliable), and since some people can't add these header lines, you need to paste lines before encryption as well. Thus the rewrite rules need to be applied asyncronously and hence I'm using a fairly complex slocal scheme to do a simple filter. Eventually I hope to write an equivalent to slocal which knows about message rewrites and simple filters, but that's for later. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Fri, 9 Oct 92 11:13:54 PDT To: cypherpunks@toad.com Subject: re: +-=*^ Message-ID: <2747.2AD5CD4D@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain U> re: problem with key distribution; right, OK, I hadn't U> thought that there might be a security problem with U> casually giving someone your key without them being able U> to authenticate that it came from you. Good point. But as Eric pointed out, and I realized later, the underlying social structure will allow detection of bum keys (presuming the scammed person or someone s/he knows notices, etc, and so on, a wholew world resides here...) U> Here's my public key. If you feel it is not secure U> enough, we can always use the cone of silence: U> U> -----BEGIN PGP PUBLIC KEY BLOCK----- U> Version: 2.0 U> U> U> 23l1t34u U> -----END PGP PUBLIC KEY BLOCK----- Now I feel very unsecure, because the above is all I got. It ain't no public key... PS: Too much anonymity? I have to reply in hte mailing list to this person cuz it's a faked From... (trust me) * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Peter Shipley Date: Fri, 9 Oct 92 11:16:24 PDT To: Secret_Squirrel@treehouse.com Subject: Re: +-=*^ In-Reply-To: <9210091712.AA27717@atdt.org> Message-ID: <9210091823.AA11516@edev0.TFS> MIME-Version: 1.0 Content-Type: text/plain >re: Interface for re-mailer; why not hitch it to emacs or something? > that to... >re: problem with key distribution; right, OK, I hadn't thought that >there might be a security problem with casually giving someone your >key without them being able to authenticate that it came from you. Good >point. I look at it this way, by emailing my puplic key anyone can send me a secure message (I can't trust where/who it came from but we [the sender and I] can assume that noone is eavesdroping (it could have been replaced but not altered or read) For secure authenticated, where you *know* if came from me you have to contact me or someone you trust that has contacted me. -Pete From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nobody@soda.berkeley.edu Date: Fri, 9 Oct 92 12:20:07 PDT To: cypherpunks@toad.com Subject: Re: +-=*^ Message-ID: <9210091926.AA17103@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Since there has been complaints about the size of my public key here is a more secure 512bit version, please discard the prevous key -Secret_Squirrel PS: please redistribute this key asap. to others. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQBNAirV2r0AAAEB/i78BfdkmEIqKt2EhdlFAJc44rB3ZMzChez5zVcB9jRpUz1o MY2M2GnucGRUcvMSvZeF/aqCVIHuodDfqyGYYTkABRG0L1NlY3JldF9TcXVpcnJl bCA8U2VjcmV0X1NxdWlycmVsQFRyZWVob3VzZS5DT00+ =Byn9 -----END PGP PUBLIC KEY BLOCK----- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Secret_Squirrel@Treehouse.COM Date: Fri, 9 Oct 92 10:05:09 PDT To: cypherpunks@toad.com Subject: +-=*^ Message-ID: <9210091712.AA27717@atdt.org> MIME-Version: 1.0 Content-Type: text/plain re: Interface for re-mailer; why not hitch it to emacs or something? re: problem with key distribution; right, OK, I hadn't thought that there might be a security problem with casually giving someone your key without them being able to authenticate that it came from you. Good point. Here's my public key. If you feel it is not secure enough, we can always use the cone of silence: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 23l1t34u -----END PGP PUBLIC KEY BLOCK----- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Secret_Squirrel@Treehouse.COM Date: Fri, 9 Oct 92 12:51:41 PDT To: cypherpunks@toad.com Subject: Anonymity Message-ID: <9210091959.AA02274@atdt.org> MIME-Version: 1.0 Content-Type: text/plain Anonymity is good. Anonymity works. >> U> 23l1t34u U> -----END PGP PUBLIC KEY BLOCK----- Now I feel very unsecure, because the above is all I got. It ain't no public key...\ << Uh... it's kind of an inside joke. Uh. Sorry. Anyway, why would you want to reply only directly to me and not to the list in general? From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Secret_Squirrel@Treehouse.COM Date: Fri, 9 Oct 92 14:53:31 PDT To: cypherpunks@toad.com Subject: Ha ha Message-ID: <9210092201.AA05901@atdt.org> MIME-Version: 1.0 Content-Type: text/plain Whoah. That's helarious. NOT! Secret Squirrel does not cotton to imposters, and that sure as hell ain't my Public Key. So don't even bother trying to write any encrypted messages with it. My key remains: 23l1t34u -- SHRDLU From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: whitaker@eternity.demon.co.uk (Russell E. Whitaker) Date: Fri, 9 Oct 92 14:18:54 PDT To: cypherpunks@toad.com Subject: *Economist* on encryption Message-ID: <1632@eternity.demon.co.uk> MIME-Version: 1.0 Content-Type: text/plain The following is intended for limited-distribution, educational purposes only.... Citation: The Economist, Sept 21, 1991 v320 n7725 p104(2) COPYRIGHT Economist Newspaper Ltd. (UK) 1991 ---------------------------------------------------------------------- Title: A cure for the common code: computer cryptography. ---------------------------------------------------------------------- Subjects: Public key cryptosystems_Standards Digital signatures_Standards Data encryption_Research United States. National Institute of Standards and Technology_Laws, regulations, etc. Reference #: A11286848 ====================================================================== Summary: Advances in the mathematics of prime factorization algorithms have led to a technology that, once standardized, will dramatically improve public-key cryptography. The RSA algorithm is popular in the computer industry, but the government favors an alternative. ====================================================================== ANYONE can sign a postcard, but how do you sign a piece of electronic mail? Without a "signature" to demonstrate that, say, an electronic transfer of funds really comes from someone authorised to make the transfer, progress towards all-electronic commerce is stymied. Ways of producing such signatures are available, thanks to the technology of public-key cryptography. They will not work to everyone's best advantage, though, until everyone uses the same public-key system. It is an obvious opportunity for standards-makers - but in America they have turned up their noses at all the variations on the theme currently in use. The alternative standard for digital signatures now offered by America's National Institute of Standards and Technology (NIST) has brought a long-simmering controversy back to the boil. Public-key cryptography could become one of the most common technologies of the information age, underpinning all sorts of routine transactions. Not only does it promise to provide the digital equivalent of a signature, it could also give users an electronic envelope to keep private messages from prying eyes. The idea is to create codes that have two related keys. In conventional cryptography the sender and receiver share a single secret key; the sender uses it to encode the message, the receiver to decode it. In public-key techniques, each person has a pair of keys: a disclosed public key and a secret private key. Messages encoded with the private key can only be decoded with the corresponding public key, and vice versa. The public keys are published like telephone numbers. The private keys are secret. With this technology, digital signatures are simple. Encode your message, or just the name you sign it with, using your private key. If the recipient can decode the message with your public key, he can be confident it came from you. Sending a confidential message - putting electronic mail in a tamper-proof envelope - is equally straightforward. To send a secret to Alice encode it with her public key. Only Alice (or someone else who knows her private key) will be able to decode the message. The heart of any system of public-key cryptography is a mathematical function which takes in a message and a key, and puts out a code. This function must be fairly quick and easy to use, so that putting things into code does not take forever. It must be very hard to undo, so that getting things out of code does take forever, unless the decoder has the decoding key. Obviously, there must be no easy way to deduce the private key from the public key. Finding functions that meet these criteria is "a combination of mathematics and muddle", according to Roger Needham of the Cambridge Computer Laboratory. The greatest successes to arise from the muddle so far are those using functions called prime factorisation algorithms. They are based on the mathematical insight that, while it is easy to multiply two numbers together, it is very hard to work backwards to find the particular two numbers which were multiplied together to produce some given number. If Alice chooses two large prime numbers as her private key and publishes their 150-digit product as her public key, it would probably take a code-breaker thousands of years to work backwards to calculate her private keys. A variety of schemes have been worked out which use this insight as the basis for a workable public-key code. Most popular of these is the so-called RSA algorithm, named after the three MIT professors who created it - Ronald Rivest, Adi Shamir and Len Adleman. It has been patented and is sold by a Silicon Valley company, called RSA, that employs 15 people, most of them ex-MIT graduate students. Faculty firms are to computer start-ups what family firms were to the industrial revolution. RSA has attracted both academic praise and a range of heavyweight commercial customers: Microsoft, Sun Microsystems, Digital Equipment and Lotus Development. But, despite repeated applications, it has never been endorsed by those in government. Rumours abound that the code-breakers in the National Security Agency have discouraged standard-setters from recommending RSA because they do not want to promote the use of codes they cannot break. RSA, for obvious reasons, does not discourage the rumours. Whatever the reason, the standard-setters at the NIST have side-stepped the debate over RSA with their new algorithm, DSA. As set out in the standard, DSA verifies the identity of the sender, but does not encrypt the message. It appends to the message a number calculated from the message and the sender's private key. The recipient can then use this number, the message and the sender's public key to verify that the message is what it seems. The NIST says that this technique is well suited to "smart cards" and other applications where there is not a lot of computing power available for working out codes. Because it hopes that DSA Will be used for verifying the identity of everyone from welfare recipients to military contractors, its flexibility is a boon. Meanwhile, however, more and more companies are choosing a public-key cryptography system for communicating confidentially - often RSA, sometimes something different. Someday, probably soon, governments will want to choose, too. Watch out for fireworks when they do. ------------------end forwarded article-------------------------- Russell Earl Whitaker whitaker@eternity.demon.co.uk Communications Editor 71750.2413@compuserve.com EXTROPY: The Journal of Transhumanist Thought AMiX: RWHITAKER Board member, Extropy Institute (ExI) [.sig revised 1 October 1992 /// Send mail to eternity node] -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAiqwg10AAAEEAMVNMI766ljeuW01xqXKYYV5lmDPvb+6dCQK3m1iBQdan0no pm35j1DIRp3UJZogAe5eimsQg1TALDhTq310OZs9+L6B/HxeX3+4BadIDad4g+xI lvaFY1Ut/hMdZNkw0tzNZOdUPiO4jYIyirReAUiMCm6jXzkTRITj7/vxxWtPAAUR tDNSdXNzZWxsIEUuIFdoaXRha2VyIDx3aGl0YWtlckBldGVybml0eS5kZW1vbi5j by51az4= =LOCL -----END PGP PUBLIC KEY BLOCK----- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Angry_Poodle@BBQ.COM Date: Fri, 9 Oct 92 18:47:57 PDT To: cypherpunks@toad.com Subject: PGP Key Message-ID: <9210100155.AA12001@atdt.org> MIME-Version: 1.0 Content-Type: text/plain If you see any msgs from 'me' saying "here's my PGP PK key," then it's an imposter! I don't have a PGP key, much less PGP! -- Angriest Dog in the World. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: marc@kg6kf.ampr.org (Marc de Groot - KG6KF) Date: Sat, 10 Oct 92 03:07:47 PDT To: cypherpunks@toad.com Subject: a key Message-ID: <9210100755.AA05427@kg6kf.ampr.org> MIME-Version: 1.0 Content-Type: text/plain A key... -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQA9AirWaLMAAAEBgMlJILifxrXH8fkJwJbeSHXAY1Q9/AzPybGVy0Dx/q70Fr3d KhM6XoSEgaw2Ezzn2QAFEbQWTWFyYyBkZSBHcm9vdCAoY2FzdWFsKbQjTWFyYyBk ZSBHcm9vdCA8bWFyY0BrZzZrZi5hbXByLm9yZz4= =LL6T -----END PGP PUBLIC KEY BLOCK----- This is a casual key for me. Perhaps a causal key for me too. -Marc de Groot From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Sat, 10 Oct 92 01:59:50 PDT To: shipley@tfs.COM Subject: Re: +-=*^ Message-ID: <199210100906.AA26559@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain I've seen a number of postings so far about "secure *and* authenticated" requiring advance in-person distribution of key material. This would seem to eliminate the main advantage of public key systems, i.e. open distribution of public keys. So as long as we're handling key material in person, how about one-time systems, eh? Absolutely secure, provably so, obsolescence-proof, simple & straightforward. Not particularly exciting from a theoretical point of view, but one-time systems are practical and on the bottom line, they work. What do y'all think...? -gg@well.sf.ca.us From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: gnu@cygnus.com Date: Sat, 10 Oct 92 02:43:25 PDT To: cypherpunks@toad.com Subject: Better directions to the meeting on Saturday at noon Message-ID: <9210100950.AA28200@cygnus.com> MIME-Version: 1.0 Content-Type: text/plain Someone asked for better directions, and the original ones were pretty skimpy anyway. Here's a better try. Cygnus Support 1937 Landings Drive Mt. View, CA 94043 There's no phone service there yet. Take US 101 toward Mt. View. From San Francisco, it's about a 40-minute drive. Get off at the Rengstorff Ave/Amphitheatre Parkway exit. If you were heading south on 101, you curve around to the right, cross over the freeway, and get to a stoplight. If you were heading north on 101, you just come right off the exit to the stoplight. The light is the intersection of Amphitheatre and Charleston Rd. Take a right on Charleston; there's a right-turn-only lane. Follow Charleston for a short distance. You'll pass the Metaphor/Kaleida buildings on the right. At a clump of palm trees and a "Landmark Deli" sign, you can take a right into Landings Drive; this gets you into the complex from the north. Or you can go slightly further along Charleston and take the next right, into a driveway with a big "Landmark" sign in the middle. No matter which way you got into the complex, follow around it until you are on the side that faces the freeway. There's a clock tower that rises out of one of the buildings, to the right (south) of the deli. Enter through the doors immediately under the clock tower. They'll be open between noon and 1PM at least. (See below if you're late.) Once inside, take the stairs up, immediately to your right. At the top of the stairs, turn right past the treetops, and we'll be in 1937 on your left. If you are late and the door under the clock tower is locked, you can go to the deli (which will be around a building and left, as you face the door), cut between the buildings to the right of the deli, and into the back lawns between the complex and the farm behind it. Walk around the buildings until you see a satellite dish in the lawn. Go up the stairs next to the dish, which are the back stairs into the Cygnus office space. We'll prop the door (or you can bang on it if we forget). Or, you can find the guard who's wandering around the complex, who knows there's a meeting happening and will let you in. They can be beeped at 965 5250, though you'll have trouble finding a phone. Don't forget to eat first, or bring food at noon! I recommend hitting the burrito place on Rengstorff (La Costen~a) at about 11:45. To get there, when you get off 101, take Rengstorff (toward the hills) rather than Amphitheatre (toward the bay). Follow it about ten blocks until the major intersection at Middlefield Road. La Costen~a is the store on your left at the corner. You can turn left into the narrow lane behind the store, which leads to a parking lot, and enter by the front door, which faces the intersection. To get to the meeting from there, just retrace your route on Rengstorff, go straight over the freeway, and turn right at the stoplight onto Charleston; see above. See you there! John Gilmore From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Sat, 10 Oct 92 07:29:03 PDT To: cypherpunks@toad.com Subject: +-=*^ In-Reply-To: <199210100906.AA26559@well.sf.ca.us> Message-ID: <9210101436.AA00257@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain George recommends one-time pads. The key distribution problem for one-time pads is *much* worse than for public key systems, or even conventional secret key ciphers for that matter. You still have to exchange keys without transmission (i.e. face to face meetings again, or mail, etc.). Anything that is secure for exchanging a one-time pad is also secure for exchanging public keys. Then you have to do this again when your pad runs out. The bandwidth required for one-time keys is much higher than for conventional keys to boot. But the biggest advantage of public key systems is that I can sign someone else's key, and if you know my key, then you know his. To put it more humorously, you will have exchanged cryptographic fluids with everyone I have as well. This is a good thing. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Sat, 10 Oct 92 12:20:43 PDT To: cypherpunks@toad.com Subject: Directions! Message-ID: <2887.2AD7240A@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain Umm, directions never came. I think it's last minute, huh?! Can anyone tell me where Cygnus' new site is? * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Sat, 10 Oct 92 13:15:11 PDT To: cypherpunks@toad.com Subject: re: Better directions to the meeting on Saturday at noon Message-ID: <2889.2AD73B41@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain Things are not good here. I have to stay and deal with my best friend Deke who seems to be going nuts. (It's not a new story, but it heated up last night.) Now, at 1pm, I've gotta stay here another hour or so, and be back by 630, so I guess I'm gonna have to miss another. I'll see you all elsewhen (to borrow a Hugh-ism). * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Sat, 10 Oct 92 13:15:12 PDT To: cypherpunks@toad.com Subject: re: Re: +-=*^ Message-ID: <2890.2AD73B43@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain (to: gg@well.sf.ca.us) Thank you for clarifying my particular problem: what I was worried about was *authentication* not security. I had the two tangled up. Duh. With an informal email/introducer setup for the FidoNet, we'll have a fairly secure system with a reasonable level of authentification, practically speaking, with authentification to some high level doable on an individual basis. (Using PGP.) This probably as "good as it gets" in our (email) environment. * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hollander Date: Sat, 10 Oct 92 13:33:53 PDT To: cypherpunks@toad.com Subject: random Message-ID: <9210102041.AA04891@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain So when are we going to start alt.crypt, where we just post a lot of uuencode'ed random data? e From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Hal <74076.1041@CompuServe.COM> Date: Sat, 10 Oct 92 11:04:58 PDT To: CYPHERPUNKS Subject: Mr. Squirrel? Message-ID: <921010180751_74076.1041_DHJ61-1@CompuServe.COM> MIME-Version: 1.0 Content-Type: text/plain Hi, I've just joined this list. Interesting confusion about Mr. Squirrel. That's one of the problems with anonymity. How do you know you're talking to the right person? What you should do is to use a public key. The pseudonym is not really the name "Secret Squirrel"; anybody can use that. The pseudonym is the public key. Any message signed by that particular key is from that particular squirrel. Any message you encrypt in Squirrel's public key is readable only by him. If Squirrel changes his key, he should sign the message so you know it's really _that_ squirrel who's changing his key (and not some other squirrel telling people to use a new key). A pseudonym is a public key. Hal P.S. Here's my key, signed by PRZ: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.01 mQCNAiqsNkwAAAEEAMKWM52m5EWi0ocK4u1cC2PPyHT6tavk9PC3TB5XBYDegf3d sldRpnjJj1r+aO08FFO+QLEI9wtBqvf1PPP5iLX7sD2uIVlJH14MPtyVtjm9ZKb8 JMtCW74045BgtHBC9yQ3V7vXNV5jM6dE2ocnH4AI/pBFrGLJPKgTA69YIUw3AAUR tCZIYWwgRmlubmV5IDw3NDA3Ni4xMDQxQGNvbXB1c2VydmUuY29tPokAlQIFECqu M1Tidd4O/2f3CwEByrUD/3uoV2y+Fuicrrd2oDawgOw9Ejcx6E+Ty9PVPqKvflLs 0zYyGfeFVSgBbTSDP3X91N3F68nydl9J9VA6QRCGelHM1cZRukCJ0AYbKYfpwUN0 xjEGHsDrd2gT5iWlB3vBZvi+6Ybs4rSq+gyZzVm1/+oRrMen32fz2r0CLgUtHok2 =fF6Z -----END PGP PUBLIC KEY BLOCK----- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: d9mj@crux2.cit.cornell.edu Date: Sat, 10 Oct 92 17:55:26 PDT To: cypherpunks@toad.com Subject: [gg@well.sf.ca.us: Re: +-=*^] Message-ID: <9210110102.AA21921@crux1.cit.cornell.edu> MIME-Version: 1.0 Content-Type: text/plain Look at what my mailer did to your header. Is this a result of your perl script or my screwed router? Date: Sat, 10 Oct 1992 05:06:40 -0400 Illegal-Object: Syntax error in From: address found on router.mail.cornell.edu: From: George A.Gleason ^ ^-illegal period in phrase \-phrases containing '.' must be quoted X-Ph: V3.12@router.mail.cornell.edu >From: To: Secret_Squirrel@treehouse.com, shipley@tfs.COM Subject: Re: +-=*^ Cc: cypherpunks@toad.com [message deleted] From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Sun, 11 Oct 92 00:50:52 PDT To: hughes@soda.berkeley.edu Subject: Re: +-=*^ Message-ID: <199210110757.AA22987@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Eric, good point about public keys and trust by association. More on OTPs. You say the key distribution problem for OTPs is "much worse" than for PKS and even other conventional ciphers. "Much worse" in what ways? The need for F2F meetings with all possible correspondents is something which exists with conventional ciphers. The cost of key storage is trivial: a fraction of the cost of the yearly (or less frequent) travel to meet each correspondent in person. Consider replaceable hard drive cartridges (30 meg for about a buck a meg), digital cassette formats including applications involving videocassettes, and so on. Yes, as you say, you have to exchange keys each time you run out of key; but you can keep ten years' with of key (error: "worth" not "with") on hand if you like, taking up less physical space than a box of cookies. "Bandwidth required is much higher..." In what way? Certainly not in terms of transmission; a stream cipher is a stream cipher. Perhaps in that each plaintext character requires one key character? This is just another formulation of the "storage" issue: and again, if you have a stack of 30MB cartridges, who cares? Not like we're talking about punched paper tape. I do agree that PKS offer convenience and features not available with conventional ciphers. However, RSA is just one mathematical breakthrough away from being obsolete, and we have no way of knowing when that breakthrough occurs. It may also be that massively parallel processors can be built through VLSI technology, allowing the cost of brute force solutions to come down to a reasonable level. All of this is not by way of getting down on PKS. I would suggest that we need a number of different systems, and need to keep them all in fairly constant use. I think we're already all in agreement that one of those systems should be RSA-based. Now I'm just suggesting that a One-Time system should be another one among the many. BTW, sorry I couldn't make today's meeting; various local tasks demanding attention; plus physical travel distance. Be back next time... -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Sun, 11 Oct 92 11:52:09 PDT To: cypherpunks@toad.com Subject: [gg@well.sf.ca.us: Re: +-=*^] In-Reply-To: <9210110102.AA21921@crux1.cit.cornell.edu> Message-ID: <9210111718.AA24207@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain There is a bit of confusion about the various lists and addresses. My main address is hughes@soda.berkeley.edu. The remailer runs from this account. All the perl scripts are there. The account I use to maintain the mailing list is on toad.com, as well as the mailing list itself. Its software is nothing but sendmail; no perl scripts. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Sun, 11 Oct 92 11:52:00 PDT To: cypherpunks@toad.com Subject: one time pads In-Reply-To: <199210110757.AA22987@well.sf.ca.us> Message-ID: <9210111753.AA24487@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain George writes: The cost of key storage is trivial: a fraction of the cost of the yearly (or less frequent) travel to meet each correspondent in person. Let me emphasize _each_ in that sentence. One time pads are very expensive on a per-link basis than public key systems for this reason only. Per-link is one person-to-person link. Consider replaceable hard drive cartridges (30 meg for about a buck a meg), digital cassette formats including applications involving videocassettes, and so on. Suppose one cartridge per link. That's $30 per link. Per link, that's a _lot_ of money. "Bandwidth required is much higher..." In what way? Whatever channel you use to transmit keys on, be it 30 Mb cartridges or what, will be more efficiently used by an exchange which requires less storage. In the case of cartridges, the UPS cost to ship one is still only about 1/5 of the cost of a cartridge. A 3 1/2 inch floppy can be shipped for one or two ounces of postage. However, RSA is just one mathematical breakthrough away from being obsolete, and we have no way of knowing when that breakthrough occurs. It is also one breakthrough away from being known to be fully secure. Not only do we not know when that will happen, we don't know which will happen. It may also be that massively parallel processors can be built through VLSI technology, allowing the cost of brute force solutions to come down to a reasonable level. Look at the figures for best know factoring algorithms. Now estimate the total amount of silicon output per annum in the US and estimate it's computational ability. I think you'll find that it would still take on the order of years to factor a single 1024 bit modulus. The difficulty of hard problems and the scale of the solar system are two things which are both extremely difficult to get any intuition about. I would suggest that we need a number of different systems, and need to keep them all in fairly constant use. [...] Now I'm just suggesting that a One-Time system should be another one among the many. Here's the bottom line: More security, more cost. Perfect security is not worth the cost in time, effort, or dollars when the marginal cost of perfection is less than the marginal benefit. Even SWIFT, the international monetary wire transfer system, does not use one time pads for link encryption. Now here is a network which breaking into would be worth billions (that's thousands of millions, let me remind you). The chief executives of SWIFT exchanges keys by post. One time pads are useful for all sorts of things, but they are very expensive to use. They are useful in protocols for blinding and key exchanges. They do not seem to be useful for end-to-end link encryption, however. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Mon, 12 Oct 92 08:20:43 PDT To: cypherpunks@toad.com Subject: Next meeting: Nov. 21 Message-ID: <9210121527.AA23015@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain The next physical cypherpunks meeting was decided on Saturday at that meeting. It will be Saturday, November 21, starting at noon at the Cygnus Support offices in Mountain View. I am announcing the date now so that you can put it on your calendar. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: whitaker@eternity.demon.co.uk (Russell E. Whitaker) Date: Mon, 12 Oct 92 02:29:15 PDT To: cypherpunks@toad.com Subject: More on packet radio encryption Message-ID: <1778@eternity.demon.co.uk> MIME-Version: 1.0 Content-Type: text/plain This article was forwarded to you by whitaker@demon.co.uk (Russell E. Whitaker): --------------------------------- cut here ----------------------------- Path: eternity.demon.co.uk!demon!pipex!unipalm!uknet!doc.ic.ac.uk!agate!spool.mu.edu!sgiblab!public!grady From: grady@public.BTR.COM ( ) Newsgroups: alt.privacy Subject: packet radio encryption Message-ID: <8113@public.BTR.COM> Date: 11 Oct 92 19:41:12 GMT Organization: BTR Public Access UNIX, MtnView CA. For info contact: info@BTR.COM Lines: 52 Bill Stewart (wcs@anchor.ho.att.com) writes, in part: [...Unlike the AX.25 link protocol specified by FCC rules, the higher level protocols are not required to be plain-text...] Do you have a reference for this? And does this apply to the contents, the protocols, or both? (E.g. can you use a crypto-based presentation layer protocol and plain-text payload, or vice versa?) ---- The definitive reference is Part 97 of the FCC rules (available from the US Government Printing Office, Washington, D.C. 20402. Phone orders: 202 783 3238. Ask for "Code of Federal Regulations" 47 CFR 80 to End.) To summarize the rules, except for certain remote control operation as space or repeater machines, nothing can be transmitted with the intent that the meaning be obscured. Conversely, text compression, for example, is legal because, although the plaintext is certainly obscured, it wasn't the _intent_ of the LZ or Huffman or whatever coding to conceal the meaning. Likewise with UUencoding and a host of other compression/ error detection and correction schemes that incidentally involutes the plaintext to some more efficient transmitted form. Spread spectrum is treated somewhat more restrictively since for that mode you may be required to produced the logs and the content of the messages. But not so for narrow- band FM packet. To sum up, using cryptography in general is prohibited. (However, digital signatures are OK, even though based on MD5 or SHA as long as the intent is not to _obscure the meaning_ of part of the transmitted message.) Clearly, though, the burden of proof is upon the FCC to show that a particular message _was_ encrypted, since there is _no_ theoretical, a priori way that an encrypted data stream can be distinguished from one merely well compressed or, just for that matter, random. Of course you should verify this with an attorney if you are troubled with fears of prosecution. Grady Ward KD6ETH/AA -- Grady Ward grady@btr.com Moby Lexicons --------------------------------- cut here ----------------------------- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: ravi@xanadu.com (Ravi Pandya) Date: Mon, 12 Oct 92 13:46:47 PDT To: cypherpunks@toad.com Subject: The subject of Saturday's game Message-ID: <9210121942.AA03720@xanadu.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain I just joined the list; I've read such archives as are locally available, but I apologize if this subject has already come up. Talking to a couple of people who had been to Saturday's meeting, I was deeply disturbed by the choice of subject for the simulated privacy game - trying to purchase illegal drugs. This is a subject on which rational public discussion is essentially non-existent in this country. Let me first state that I do favor the legalization of drugs, and I am a committed libertarian (as I suspect are many of the people in this group). However, I think it is unwise to tie cryptography in with this issue. Communications privacy is *too important* to take the risk that it will get caught up in the current hysteria of the New Prohibition. There have already been enough government attacks on cryptography that we do not want to give them any more ammunition. I think that if we are committed to getting cryptographic technology in wide use, and spreading true privacy and information security throughout the world, then we need to take careful account of the political and social factors, as well as the technical. In order to be successful, this needs to be not just a development project, but also a marketing campaign. When an MIS manager at some large corporation is deciding whether to upgrade her network to privacy-enhanced mail, we want her to associate it with security and liberty, not the street corner punks who are trying to sell her kids crack. In this vein, let me suggest some subjects for future simulations: - organizing the Boston Tea Party in the face of British spies and informers - purchasing condoms or Lady Chatterley's Lover back when they were banned (these bans seem so absurd now, that trying to get around them seems sensible and ordinary, and may start people thinking about the absurdity of current interdictions) - Yeltsin/Gorbachev vs the coup leaders Furthermore, given the erosiion of constitutional protections in the Drug War, I think the participants in Saturday's game were taking a non-trivial risk to their persons and property. If the risk were necessary to help spread cryptographic privacy, I think none would begrudge it; however, I think it was not only unnecessary, but counterproductive. 'Nuff said. To life and liberty, --ravi From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tribble@xanadu.com (E. Dean Tribble) Date: Mon, 12 Oct 92 15:09:10 PDT To: uunet!xanadu.com!ravi@uunet.UU.NET Subject: The subject of Saturday's game In-Reply-To: <9210121942.AA03720@xanadu.xanadu.com> Message-ID: <9210122148.AA05516@xanadu.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain Excellent message. I agree with your points about drugs. I also like the organization topics you suggest for the game. In this vein, let me suggest some subjects for future simulations: - organizing the Boston Tea Party in the face of British spies and informers - purchasing condoms or Lady Chatterley's Lover back when they were banned (these bans seem so absurd now, that trying to get around them seems sensible and ordinary, and may start people thinking about the absurdity of current interdictions) - Yeltsin/Gorbachev vs the coup leaders On the victory conditions. Right now, the game is declared over as soon as any party accomplishes their objective. This creates the incentive to prevent other people from accomplishing their objective, even if it would help me accomplish mine. The use of topics like the above gives clearer victory conditions: One side or the other wins, even though that side only loosely includes any particular participant in the game (an informer wins if either his nominal side wins without his duplicity being revealed, or if the opposition wins). A plausible generic form of victory condition is for one 'side' to succesfully transact some secure exchange, or for the other 'side' to successfully break such a secure transaction. I don't know how to allow decoys with this model of victory. Hmmm... To life and liberty, Da. dean From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Mon, 12 Oct 92 15:40:05 PDT To: cypherpunks@toad.com Subject: Game items In-Reply-To: <9210121942.AA03720@xanadu.xanadu.com> Message-ID: <9210122247.AA01207@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Re: drugs and simulation games. At the meeting last Saturday, we played the second incarnation of the remailing simulation game. In a nutshell, the game is intended to teach people about how to protect their privacy by using encryption to prevent against monitoring and by using remailing to protect their identities. Since the game is also in part an economic simulation, I tried to pick game objects which someone had some interest in keeping quiet. I picked drugs, of unspecified name, as a prominent game item. This, by wide acclamation, is a mistake. Since the primary reason to pick this was a paucity of imagination, I now ask for help from the list. We want to develop a list of game items, physical objects, which will be the goods of transaction. I would like to pick objects that have been illegal in the past, but which are not anymore. They should not be primarily information, such as copies of _Ulysses_. They should not now be restricted. Nor should they be weapons, such as crossbows or samurai swords. They should, however, be objects that are known to have generated some emotional reactions in the past. There are two suggestions that meet these criteria: contraceptives and printing presses (or xerox machines). I would like to find more. Please make your suggestions. Another possibility is to use items which have been the subject of state-enforced monopolies in the past, such as pepper or nutmeg. Be creative. We'd like to get a good list of twenty or so items. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: efrem@spitha.informix.com (Efrem Lipkin) Date: Mon, 12 Oct 92 20:56:33 PDT To: cypherpunks@toad.com Subject: Re: drugs and simulation games. Message-ID: <9210130254.AA04987@spitha.informix.com> MIME-Version: 1.0 Content-Type: text/plain Unfortunately the first two things which come to mind are: coffee (a drug - actually an excuse for gathering) papers on public key cryptography (primary information) radios - illegel in Russia and I believe elsewhere during WWII East German typewriters - I had one Also a slight deviation: many medicines (and soon herbal contraptions) which are doctor monoply items here, but over the counter in most other countries. Religious artifacts of any number of banned religions. Divorce (opps, not a physical object). Really on thinking about it, I believe that the trade of ideas is always far more repressed than the trade in any kind of stuff. --Efrem Re: > We want to develop a list of game items, physical objects, which will > be the goods of transaction. I would like to pick objects that have > been illegal in the past, but which are not anymore. They should not > be primarily information, such as copies of _Ulysses_. They should > not now be restricted. Nor should they be weapons From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tribble@xanadu.com (E. Dean Tribble) Date: Mon, 12 Oct 92 21:57:42 PDT To: uunet!spitha.informix.com!efrem@uunet.UU.NET Subject: drugs and simulation games. Really on thinking about it, I believe that the trade of ideas is always far more repressed than the trade in any kind of stuff. In-Reply-To: <9210130254.AA04987@spitha.informix.com> Message-ID: <9210130425.AA01334@xanadu.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain --Efrem > We want to develop a list of game items, physical objects, which will > be the goods of transaction. I would like to pick objects that have > been illegal in the past, but which are not anymore. They should not > be primarily information, such as copies of _Ulysses_. They should > not now be restricted. Nor should they be weapons We definitely should have physical goods because the interface between an information world (in which privacy and anonymity can be completely protected) is where much of the complexity lies in managing things like cryptographic money. dean From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hollander Date: Mon, 12 Oct 92 21:56:16 PDT To: ravi@xanadu.com (Ravi Pandya) Subject: Re: The subject of Saturday's game In-Reply-To: <9210121942.AA03720@xanadu.xanadu.com> Message-ID: <9210130503.AA15950@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain That was a really good point. Keep separate issues separate so as not to alienate people. e From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Tue, 13 Oct 92 01:14:58 PDT To: hughes@soda.berkeley.edu Subject: Re: one time pads Message-ID: <199210130821.AA03658@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Good hard critique, Eric! Now if I might try to salvage my position... "One time pads are very (much more) expensive on a per-link basis than public key systems..." Yes, of course. However I don't envision OTPs as a standard for bulk encryption on large networks. Rather, for person-to-person communication in small networks. Examples: a group of civil rights attorneys suing the Federal govt., an international environmental organisation's main offices in the capital cities of a small number of countries, etc. Cases where the adversary is one or more powerful governments, and the number of links required is relatively small. Given the nature of the relationships between these kinds of networks and their adversaries, the expense would seem to be justified; in any case, the **incremental** cost of for instance a set of 30MB cartridges as compared to a few floppy discs, is an minor fraction of the cost of the airline tickets and other expenses for trusted couriers. (oops: "a minor fraction...") Your discussion of bandwidth can be met with a similar counter-arguement. First of all, I would reject the use of UPS or (God help us) the *Post Office* as a courier, particularly where one or more governments may be the adversaries against whom protection is needed. So your reference to those carriers is not relevant to the main point of my case. I'm assuming that key materials are transported by trusted courier and are guarded by same until they reach their intended recipient. Okay, that *really* drives up the cost, doesn't it...? Not if the key materials "hitch hike" on an existing travel plan: attorney A flies out to city B to visit attorney B... and happens to carry key material onboard in his/her shoulder bag. No added cost except for the storage devices, and that is not significant. Re mathematical breakthroughs in factoring etc, you say, "we don't know when that will happen, and we don't know which will happen." Exactly my point. *We* don't know. But the NSA and so on, most certainly do know, and they won't be telling. If the breakthrough comes, then the period between that point and the point when it is publicised, will be one of false security. Was it Kahn who said nothing is more dangerous than a bad cipher? My point here comes down to nothing more or less than the principle of caution in the face of an unknown. (Discussion of relative cost of brute force solutions, and the question of hard problems and scale.) I agree that my intuition about these things may be highly flawed. However this doesn't invalidate my point about the possibility of basic breakthroughs happening behind closed doors. Now in a way I'll admit that my arguement here sort of comes down to a black box. However, again I would assert that there are cases where the almost irrational caution is worthwhile. You say in concluding, "Perfect security is not worth the cost in time, effort, or dollars when the marginal cost of perfection is less (do you mean more?) than perfection." You cite examples of international banking systems. I would cite examples of political movements which have been sabotaged and destroyed by government covert action. One need not look far to run into COINTELPRO and the more recent French govt action of blowing up a Greenpeace vessel. Where your adversaries are the intelligence agencies of world powers, and where lives are at stake, I would say the cost of perfect security is justified. Now of course, the French terrorist bombing, the destruction of Black nationalist and student organising groups in the US, and other examples, may not (probably would not) have been prevented altogether by adoption of perfect communications security. Che Guevara after all used OTPs, and it was radio direction finding and traffic analysis (rather than cryptanalysis) which ultimately led to his murder by US-backed mercenaries. If we are promoting a tendency which is inherently political, it implicitly recognises governments as its adversaries. Our choices of cryptographic systems should reflect a wide range of applications and not exclude some a-priori on grounds of cost or convenience. -George (gg@well.sf.ca.us) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Tue, 13 Oct 92 01:49:34 PDT To: hughes@soda.berkeley.edu Subject: Re: Game items Message-ID: <199210130856.AA05294@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain The examples I always refer to are Federal civil rights suits naming the Federal govt as defendant, and international ecological organisations conducting whatever business they may be engaged on. These may or may not fulfill the game objectives, and they do tend to suffer from being a bit mundane perhaps to the point of being unexciting. However they are historically relevant and probably will be so in the future. Another possible topic would be womens' access to abortion, though given the coming change in our govt this may be irrelevant. How about GIFs depicting sex between consenting adults? Corporate proprietary information on new technology, in an age of increasing international competition (in this case the physical prototypes as well as information about same). International intrigues are always interesting: small countries seek to combine economic power against large countries, that kind of thing. -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: hugh@domingo.teracons.com (Hugh Daniel) Date: Tue, 13 Oct 92 05:02:06 PDT To: CYPHERPUNKS@TOAD.COM Subject: Mr. Squirrel? Just who is whom here? In-Reply-To: <921010180751_74076.1041_DHJ61-1@CompuServe.COM> Message-ID: <9210131201.AA12086@domingo.teracons.com> MIME-Version: 1.0 Content-Type: text/plain Hal is somewhat right, anyone can use 'Secret Squirrel' and anyone can use any public key they want also. So, in a many-to-one scope (as in a maillist) where the sender can not use the one-on-one signed signiture method how do we have proff of who the sender really is? Maybe public forums are just not places where it is easy to verify the identity of a speaker? A second thing that Hal's comments bring up is that we were reading the From: headders and ignoreing the keys. In good crypto-mail readers the key ought to be checked against our own data base of others keys and the result added to the hedders as say: KeyCheck: FooBar Bazoid holds this key in XXX database or some such rot. I wonder what is more important, who I claim to be in a random message or what key I include... New keys ought for an ID (or new ID's for the same key) should be added to the data base as well. But all this needs to be done automaticly by the mailers and interfaces, else the system will be mis-used and folks will tire of the extra work that gets them little advantage. ||ugh Daniel From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Tue, 13 Oct 92 08:51:51 PDT To: cypherpunks@toad.com Subject: one time pads In-Reply-To: <199210130821.AA03658@well.sf.ca.us> Message-ID: <9210131558.AA25287@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Previously I said about one-time pads: "High security, high cost." (Well, not exactly that...) I invoked it then in order to argue that I personally didn't need to use one-time pads. Implicit also in that statement is the claim that when the worth of security is high, the cost may be relatively cheap. George and I agree on this point. When you are fighting a military battle, when you have a government pissed off at you in a serious way, you need as good as you can get. Since you can get perfect end-to-end link encryption, you use it. All cryptography is economics. Repeat after me. All cryptography is economics. I don't need one-time pads. Sendero Luminoso does. It's as easy as that. It's merely a matter of scale. Large scale, high security. Small scale, pretty good security. Re: Mathematical breakthroughs. George missed my main point here. We don't know whether factoring is "fundamentally hard." (Project your own definition here.) We should not assume that when the breakthrough comes, that is will be found "easy." It may be that factoring is hard, and that RSA is secure for that reason. (The astute reader will see that these two are not exactly the same question.) My current thinking is that factoring is hard because of various randomness properties of primes, that in fact multiplying one large prime by another is like encrypting one prime with the other as a one-time pad! But I'm no number theorist. I do, however, agree with "caution in the face of an unknown." And for high stakes, George's "irrational caution" is not irrational at all. Re: Relative security. It seems I had an editing error. What I meant to say (paraphrased) was the following. Perfect security is not worth the cost when the marginal cost of perfect security is more than the marginal benefits of such security. This encompasses both the high end and the low end. I don't need one-time pads. Abu Nidal does. Repeat after me. Cryptography is all economics. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Tue, 13 Oct 92 09:03:14 PDT To: CYPHERPUNKS@TOAD.COM Subject: Mr. Squirrel? Just who is who here? In-Reply-To: <9210131201.AA12086@domingo.teracons.com> Message-ID: <9210131610.AA25466@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Hugh asks how, in a broadcast network, we may verify identity. The answer is "statistically." Not everyone needs to verify each message; only those who communicate with the sender personally (and who thus know the private keys) need to. Hugh mentions the "one-on-one signed signature method" and that it is not applicable to broadcast. Well, signing the whole message is not, but signing a message digest is. This is the whole reason for message digests, that a message may go out in cleartext, but the validating information for that message be encrypted. Thus everyone can read the message, even without knowledge of the public key, but it is possible to verify the identity if you know it, i.e. you know the private key. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Tue, 13 Oct 92 09:15:29 PDT To: CYPHERPUNKS@TOAD.COM Subject: Mail headers In-Reply-To: <9210131201.AA12086@domingo.teracons.com> Message-ID: <9210131622.AA25597@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Hugh's comments brought up a idea to me. RFC 822 is the standard for the format of Internet mail messages. Anybody interested in the remailer should eventually read this thing. In it there is already a standard header field "Encrypted." It accepts two optional arguments, a decryption type and an identifier (say, for key lookup). So we have a way of automatically telling encrypted message without doing pattern recognition on the body. I propose a couple more header fields. "Digest" for signed message digests. "Key-Mgmt" for the distribution of new keys and key compromise certificates, i.e. for automatic key distribution. What else do we need to make a fairly automated crypto mail system? Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: gnu@cygnus.com Date: Tue, 13 Oct 92 10:53:19 PDT To: Eric Hughes Subject: Re: Mail headers In-Reply-To: <9210131622.AA25597@soda.berkeley.edu> Message-ID: <9210131800.AA10408@cygnus.com> MIME-Version: 1.0 Content-Type: text/plain We have standards already for a fully encrypted email system. It's called PEM, Privacy Enhanced Mail. It'd be completely senseless to come up with a different format at this point, as PEM is on the verge of deployment. John From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hollander Date: Tue, 13 Oct 92 11:30:35 PDT To: Hal <74076.1041@compuserve.com> Subject: Re: Mr. Squirrel In-Reply-To: <921013154244_74076.1041_DHJ92-2@CompuServe.COM> Message-ID: <9210131837.AA28968@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain The most pressing thing is not to integrate encryptions in mail handlers, but at the level of ether. Ether is an enormous security hole. I can walk up to anything running ether with my notebook, plug in, and listen to all traffic. Therefore, ether cards need public key encryption built in, so they can communicate with eachother in a secure way. This also applies to all other low level protocols. e From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Hal <74076.1041@CompuServe.COM> Date: Tue, 13 Oct 92 08:55:18 PDT To: CYPHERPUNKS Subject: Re: Mr. Squirrel Message-ID: <921013154244_74076.1041_DHJ92-2@CompuServe.COM> MIME-Version: 1.0 Content-Type: text/plain ||ugh Daniel raises some questions about using public keys to verify pseudonyms: > Hal is somewhat right, anyone can use 'Secret Squirrel' and anyone > can use any public key they want also. But, once person A creates public key X, nobody else can sign messages using X. So if all messages from A are signed under X, we can know that they are all from the same person, even if they are sent anonymously or under a pseudonym. > So, in a many-to-one scope (as > in a maillist) where the sender can not use the one-on-one signed > signiture method how do we have proff of who the sender really is? You can use signatures even in a many-to-one scope. Messages from a particular person could be signed and the signature appended to the message. Then anyone who has the public key can check to see who the message came from. The process is a little unwieldy now in PGP because you have to separate the signature and message into separate files and run PGP on the signature file. This should be streamlined. > [Good points about keeping track of key-pseudonym pairs] > But all this needs to be done automaticly by the mailers and > interfaces, else the system will be mis-used and folks will tire of > the extra work that gets them little advantage. Absolutely. The most crying need now, IMO, is to better integrate the cryptographic tools into mail readers and senders, so that it's not such a pain to use these things. People should be able to give a single command or press a button to decrypt an incoming message or encrypt an outgoing one. Only then will these features be used by average people. There was a message posted on alt.security.pgp describing how to use PGP with the Emacs mail reading program. I'd like to see more messages telling how to use it with other systems. Hal 74076.1041@compuserve.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Tue, 13 Oct 92 08:58:32 PDT To: hugh@toad.com Subject: Mr. Squirrel? Just who is whom here? In-Reply-To: <9210131201.AA12086@domingo.teracons.com> Message-ID: <9210131550.AA03941@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: hugh@domingo.teracons.com (Hugh Daniel) > A second thing that Hal's comments bring up is that we were reading >the From: headders and ignoreing the keys. In good crypto-mail >readers the key ought to be checked against our own data base of >others keys and the result added to the hedders as say: > KeyCheck: FooBar Bazoid holds this key in XXX database >or some such rot. I wonder what is more important, who I claim to be >in a random message or what key I include... Anyone can include your key in a random message. If you just sign your messages, then the whole thing goes away and everyone knows its from you. PGP allows you to sign messages without encrypting them. The problem is that most people find using PGP on routine email inconvenient. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Tue, 13 Oct 92 11:49:36 PDT To: cypherpunks@toad.com Subject: Mr. Squirrel In-Reply-To: <9210131710.AA20497@bsu-cs.bsu.edu> Message-ID: <9210131856.AA29470@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain A signature on a message is dependent on the contents of the message; it is not a free floating bit of information. You can't copy a signature, therefore, without copying the message or find another message that hashes to the same value. This is the design criterion behind one-way functions--that you can't (feasibly) find a message that hashes to a given value. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Tue, 13 Oct 92 19:52:16 PDT To: cypherpunks@toad.com Subject: Integrated privacy... Message-ID: <2931.2ADB225F@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain U> Absolutely. The most crying need now, IMO, is to better U> integrate the cryptographic tools into mail readers and U> senders, so that it's not such a pain to use these things. U> People should be able to give a single command or press a U> button to decrypt an incoming message or encrypt an U> outgoing one. I just completed (well, it's in "beta") a mail-reader package for MSDOS and FidoNet. It does "rm" type stuff, and has PGP integrated reawonably well. Single character commands to decrypt, encrypt, sign, or encrypt/sign. It furnishes the distributed PGP.EXE program with it's imput (deriving it from the message itself). It'll extract keys from messages, and all that. It's MSDOS and .MSG-type FidoNet message base oriented, but it does all it's work in pure ASCII (FidoNet .MSG files are mixed binary and text). It is intentionally "RFC-822 like", and will become fully RFC-822 "soon". I was reasonably careful regarding de-cyphered plaintext laying about on disk, etc. It's available via Wazoo filerequest as magicname RM. (That's probably as obscure to you as FTP is to FidoNet.) It will be released as "copyleft" with all sources. Binaries only this week til I get it shaken down. * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nowhere@bsu-cs.bsu.edu (Chael Hall) Date: Tue, 13 Oct 92 10:04:24 PDT To: cypherpunks@toad.com Subject: Re: Mr. Squirrel In-Reply-To: <921013154244_74076.1041_DHJ92-2@CompuServe.COM> Message-ID: <9210131710.AA20497@bsu-cs.bsu.edu> MIME-Version: 1.0 Content-Type: text/plain >But, once person A creates public key X, nobody else can sign messages >using X. So if all messages from A are signed under X, we can know >that they are all from the same person, even if they are sent anonymously >or under a pseudonym. Who's to say that person B sees a message signed under X by person A. He copies the signature (X) onto the bottom of one of his messages and everyone thinks they can verify that it's from A but it's really from B. (makes sense to me anyway...) Chael Hall Chael Hall | Campus Phone Number iuvax!bsu-cs!nowhere | (317) 285-3648 00CCHALL@bsuvax1.bitnet | iuvax!bsu-cs!bsu-ucs!00cchall | "I hate it when that happens!" From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: gnu Date: Tue, 13 Oct 92 12:12:29 PDT To: George A. Gleason , cypherpunks Subject: Re: one time pads In-Reply-To: <199210130821.AA03658@well.sf.ca.us> Message-ID: <9210131912.AA14835@toad.com> MIME-Version: 1.0 Content-Type: text/plain One time pads don't provide perfect security, George. They only provide perfect security if the opponent doesn't know the contents of the pad. Given that most small organizations are in locations that are easily burglarized, ``when lives are at stake'' it would be easy for governments to break in, copy the storage medium containing the pad, and then read all past and future traffic encrypted with that pad. All cryptography is economics. If you make it harder to tap your phone lines, but it's cheap to break in, they'll do that. There is no absolute security this side of the grave (and who knows about the other side). John From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Tue, 13 Oct 92 19:52:16 PDT To: cypherpunks@toad.com Subject: PGP implementation for FidoNet Message-ID: <2932.2ADB2261@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain There's a conference in FidoNet called PUBLIC_KEYS, devoted to PGP and surrounding issues. Most evreyone is enthusiastic but without security experience. As always, we find that the prevailing "right ways to do things" don't fit. FidoNet's main need is "privacy", not "Security". What would be considered very low "security" in traditional circles would be more than adequate. (And of course the usual ways work just fine with a for "real" security needs.) Follows is an article I ran in FidoNews, the weekly FidoNet newsletter. I hoep it makes sense. The FidoNet environment is a little different than other nets. * Security and authentication using PGP in FidoNet THOUGHTS ON SECURITY AND AUTHENTICATION FOR EMAIL SYSTEMS Tom Jennings (1:125/111) Some ideas on public key security systems. To sum up ahead of time, I assert that the public broadcasting of public keys is more than enough security and authentication for casual, privacy needs in the FidoNet or other email network. All of this article assumes the use of PGP version 2.0, the RSA double-key encryption system implemented as freeware. This is all new to most of us, this security/privacy thing. Both technologically and socially. What privacy we have we take for granted without much thought; letters in envelopes, "who is it?" to knocks on the door, etc. When we try to break down these things into their underlying assumptions, well, it's hard. We shouldn't get upset with ourselves or others if "we don't get it" right away. And we'll find some obvious things aren't, and vice versa. I will assume that if you really, really need utter absolute security, you can achieve that with PGP or whatever. If it's that sensitive, sending it over an electronic medium probably isn't recommended. This article isn't about how to achieve bank-vault security. Within the FidoNet, the most common use we all seem to talk about is PRIVACY, rather than SECURITY. I can only speak for myself, but, my netmail (not echomail) traffic is probably a reasonable example. I read about 100 messages a week, and send out about 50. There's a dozen or so people I talk with regularly, and about 50 per week that I do not know. Most of it is of the "Oh yeah, so and so said this. How's your mother. Did you get that file OK...". Even if an eavesdropper read this stuff, I would barely care. There are some times though when revealed message contents could be... personally compromising. Embarrassing. A real life example: a long time ago, a sysop in a net was having trouble with their net host. Some messages critical of that net host were intercepted by the host, some passed on, and some we each got replies to! Not Good. What *I* want is a way to ensure that sometimes, only the addressee can read a given message. I am willing to pay some penalty for this, but I won't live with a system that restrains me like a stone castle and moat. My needs and risks just aren't that great. With that as a background assumption, let's look at two separate issues that look at first to be the same -- SECURITY and AUTHENTICATION. SECURITY -- given an encrypted message, how likely is it that someone can ascertain what's inside it (assuming you're not the addressor or addressee)? As an operating assumption, I will take it for granted that PGP produces files that are secure in themselves (barring bugs, etc). Like the docs say, a frontal cryptological assault is hard, and in our casual privacy case, probably not what we've got to worry about. There are other ways to figure out what's going on. Imagine you're that net host. You've had trouble with this particular sysop before. You notice he's just sent a flurry of messages to the local RC, then the ZC. Hmmm!! Do you really need to know what's in those messages?! (This is called traffic analysis. In pre-WWII Germany, the Nazis tracked down "Jew sympathizers" with traffic analysis of telephone billing information; Europeans don't get itemized phone bills any longer... like here in the US. So I was told, the information is no longer kept. (Do I really believe that...:-)) Anyways, security is more than cryptographic strength. Turns out, there's a way around this: anonymous remailers. In a private Internet mailing list Eric Hughes came up with a trick to anonymously remail messages; you send mail destined for system X to the remailer instead; it strips off the header info and mails it to system X. Anonymity isn't really needed though in the case above, simple remailing will do. Again, our *general* FidoNet needs are modest. AUTHENTICATION is the sticky one for us. Authentication is determining: is this person really the person they say they are? But I think you'll see it isn't the fatal problem it appears to be at first. Let's get the obvious case out of the way first again: if you need utter and absolute security, you better damn well know the person ahead of time, you should get a key delivered by hand, and you should think about if you really want to conduct business over an electronic link in the first place. Authentication in this case isn't -- or shouldn't be! -- a problem. For our relatively-casual privacy use, authentication is almost moot. Some people I have already exchanged keys with, *I've never met face to face in my life* and may never. In spite of this I feel I know them. I trust or assume that they are who they say they are. This is the environment we need to work in. This, plus the fact that we've got (at the moment) some 16,000 potential keys, means we simply can't do the full-blast security thing. How much "security" can I expect, or need, with someone I've never met? Consider again the utter-security case again. But the bottom line is in fact already taken care of, PGP or not -- how do you know that "the real Tom Jennings" wrote this article? Our underlying social system, so frequently overlooked, takes care of it. You can assume I, and many people who have been in the net, are verifiable. You have a number of ways to determine if I really wrote this article. Simply asking via FidoNet will uncover most fakes. Looking at old nodelists to see what info on my name has changed. Ask people who might know me. And so on. If our public keys are scattered to the wind like plants scatter pollen, it is certainly possible that I could fake "your" public key, and gain access through all the methods discussed in detail in the literature. However, assuming the real person and the fake person(s) are both generating keys (and using them to sign and send messages), the more keyrings were passed around the chances of detecting the incompatible keys becomes almost certain. At that point, even a casual effort would be able to track it down, to at least determine that there *was* a fake. Example: Mary has been using PGP for a few months, and conversing with friends and acquaintances. Her public key is filerequestable, and probably appears on a hundred keyrings. Over the next few months, other people get messages from "Mary" making increasingly odd claims, via encrypted mail. The impostors fake key, in order to be useful at all, would also have to be widely distributed. Curious, someone sends Mary a message encrypted with what appears to be her public key, and a plaintext one telling her that the cyphertext was encrypted with her public key, and that he suggests if she can't decipher it someone may have faked her key. What Mary actually does depends on many things. If she has indeed been creating the crazy messages, well, the problem's elsewhere. If she finds she can't read the message, her recourse depends on what is available to her: if there are public key repositories, she would be advised to contact them and notify them of the alleged faked key(s), and follow whatever process is setup to generate a new key. The very knowledge of key collision would be enough to flag to users that there's a potential problem. There are more practical issues that limit our need for traditional security measures on keys. Even if you stored your private key on disk, it would take physical access of your machine to get it. This is not what I'm worried about in private FidoNet mail. If a FidoNet member tries to break into my house or system to get at my key, I've got other troubles! Practically speaking, it might even be a good idea to have two keys; a small (256 bit) one for casual, email privacy, and a big one (1024 bits) that you give to people by hand on diskette. The small key will mean better performance, more important on bulk casual email, and certainly adequate against eavesdropping. For high-security needs, which most people don't have (I certainly don't), the performance penalty probably won't matter as much. The worst part of security systems is that people will *rely* on them as absolutes. This is the only thing that makes a faked, encrypted message worse than a faked, plaintext message. Again, it's important to remember the goal (as if we could ever possibly agree to a *single* goal...) -- if it's privacy, the ability to stop eavesdroppers, then a broadcast public key system is more than adequate, and public key repositories even better. If you want a maximum-security vault, you take added precautions. No one system will solve all problems. I'm a firm believer in a broadcast public key system for email. PRACTICAL SUGGESTIONS FOR PGP USE IN FIDONET PRIVACY: * Use small (256 bit) keys for routine, low-security use, such as netmail privacy with people you don't know personally (and don't get keys from physically). * Public key encryption is most useful for email, ie. FidoNet netmail, especially when it flows through multiple hosts on its way to its destination. * The current password scheme for echomail links is proven to be adequate to safeguard what is basically a public forum, anyways. Further security doesn't seem to be needed on these links. * When adding keys received via FidoNet to your public keyring, answer "do you want to certify this key yourself" with NO, unless you received the key by hand. It doesn't hurt the usefulness of the key itself; however, if someone later uses your public keyring they won't be lulled into a false security. (Certification of keys can be done at any time.) * Passing keyrings around willy-nilly, though counter to "good security practice" in traditional uses is actually a good thing for us. "Key Repositories" scattered throughout the net (each exchanging keyrings as well as posting lists of "trouble keys") is a better idea. * Reserve large (1024 bit) keys for people who you know, and can ensure security in traditional ways (some pointed out in the PGP documentation). * As seems to be developing, have your public key filerequestable as magicname "PGPKEY" (your own public key only), and your keyring as "KEYRING" (all of your public keys). These should be ASCII-armor files (PGP -kxa) * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: "Fen Labalme" Date: Tue, 13 Oct 92 15:56:27 PDT To: "Cypher Punks" Subject: anonymous bank accounts via Message-ID: <9210132256.AA08647@relay2.UU.NET> MIME-Version: 1.0 Content-Type: text/plain Mail*Link( Remote anonymous bank accounts via pem FYI: [pem-dev is a private email list for developers of the Privacy Enhanced Mail protocol additions to Internet mail, originally published as RFCs 1113 - 1115, and now updated as four draft-ietf-pem documents. To join the list, send email to pem-dev-request@tis.com. By the way, most of the discussion is not nearly as germane to our ideas as this particular posting, but this one caught my eye as of some iterest to cypherpunks.] ----------- Forwarded Message ------------ Date: Tue, 13 Oct 92 01:07:39 EDT >From: uunet!ellisun.sw.stratus.com!cme (Carl Ellison) To: pem-dev@TIS.COM Subject: Re: [Peter Williams: Perhaps OSI security is not possible in a liberal community!] Sender: uunet!TIS.COM!pem-dev-relay Let me throw in another vote against the *necessity* of hierarchical certification by arguing against the necessity of certification itself. For example, it is possible, given digital signatures, to have totally anonymous bank accounts -- identified only by public key -- with no certification of relationship between that key and any other fact about any individual or corporation. Such accounts are at least as valuable as a Swiss numbered account -- perhaps more so since no one need know the identity of the person or people with the power to withdraw funds. Such funds transfers can be made not only anonymously but untraceably. It might even be possible for them to be made without it being possible to trace the transfer at either end (eg., using digital cash techniques). I don't propose that all bank accounts be anonymous. It's just that I don't like to see us jump into an attempt to relate public keys into the physical world so that our old established notions about relationships and responsibility can carry over into this new domain when by doing that we end up avoiding research into all the possibilities which digital signatures open up. That research needs to be both technical and social -- or we could shy away from it by forcing relationships between keys and those entities to which we are already accustomed. --Carl From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: gnu@cygnus.com Date: Tue, 13 Oct 92 13:46:27 PDT To: Eric Hughes Message-ID: <9210132046.AA19146@cygnus.com> MIME-Version: 1.0 Content-Type: text/plain Get the latest Internet Drafts for PEM; the RFC's are out of date. By ftp to nic.ddn.mil, directory internet-drafts: -rw-r--r-- 1 gvaudre 35978 Sep 4 03:36 draft-ietf-pem-algorithms-01.txt -rw-r--r-- 1 gvaudre 16031 Sep 2 03:36 draft-ietf-pem-forms-01.txt -rw-r--r-- 1 gvaudre 85132 Aug 7 03:30 draft-ietf-pem-keymgmt-01.txt -rw-r--r-- 1 gvaudre 104515 Jul 25 03:30 draft-ietf-pem-msgproc-02.txt -rw-r--r-- 1 gvaudre 128 Sep 2 03:36 draft-ietf-pem-notary-00.txt John PS: I too think that other key certification models besides "hierarchical" are appropriate. I think we can start from PEM software and PEM message formats and evolve and experiment as appropriate. Before you ask, currently there is no PEM software widely available. It's in alpha test. It will be released in full source code, and its development was funded by DARPA. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Tue, 13 Oct 92 13:25:13 PDT To: gnu@cygnus.com Subject: Mail headers In-Reply-To: <9210131800.AA10408@cygnus.com> Message-ID: <9210131851.AA07309@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: gnu@cygnus.com >We have standards already for a fully encrypted email system. It's >called PEM, Privacy Enhanced Mail. It'd be completely senseless to come >up with a different format at this point, as PEM is on the verge of >deployment. One might have a good reason to follow most of PEMs formatting standards and the like; I'd fully agree its foolish in the extreme to do otherwise. However, some of us don't like PEMs hierarchical key authentication concepts. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Hal <74076.1041@CompuServe.COM> Date: Tue, 13 Oct 92 13:37:43 PDT To: CYPHERPUNKS Subject: New remailer... Message-ID: <921013203148_74076.1041_DHJ21-1@CompuServe.COM> MIME-Version: 1.0 Content-Type: text/plain I have been experimenting with Eric's remailing software on the Sun 4 I use at work. This is what I've found. First, Eric's descriptions of how all the different software components work together have been very helpful. The software has gone through three revisions as Eric added new features, so I implemented them in that order - first the basic remailer, then adding the "##" and "::" support for header management. (I had to get perl and slocal before I could get started. Luckily my system already uses sendmail.) Basically, I was able to put the parts together the way Eric described and have it work. I was able to send messages and have them remailed. I even did some tests bouncing mail between my remailer and Eric's. Then I tried adding a new feature to the remailer - automatic message decryption using PGP. It's not really very secure since anyone with root privileges at my site can see my pass phrase, but my site is pretty isolated (a 2400 baud modem is the only link to the outside world). For this I had to add one line to Eric's model .maildelivery file to invoke my PGP filter, and had to write about a five line shell script to run PGP in a useful way. I am still tuning this a little bit but I can send the exact scripts out when people are ready for them. One nice thing about this is that, with my remailer plus Eric's, and with the decryption option, you can now send anonymous messages for which no one person can tell that you did it. What you would do is to send the message first through Eric's remailer, so I don't know where it came from, then through my remailer, but with the message encrypted so that Eric can't tell where it's going after it leaves me. If more people will run remailers then we'll have much more security. I will now tell you how to use it, in case you want to experiment. But remember that all messages are going across an intermittently- polled 2400 baud modem, so don't expect fast turnaround and please don't send a large volume of messages. Also, please don't pass information about this remailer beyond this list, for now. The remailer is at hal@ghs.com. The basic remailing operation is as Eric has described: either put "Request-Remailing-To: " in the header of the message, or put, as the first two lines of the body of your message: :: Request-Remailing-To: And follow these two lines with a blank line, then the message to be forwarded. Decryption is just a little complicated. The thing to remember is that you want to do more than just have me decrypt the message. You want me to then remail the message after decryption. This means that you should prepare a message with remailing instructions as above, then encrypt the whole thing, including the "::" and "Request-Remailing-To:" lines. Encrypt using PGP with the public key I show below, and use the -a flag for Ascii output. This will create a PGP output file, typically with the extension .asc. The first line will be: -----BEGIN PGP MESSAGE----- Now, you can send this message to me, but you have to do one more thing. You have to mark it as an encrypted message, by putting the line "Encrypted: PGP" in the header. If you can't put stuff into the headers of messages, then use Eric's "::" feature and add the following two lines, then a blank line, before "-----BEGIN PGP MESSAGE-----": :: Encrypted: PGP Don't forget the blank line after these two. Now, this message can be sent to my remailer. It will be decrypted and then remailed to whomever you requested. I know this sounds complicated, so let me break it down into steps: 1. Create the message. 2. Add "::" and "Request-Remailing-To: " and a blank line to the top. 3. Encrypt the whole file using PGP and the public key below. 4. Add "::" and "Encrypted: PGP" and a blank line to the top of the encrypted file. 5. Send it to hal@ghs.com. That's not so bad, is it? Now, if you're really adventurous, here's how to do the double-remailing process I described above, the one which keeps any one remailer from knowing who's talking to whom. 1. Create the message. 2. Add "::" and "Request-Remailing-To: " and a blank line to the top. 3. Encrypt the whole file using PGP and the public key below. 4. Add "::" and "Request-Remailing-To: hal@ghs.com", then a blank line, then "##" then "Encrypted: PGP", then a blank line, to the top of the encrypted file. 5. Send it to hughes@soda.berkeley.edu The only complicated step is step 4, where you put in the remailing request to go from Eric's system to mine, and use the "##" line so that the outgoing message has "Encrypted: PGP" in the header. If you want real security, encrypt the message using your friend's public key after step 1 and send that. Then nobody will even know what you're saying, let alone who you're talking to. As promised, here's the public key for my remailer: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.01 mQBNAirY9EoAAAEB/iuDBqpeJ8gsNQwJNRYWBxH7uP95ApQ92CDhCmuSEJ0Tta0l oCrC+8Br+D7Nfotb7hJlI0A1CYGAlmCsRO8VEmkABRO0H1JlbWFpbGluZyBTZXJ2 aWNlIDxoYWxAZ2hzLmNvbT6JAJUCBRAq2ISQqBMDr1ghTDcBARYlBADCjkCkIDvA 7QFtpYUlYjz/2U+/oDuMZBDlmAw8BCg3sdJG7hnxPE4yVgKoH/ozsb23pbFTPB8H WNEjqTqixNybOKSKH9T8iCaRDA8+bS6xPN4YlWKD/Wg2EiyuOjD3v/vWgiZXzMR5 hpe0CYVJ6bM++hptXu+JxqDReJIot5FFbQ== =p8FS -----END PGP PUBLIC KEY BLOCK----- Hal 74076.1041@compuserve.com P.S. Coming soon: anonymous return addresses! From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: hugh@domingo.teracons.com (Hugh Daniel) Date: Tue, 13 Oct 92 18:58:39 PDT To: cypherpunks@toad.com Subject: Matching Text, Headders and Signatures with Crypto Hashes In-Reply-To: <9210131710.AA20497@bsu-cs.bsu.edu> Message-ID: <9210140150.AA12409@domingo.teracons.com> MIME-Version: 1.0 Content-Type: text/plain A genral and powerful method of makeing sure that Headders, Bodys and Signatures match is to use cyrpto-checksums. For example in NetNews I proposed changing the MessageId: headder such that part of the gobldyguk on the left side of the atsign was a crypto hash of the body of the message and some of the important sending host generated headders. With this system of MessageId:'s anyone who corrupts a message (intentionaly or otherwise) creates a bogus message, as the next machine that gets the message can see that the message does not match it MessageId: line. So, if we design the signature system right (with a field for a crypto hash, or some sort of secondarys signatures to in efect counter sign various includes such as the plain text) a plain text message can be signed in such a way that you can be sure that the text is the right text and none other. This can be sent over the airwaves as it is not hideing information but proveing that it is the right information! Systems like this would be *very* usefull right now, are simple to do (with good advice from Crypto Math types) and usefull to everybody. ||ugh From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Tue, 13 Oct 92 22:45:57 PDT To: cypherpunks@toad.com Subject: re: Re: Mr. Squirrel Message-ID: <2934.2ADBB27E@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain U> The most pressing thing is not to integrate encryptions in U> mail handlers, but at the level of ether. Ether is an U> enormous security hole. I can walk up to anything running Who uses ethernet?! :-) I think it's safe to say our FidoNet doesn't have three feet of thinwire in it. We're all dialup. Message-reader integrated security is where it's at -- here. You're totally right about it though... but it requires physical access. * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Tue, 13 Oct 92 22:45:57 PDT To: cypherpunks@toad.com Subject: re: Matching Text, Headders and Signatures with Crypto Hashes Message-ID: <2936.2ADBB282@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain U> From: hugh@domingo.teracons.com (Hugh Daniel) U> For example in NetNews I proposed changing the U> MessageId: headder such that part of the gobldyguk on the U> left side of the atsign was a crypto hash of the body of U> the message and some of the important sending host U> generated headders. With this system of MessageId:'s U> anyone who corrupts a message (intentionaly or otherwise) U> creates a bogus message, as the next machine that gets the U> message can see that the message does not match it U> MessageId: line. There's a FidoNet mailer (Dutchie) that uses MD4 to generate message IDs in exactly this way... They did some cheat, to allow certain filters (CR/LF vs LF, etc) to work. * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: wixer!pacoid@cs.utexas.edu (Paco Xander Nathan) Date: Wed, 14 Oct 92 03:49:44 PDT To: cypherpunks@toad.com Subject: Game items Message-ID: <9210140517.AA12767@wixer> MIME-Version: 1.0 Content-Type: text/plain Just about any device for refining psychoactives... Alcohol stills, for one. We run one at home in TX, legal now, but which would have been jailbait in my grandmere's time. In certain parts of TX, wirecutters used to be illegal on strangers. They implied cattle rustling, etc. Phone recording equipment is legal now in many areas - formerly forbidden by wiretap laws, but now available through catalogs like Damark, etc. It would be so easy to find counter examples - non-weapon, physical items formerly legal, now illegal or heavily watched/licensed... precision scales, lab glassware, Kevlar, radio transmitters... pacoid. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Judith Milhon Date: Wed, 14 Oct 92 10:28:10 PDT To: cypherpunks@toad.com Subject: game items Message-ID: <199210141727.AA18138@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain You needn't timetravel to come up with instances of underground heroism. There is RIGHT NOW an underground dealing with AIDS meds. And there may be, soon, an RU-486 network. These are worlds away from traffic in sleazy recreationals for profit. >jude< From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Wed, 14 Oct 92 17:26:19 PDT To: cypherpunks@toad.com Subject: illegal objects Message-ID: <2952.2ADC70A6@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain Hell, there's real-world examples today that some of my friends have been harrassed for: "Obscene materials". OK, sexually explicit photographs are a trivial example. Friends have gotten harrassed (by US customs) for zines containing weird shit, not just sexually explicit. The US/Canada customs people are living in another century and reality plane. * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Wed, 14 Oct 92 11:06:29 PDT To: cypherpunks@toad.com Subject: Some (Pseudo)Random Thoughts Message-ID: <9210141805.AA04539@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Some thoughts on the recent meetings and what we're doing: 1. The importance of trading physical goods in the Crypto Anarchy Game. This, in my view, has been given undue and misleading importance. Physical goods are inherently easy to trace through remailers (via sniffers, radioactive tracers, weight of packages, and many other physical cues), are hard to store physically (imagine getting 100 parcels for later remailing), and, most importantly, have none of the "envelope within envelope within...." protection accorded to the bits of a cryptographic remailing, or DC-Net, system! The elegance of cryptographic protocols is lost with physical goods. Furthermore, physical delivery of any good, whether drugs, stolen missile components, antiquities and art items, whatever, is fundamentally a hard problem to solve...smugglers and thieves have been dealing this since the beginning of time. Stings can be easily arranged, delivery is not anonymous (one merely watches who takes delivery, or who opens a train station locker, etc....this is all SOP for narcs and counterespionage types), and a raid on a remailing entity will result in confiscation of the physical goods and (likely) prosecution of those caught holding the stuff. (Raiding a bit remailing entity produces only random-appearing bits...granted, the authorities may well outlaw bit remailing, or use the RICO and conspiracy/sedition laws to prosecute, but that's another topic.) Our recent emphasis on physical goods, and all the ideas pouring in on what other kinds of "contraband" besides drugs can be used, is misleading. None of the richness of the cryptographic world is faithfully preserved. I urge we get back to our roots and deal only with things that can be expressed purely in bit form. 2. The "colonization of cyberspace" does not mean there is no interaction with the physical world, of course. But that interaction can be mediated with money made by converting information or digital money into physical money. Several methods for this conversion path can be considered: -Alice sells information in the cyberspace domain for the equivalent of, say, $30,000. She converts this to "real" dollars by using an escrow entity which hold both sides of the transaction until it's completed. They then mail the information to the purchaser and send an ordinary check "for services rendered" to Alice for $30K. She reports it on her taxes, probably as a "consulting fee" (for which essentially no government supervision currently exists, nor is likely to....), and the conversion has taken place. (Note: there are still elements of trust involved, notably involving the escrow agent, but trust works pretty well for many things, especially when reputations are at stake. Understanding how real businesses depend on reputations is a missing part of modern cryptology analyses of transactions...the protocol analyzers and number theorists almost never take into account how reputations work in the real world, But I digress.) -Alice and Bob trade information such that Bob gets the information worth about $30K, as above, and Alice gets another piece of information she can use in the "real world" that is worth about $30K. This might be stock tips, or, better, information she can turn around and sell in the "open market" of a service like AMIX! There are lots of wrinkles, inefficiencies, etc., to be worked out. -And then there is digital money. You all know about this, or should. David Chaum, DigiCash, blinded notes, credentials, etc. The handout for the first meeting had a glossary of terms. (IMHO, we should be spending more of our time at our meeting discussing this, and less in playing more interations of the Game.) The fascinating novel "Snow Crash," by Neil Stephenson, makes a mistake in having Hiro Protagonist a very wealthy man in the Metaverse (Stephenson's term for the virtual reality cyberspace) but a very poor man in the Real World. Information _is_ money. Information is liquid, flows across borders, and is generally convertible into real money. (One simple conversion strategy, alluded to above, is for Alice to sell her information for, say, $500K, and then to receive a "consulting contract," perhaps called a "retainer," of $50K a year for the next 20 years. Her retainer is fully legal, is perhaps handled through cut-outs who specialize in this kind of thing, and is a low-risk way to "launder" money from cyberspace into the real world. I have a lot more to say on these schemes, perhaps later.) 3. Are we emphasizing "The Game" too much? If the goal is to produce a paper-based game, similar to "Monopoly" or fantasy role-playing games, then I suppose more practice is needed. But I'm not sure how worthwhile it is to try to design such a game. (Those who wish to should do so, then commercialize it, and become the Avalon Hill of crypto games!) If the goal is educational, for newly interested folks, then I also question how much more effort should be put into it. The ideas of anonymous remailers, of digital money, etc., are, I think, gotten across in the first 60 minutes of the game, especially if some of the formalism is first explained (as it was at the first game, where digital mixes, tamper-resistand modules for implementing mixes, the "Dining Cryptographers Protocol," and digital money had all been freshly covered, so participants were putting the theory to test). I found the first game was instructive, the second much less so (and _not_ because of the focus on drug selling...that was a relatively minor issue). My impression is that many of the newcomers--and they should jump in here with their own reactions (too bad we don't have hypertext links!)--didn't really know how remailing mixes work, how digital psueodnyms can protect privacy in transactions, and how the "Game" was intended to exercise these concepts. 4. We need to talk about the charter or purpose of the "Cypherpunks" or "Cryptology Amateurs for Social Irresponsibility" (CASI--Eric Hughes's term) group. -Is it mostly educational? -Is it a lobbying group, as are EFF, CPSR, and the like? -Is it to produce remailers, digital money, and other programming? -Is it subversive? Now clearly we can't say it's subversive (any bets on who's gatewaying these messages to Other Listeners?). But we also don't want to skew things toward "YALG" (Yet Another Lobbying Group), nor do we want to be a spoon-feeding educational group for people with a casual (and transient) interest in crypto stuff. 5. There have have been several messages so far about worries about the legal implications of these topics, about how some corporate-affiliated subscribers will desubscribe "real fast" if certain discussion trends continue, and so on. Now we can't please everybody, but maybe we ought to talk about this sensitive issue soon, and _in person_. Since it relates to our charter, Point 4 above, I recommend we do this at our next meeting. I'd favor that over another iteration of the Game. In conclusion, we are in at the beginning of Something Big. While I'm somewhat skeptical about the claims for things like nanotech, I see this whole cyberspace/cryptology/digital money/transnationalism ball of wax being _much_ easier to implement. Networks are multiplying beyond any hope of government control, bandwidths are skyrocketing, CPUs are putting awesome power on our desktops, PGP is generating incredible interest, and social trends are making the time right for crypto anarchy. I look forward to hearing your views. -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP 2.0 and MailSafe keys by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hollander Date: Wed, 14 Oct 92 11:11:49 PDT To: Tom.Jennings@f111.n125.z1.fidonet.org (Tom Jennings) Subject: Re: Mr. Squirrel In-Reply-To: <2934.2ADBB27E@fidogate.FIDONET.ORG> Message-ID: <9210141810.AA14191@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain >Who uses ethernet?! :-) Everyone here at UC Berkeley. >I think it's safe to say our FidoNet doesn't have three feet of >thinwire in it. We're all dialup. Message-reader integrated security >is where it's at -- here. In the case of FidoNet, it sounds like that's what's needed, because your mail is being sent from systems that are not multiuser systems. The net really is just for exchanging files and mail; it isn't for remote computer access. >You're totally right about it though... but it requires physical access. Physical access is much easier than people think. I can walk into almost any computer room here at UC Berkeley and plug in. And we have something called building ether in the building I work in: all of the machines in this section of the building are on the same ether net. This means that if we want to see other researchers' data before it's published, we can, because we can see all of their packets. e From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Hal <74076.1041@CompuServe.COM> Date: Wed, 14 Oct 92 08:27:57 PDT To: CYPHERPUNKS Subject: Game items... Message-ID: <921014151922_74076.1041_DHJ62-1@CompuServe.COM> MIME-Version: 1.0 Content-Type: text/plain I'm trying to think in terms of things which were illegal but which have good moral connotations today. Crosses and other Christian symbols were supposedly outlawed during the Roman empire (leading to the adoption of the fish as a symbol of Christianity). Posing as early Christians smuggling crosses ought to make the right-wingers happy! Abolitionists had to smuggle runaway slaves out of the South on the so-called "underground railroad". Perhaps cryptography would have helped them coordinate their efforts. Much of the support in the U.S. for freedom and privacy comes from our revolutionary heritage. I'm embarrassed at how little I can recall of what things were restricted in those pre-revolutionary days. I recall the Stamp Act and a few other laws, and I imagine that seditious materials were restricted. Perhaps the game players could be early revolutionaries trading items forbidden under British rule. Hal Finney - 74076.1041@Compuserve.Com -----BEGIN PGP PUBLIC KEY BLOCK----- mQCNAiqsNkwAAAEEAMKWM52m5EWi0ocK4u1cC2PPyHT6tavk9PC3TB5XBYDegf3d sldRpnjJj1r+aO08FFO+QLEI9wtBqvf1PPP5iLX7sD2uIVlJH14MPtyVtjm9ZKb8 JMtCW74045BgtHBC9yQ3V7vXNV5jM6dE2ocnH4AI/pBFrGLJPKgTA69YIUw3AAUR tCZIYWwgRmlubmV5IDw3NDA3Ni4xMDQxQGNvbXB1c2VydmUuY29tPokAlQIFECqu M1Tidd4O/2f3CwEByrUD/3uoV2y+Fuicrrd2oDawgOw9Ejcx6E+Ty9PVPqKvflLs 0zYyGfeFVSgBbTSDP3X91N3F68nydl9J9VA6QRCGelHM1cZRukCJ0AYbKYfpwUN0 xjEGHsDrd2gT5iWlB3vBZvi+6Ybs4rSq+gyZzVm1/+oRrMen32fz2r0CLgUtHok2 =fF6Z -----END PGP PUBLIC KEY BLOCK----- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: hkhenson@cup.portal.com Date: Thu, 15 Oct 92 03:39:36 PDT To: cypherpunks@toad.com Subject: Re: Game items... Message-ID: <9210150128.1.14673@cup.portal.com> MIME-Version: 1.0 Content-Type: text/plain I have not been paying enough attention to the cyberpunk list, but I did notice that some of you were concerned with the subject, and that Tim May was mentioning "pure information" as a better model to play with, so I thought I would send this in as a sample. Perhaps some ideas of where to take the story will come out of using this model for another game. Anyway, this game theme should not push as many hot buttons as drugs do (though it should!). This fragment of a tale was written shortly after I came back from the first Computers, Freedom and Privacy conference. It is placed in the time period between now and the usual time frame of Gibsonian cyberpunk. It was written to help me think about the social & legal responses we might see when encryption is more widely available-- and used. Sorry the story is incomplete, I just got too busy to finish it, and ran short of ideas as well. And sorry for the obsolete technology involved. I am sure something better than MS DOS will come along eventually. :-) (The usual conditions of posting apply--copyright H. Keith Henson 1991) Green Rage by H. Keith Henson "'Nother hour and I can 'crypt and email this mess." Lenny closed the forth of five files: maps, diagrams, schedules, assignments, and instructions. It was a four person monkey wrench project for destroying a big piece of a paper mill and (he hoped) making it look like an accident. It was due to take place on the east coast in a few weeks. Lenny had never met any of the people who had scouted out the plant, nor the bitter, out-of-work engineer who had figured out how to wreck it, and none of the operators who were involved would meet each other. Made for hard-to-crack operations. Some people on the east coast did the same for the covert side of the GreenRage group that paid Lenny. The tofu sandwich he had for breakfast was a dim memory. "Lunch first." Lenny thought. As he headed out to pick up a vegetarian pizza, he looked through the little glass panels in the front door. "Oh, shit, suits outside," Lenny said it with feeling, but kept his voice down. He turned on his heel in the hall leading to the front door and ran back into the grubby GreenRage office in the dining room of a rented house in San Samon. He managed to hit the power switch on the PC at Stel's desk before the door opened. Stel was in the bathroom. Whether she heard the warning or not, Lenny could get no help from her, and Marge was out on errands. The door was opening--there was no chance to get to the other two computers or to take down the '586 file server in the kitchen--he looked up and in his best bright and cheerful voice (which to Lenny sounded hollow and rehearsed) said, "May I help you?" The first of the four suits, a beefy dude in a grey outfit spoke up. "Yes, you can. We're from the CCA. (The Computer Control Agency): We have a court order to copy all the computer files in this building," (he held up an official looking piece of paper--more trees destroyed, thought Lenny.) "so unless you want to be charged with contempt, you can step back from that computer, and don't touch anything till we are done." Lenny stepped back. He wasn't as terrified as he could have been, though his heart rate must have been close to 120 and his mouth was dry. He had been through raid drills and a few real confrontations with the law at pickets and bleed-ins. "At least it isn't a search warrant, we might keep operating" he thought. Then remembering the drill, spoke up: "Can I see the order?" The beefy one handed it over while his three leaner and younger companions fanned out to the computers. They obviously knew where the computers were, but that did not necessarily mean rot in the organization. How well they coped with the 'puters would say something about that. The paper was about what he expected, an order signed by a judge to copy every storage device in the GreenRage's office to an encrypted WORM drive. The box for paper documents wasn't checked, so they knew they wouldn't find anything useful on paper. Bad sign, it meant they knew more about GreenRage than Lenny liked. "Waste as much time as I can," Lenny thought to himself, and in a very polite voice he asked: "Can I see some ID for you and your men? The closest of the technoids, as Lenny thought of them looked up in disgust after putting his hand on the back of the ancient '386 clone Lenny had just killed. "Its been turned off in the last 2 minutes. Did you do it when we came in?" he said this looking right into Lenny's eyes, while digging out his badge. Lenny didn't lie with his reply, "Its Stel's, she was about to go out, and we try to save power by turning them off when we go out." He said this as loud as he dared, hoping that Stel would hear him in the bathroom, then spoke up even louder, "Stel, we have official visitors, so don't make any sudden moves." At 200+ pounds, and fifty plus years, Stel didn't make many fast moves, unless they were on young guys. In view of the constant water shortage, the chances were only about one in four that she would flush the toilet, and less than even that Stel would wash her hands. Without any running water sounds, she come out. "Pigs, huh." Stel had been politically imprinted as an anarchist at Madison over thirty years ago in the late '60s and early 70's. When it suited her, she could be one of the most obnoxious people Lenny had ever known. At least it diverted the attention from him, chances were low that the cops would grill Stel on who shut off the power on her computer. Beefy, whose' badge claimed to be one Dan Barker, and technoid #1 (Lenny never did get a name for him, flashed their badges. Lenny grabbed a whiteboard marker (almost dry, and the only non computer writing device permitted in the office) and scribbled Barker's name and badge number on the edge of a badly cluttered whiteboard. The other two technoids had fanned out, one to Lenny's desk, and the other to the kitchen. The kitchen one came back shaking his head. "No damn keyboard or display on the server. Have to go in through the other ones to dump the disk." Technoid #2 moved the mouse on Marge's machine, but thank the green mother, thought Lenny, the screensaver program had timed out, and the "I NEED A PASSWORD!" message came up. That meant the password was gone from memory on that machine. Technoid #3 hit paydirt on Lenny's machine: the screen was still alive. He hit the space bar, and pulled out a little alarm timer which he set to go off every 3 minutes. "Damn, damnit" thought Lenny, "I should have set the timeout shorter, has it really been less than 5 minutes since I got up?" And he was mentally kicking himself for not wiping the password when he got up. Technoid #3 noted the directory (ACIDRAIN/TRMINATE) where Lenny had been working and went back up, a level at a time to the main directory on the file server. He seemed prepared to deal with a no printer machine, pulling out a pad of paper from a little portfolio (more trees!) and started making notes on the directory structure. Technoid #2 looked up from Marge's machine and asked Lenny, "I don't suppose you would know the password?" Lenny shook his head and then looked the agent in the eye. "No sir! I certainly wouldn't know Marge's password to get into her personal machine!" And wouldn't admit it if I did know, he thought. Technoid #2 looked over at Stel frowning at the machine on her desk and asked mildly, "I don't suppose you would remember your password?" "Fuck off sharp one," Stel said with a straight face. Even in a near state of panic, Lenny got a flash of amusement as Beefy started to spit out a hot reply. Beefy checked himself as he saw #2 write down fuckoff#1. Stel grinned slightly; she had almost scored one on the agents. Without making a move toward Stel's machine, #2 asked #3, "Shall I try it, Jim?" Jim was engrossed, paging through directories but he mumbled: "No, let's see what I can get before we risk a password given under duress." And, half a minute later, "This is going to be a bitch, I can't find any programs to dump memory, no debug, no basic, no smalltalk, no turbo, nothing." Lenny grinned, and straightened his face with an effort. The crypt program had come with instructions to delete or encrypt under a special key a long list of compilers and interpreters-- not that he understood exactly what they were anyway. "Bob, could you have one of the uniformed officers get the camera out of the car? Looks like we are going to have to photograph some of this." Beefy went to the door and tried to get the attention of one of the uniformed cops that had come with them. No luck, they were both out back, keeping an eye on the building power switch so no one could turn it off. It was less distance to the car, so he just walked out to the car, rummaged around in the back seat and brought back the camera kit. Jim waited for him, typing a space every 3 minutes. "Take it easy on the polaroid, damn film costs two dollars a shot," as he handed the camera kit to technoid #3. Technoid #2 came over to help and started clicking shots of the screen as Jim worked his way around in the directory tree. There were *lots* of interesting directory and file names. Stel, Marge, and the three masked visitors from back east had spent a whole evening making up provocative names like HIT_LIST (Lenny's address book), and $LAUNDRY (data for a spreadsheet program Marge used), and a lot of disaster names like HINDENBG, and TEX_CITY. Since the crypt program left the directories in the clear, they thought they might as well make them amusing. At the moment, with cold sweat dripping down his back, Lenny wished he had made the directories a little *less* provocative. Once in a while, technoid #3 or Jim as Lenny was beginning to use to identify him--gotta scribble that name on the white board--would give the command to type out a file to the screen. He either got a mess of published material from decade-old anarchist newsletters, some of which they carefully photographed on the screen, or computer-generated random bytes (which, of course, they thought was encrypted material). One or the other of the technoids not sitting at the screen kept themselves shielding the power switch and plug. Stel was sitting on the grubby couch waiting for the technoids to either break into the system or screw up. Lenny went over and joined her, feeling miserable about the agents getting in through _his_ system and unwilling to watch any more and give away by body language when they were about to trip. He glanced at his watch. The damn cron program should ask for the password in another 20 minutes. "Jeez," he thought, "I hope they don't get anything." "There are _10_ copies of something which looks like a word processor on the server hard drive--they all have the same byte count and date, and there is _NO_ 'path' set," technoid #3 bitched loudly enough for Lenny to hear. (Happened that this was an accident. Lenny had found that if he copied the word processor into each directory he made, it worked fine.) The server had an old 700 Mbyte drive, and a few copies more or less of a half Meg program made no big difference. However at the moment, the technoids had concluded that this was a clever hack, that the system would wipe the password out of memory if they tried to run the wrong word processor program. They outfoxed themselves: any one of them would have worked fine. ("Type" or "copy" to the screen wouldn't work because the WD*11.0 stored files in compressed binary.) "Well, Bob, it is moment of truth time. We can take a 1 in 10 chance of starting up the word processor and looking at the files, or we can try to load in a program to extract the key from this thing's stinking memory. What say?" "You guys are the experts, don't ask me." After a short conference, technoid #3 fished a diskette out of his pocket, kissed it for luck, and stuck it in the drive on Lenny's machine. "Here goes nothing." and he typed "dir a:". The crypt program was watching for diskette access, and came back with: "I NEED A PASSWORD! "Shit." whispered a dejected technoid under his breath. "Know anybody at NSA?" ---------------- Lenny put the back of his palmtop on the microphone of a payphone and hit the dial button. "That will be one dollar for the first minute." Bong, bong, bong, bong. "Thank you for using ESJI, you have one minute." Buzz-click, "Hello, there is no one here at the moment, but you can record a message." "Here" was a little module of code in an automated PBX/voice mail machine watching for incoming calls after working hours on a line deep in the list of numbers assigned to a small corporation. It was an old machine, and unlikely to get another software upgrade. After taking a call, it would not take another for several hours, and it rotated through several recorded messages. Lenny hit the next button down on the palmtop. #-Beep, 4-Beep, 3-Beep, 6-Beep. "confirm with password. L-beep, E-beep, N-beep. "Record message. End with any key." Beeeeep. "Nancy, its Murray, just called to say hi. Get back to me sometime when you get a chance." #-beep. "Message confirmation number 36, repeat 36," and a click. The PBX made a local call to a paging company and transmitted what looked like a phone number. The phone number digits added up to 36. Lenny punched 36 into his palmtop and hit the enter key. It came up with an address, a description, and a phone number. It was the phone next to the K-mart entrance about a mile away. "K-mart will be closing about the time I get over there," he thought. "Could have taken the bike." He closed the palmtop. It sensed the closing and erased its encryption password. Lenny got back in his tiny 5 year old "B-car," the 60 mpg car some rich dude had been force to take in a package deal when he bought a 20 mpg Lincoln Towncar. He twisted the key. The lights dimmed as the catalytic convertor came back up to heat on the battery. There was a few seconds' wait to let the battery recover, and the car started. Lenny watched for cops as he drove over to the K-mart, but he didn't drive *too* cautiously. That was one sure way to attract attention. There wasn't much of a mob leaving the closing K-mart on a weekday. Lenny parked near the phones and walked over. He was about 20 feet away when the one on the left rang. He picked it up and said, "36." "What's the problem? If you forgot your key, I can't help." The voice on the other end sounded odd. It was probably going through some blind location in Mexico where the automatic number identification had not yet been installed. It also had the quality of digital speech. Original words of the speaker were being converted to phonemes and back to words. Not a hint of the speaker's real voice quality came through, though this dodge did not affect word choice and rhythm patterns. "Agents," Lenny said. The CCAs came in early this afternoon. I don't think they got anything, but I needed someone to talk to." "Dumb idea if they are watching you, but tell me what happened anyway." Lenny related the events of the afternoon up to the point where the agents lost the password on his machine by trying to load a memory dump program from a diskette. And then he went on. "After that, they popped the cover off the server, hooked up their gear and copied the 700 Meg disk, a few dozen 60Mbyte SMs, and a few dozen 3 meg floppies. One of them had your crypt package. They didn't mention my palmtop, and Marge keeps the backup tapes at home. Only took them about 2 hours. They put the covers back on and left me with what they called a PK encrypted 2.4 Gig WORM cartridge. They took one just like it, and even made me choose which one I got. The order said I was required to take one of them. It has all kinds of legal seals and signatures on it. They said take it to our lawyer. One of us took it over about 5 pm. None of us have a way to read it. Are we in trouble?" There was quite a delay. Then, the digital voice spoke up. "Even if they were able to track me down, *I* am not in trouble. I make a point of posting all the programs I ever give out. In source code yet." "I don't think you are in trouble from what they took with them. The copy they left with you is the data off your disk, encrypted with a half-key the judge issued. Until the hearing they can't read it because they lack the other half of the key. The only use for it is to keep them from making a copy of data, changing the data and making another one of those write-once cartridges. So, you are ok till the hearing." There was more delay, then the funny sounding voice on the other end of the line went on. "Presuming the passwords are not compromised, even getting the other half of the key from the judge to look at what they took should not be a big problem. But since they came in at all, I would say you are in big time trouble. That was a piece of dumb luck that they didn't try WD* on your files. Of course they always have the option to give you blanket immunity and force the key out of you, but by the time they get around to doing that, you can forget the key. I sure would. I presume you had the machine convert all the files after they came in to a new password?" "Not yet. I haven't let anyone put a password into any of the machines since they showed up. I'm afraid they will have a camera bug looking over my shoulder. About a month ago, I read in the paper that they did that to a bookie in St Paul." "Not likely for you--but possible. Hmmm, did they leave any judicial orders about not moving the machines?" "Not from what I read on the court order. I can ask our lawyer. Our lawyer may be good at filing objections to logging company projects, but I think he is out of his depth if they go after us criminally. I can't afford a criminal lawyer. I called around and the best deal I could get was $100k retainer, cash or gold, no checks." "They have already gone after you criminally. You don't get a data search order from a judge without a fairly good reason. On the other hand, it was not a search warrant. It is arguable that they shouldn't have gone looking at stuff in your files, but who needs to argue? They either don't have enough on you for that or they are waiting to see what you do and who you talk to after the DSO. I don't know and don't want to know what you are doing, but there must have been something that tipped them off." "I can't think of anything--even if the people we are sending email to on the east coast had all been turned, I can't see how they could have traced it back to us. Mail to them was going through about 10 blind links, sometimes took 3-4 days to get cross country, it was deep 'crypted all the way, and somebody donated the digital stamps." "Never like to use digital stamps I haven't bought myself with cash, and then only from a reputable Swiss bank. But I can't see how that would have done any harm . . . . is there any chance the stamps might have been 'used?' That would certainly compromise your traffic, though not the messages." "Nope, a few of the messages circulate back to us. They wouldn't if the "stamps" were no good." "Not necessarily true. The mom and pop forwarders often accumulate stamps for a week or more before sending them to the bank. You just can't check with a bank on dollar or sub-dollar amounts--connect time eats you up. "The first link was Telesis, and I know they are on line to the bank that issued the stamps . . . . Unless they are . . . . in on it. . . ." Lenny was looking right at the Telesis logo on the phone. "Yeah, '/Paranoia strikes deep/' . . . . Did the court order say anything about why they were going after you?" "No, there was a note on the order that the supporting affidavits were sealed." "You guys rate! There hasn't been a sealed affidavit for a DSO I know about in the last ten years. The stink around the Steve Jackson warrant took years to wear off! Well, they have to unseal them before the hearing. The hearing has to be within the next three weeks if I remember right." "You do, it's on the 9th of next month, 20 days from now." "Well, the first thing you should do is change the password, so you can start forgetting the old one. How much clear stuff was on the disk? "None that I know about . . . . well actually about half the disk was filled with the nastiest old published stuff we could find--rabid libertarian literature and anarchist newsletters, public domain stuff off a CD ROM. The rest was filled with random numbers from a noise card when your guy set it up last year, then we deleted about half of it to give us working space. But far as I know, there was nothing to worry about in the clear. Snooper hasn't been complaining about unencrypted files when I run it on startup every morning." "There is a hole in that program, but it takes some very special circumstances for it to fail. I kind of doubt you are being watched. If they were going to go to that much trouble, a search warrant instead of a digital search order would have been the way to go, but if you are really worried about them looking over your shoulder, take your machine and the server to a random motel you've never been to before. Lets see, if you had to do the whole disk, it would take maybe two hours. You shouldn't lose anything if you have to interrupt the process in the middle--wait, yours is a 3 person office?" "Yes." "Main password, and then one for each of you?" "Yes." "Option 4:7 is what you want to use. It will decrypt only through the old main password, and reencrypt through the new password. Data never comes up to clear. Try that." "Ok. Should I take it off to a motel?" "Suit yourself. You know how good or bad you have been. But do keep me informed. Hasn't been a case this interesting in years. Random route Email by preference, but call if you need to, same method." ------------- Lenny and Marge checked into a motel which had definitely seen better times, but was happy to take cash. A lot of people had quit using credit cards, especially for checking into a motel on the hourly plan. It was just too easy for people to tap into credit card records. The swimming pool was dry in July, but what the heck, they weren't here for swimming. "I can't believe this, Marge, this power outlet has only _two_ holes." "Lenny, this place was built before they invented grounding plugs, what do you expect." "Well, what the heck are we going to do now?" "First we look around. No problem, the socket in the bathroom is a 3 pronger." Lenny plugged in the powerstrip while Marge plugged the pieces of the PCs together and connected a short network cable between them. Lenny joked to keep down his nervousness; "Wonder what they thought of us." Not many couples bring in couple of PCs to do perverted things in the dark." "Lenny!" Marge said sharply. "No, Marge, I meant the _PCs_ will be doing things in the dark, not us." Marge picked up on the joke by looking disappointed. She really wasn't. Lenny was one of those rare guys who just did not care about sex with anybody. Her regular boyfriends knew she was not getting any at work. -------------- The 'crypt program rejected the first three passwords Lenny tried as too simple. Which to him meant easy to remember. He finally got it to accept anhtre spelled a@n7t%h7e$r (the password program would drop the final r). Lenny's first password had been sesame. He had used variations on opendoor, opendore, openwindow, enterhere, portculius, drawbridge, safedoor, gateway at various times. If anybody had a list of his passwords, they would be a long way up on selecting attacks. He felt he was doing the best he could to make them complex, but still rememberable. He left the duress password (bugout) alone. It was one he had kept using for years, and never had needed. Lenny wasn't certain he would use it if he got a chance. Even though Marge backed up the disk every week, he would lose a lot of work if he used the duress password and wiped the disk. ----------- They crammed the computers back into the tiny car five hours later. Marge dropped the key in the slot by the office and they drove back to the GreenRage office where Marge and Lenny set up the machines and Marge started the backup program. The CCA observer made voice and printed notes of their return on his palmtop from the stakeout location inside a furniture company office about a block down the street. --------- The office never got up to full productivity over the next five weeks, but Lenny did finish and email the project--with notes to the effect that the enclosed was chapters from a book he was writing, and a true-to-life description of the data search order being carried out. He left it up to the folks on the other end. If they wanted to carry out a project which was in the hands of the cops, it was on their heads. ---------- The DSO hearing went about as expected. The judge granted a two week extension over the protest of Bruce, the GreenRage's lawyer. When the day came, Lenny, Marge, Stel, and Bruce were all looking more respectable than they usually did. Even Stel was wearing a dress (long out of style, but the only decent one she owned). The hearing at the federal building started in open court with a request from the US Attorney for the judge to review the CCS's material in camera. "Mr. Mulronny, I have already looked over the affidavits you sent over, and I can't do it. I already granted you an extra two weeks, and the law can only be stretched so far. You either have to make a case and let these people defend their data, or you have to drop it." Mulronny looked unhappy, but was prepared with the unsealed affidavits. He gave one to Lenny, one to Bruce, and one to the judge. The judge looked at Bruce, "Your honor, this is only about 11 pages, I think my client and I can review it during a short recess, or you could take up other actions while we review this." Court matters were running a little ahead of schedule that morning, so the judge had the clerk pencil them in after the next two short actions. They went out in the hall, not worrying about snoops except being overheard. The last time a judge found out that someone was bugging the courthouse, the head of the agency that did it spent time in the drunk tank for contempt. Lenny had read the affidavit almost through when they reached the far end of the hall. Bruce waited till he finished, and said, "Well?" Lenny shook his head, "They're after someone else. I've read about some of the events they are citing, but I sure don't know anything about them." That wasn`t entirely true. One of the "events" was one Lenny had put together, but when it didn't come off within a year, he had decided they had chickened out. Since the project he had put together took out much of an oil refinery, he was not surprised. Industrial sabotage on that scale took more than a little guts. When the plant finally blew up, Lenny watched the papers for weeks, but never found out if it was ruled accidental. The feds did not seem to be sure either, they only mentioned it as a possibility. The other accusations were split between cases where Lenny strongly suspected sister organization had done the deed, or industrial accidents where some organization had taken credit for what was probably an accident. Back in court Bruce complained to the judge that there was nothing substantial in the affidavit supporting the DSO, and that while his client did not have anything to hide, the government was asking to break into the confidential business records of a public interest group. And if they would not just forget the whole thing, he wanted more time to respond. The US Attorney would have asked for more time to respond if Bruce had not, so he was agreeable. The clerk set a date for 6 weeks off. -------- Lenny was paralyzed from the neck down. The judge was asking him for the password, and he could not remember it. The bailiff, clerk, Bruce and Mulroony were all talking in a huddle and he could not make sense out of anything they said, no matter how hard he tried. "This will do it!" one of them said, and jammed a furry dead fish under his nose. Lenny found he could move as he pushed it away. He woke up to find the cat had been licking his face and smelling of fish flavored cat food. 5:14 AM. "There isn't much point in trying to get back to sleep," he thought but Lenny flopped back on the bed. The cat started to purr and kneed the covers. Lenny absently rubbed its head, and thought about the next fundraising letter. The DSO had had the effect of galvanizing the GreenRage membership, so donations were way up, and for the first time in several years, there was more than just a little money in the bank account of GreenRage. Of course, it was flowing out almost as fast. Even though Bruce charged about half the going lawyer rate to public interest organiztions, fighting the DSO was going to cost them a bundle. "Just how much of the stuff on the disk is going to cause trouble," Lenny realized he had spoken outloud. If they asked for a special master, the membership list could be declared off limits. Unlike the old days, when the cops could look through outgoing mail at the post office, an electronic mail list was fairly secure. There wasn't much of interest in the finantial records either. Oh, a few thousands spent for sabatage material would be hard to account for if they really dug into it, but the bulk of the money was spent on saleries, office supplies, rent, and telecom charges. They could always claim the money was spent on spray cans and ceramic spikes for trees. And we can say we spent it for dope. Lenny grinned at this one. He had given up smoking dope, made him too paranoid. But, every fall some unknown but appreciated benifactor sent the office a plastic tub of the stickyest buds you could imagine. Perhaps one of their above ground efforts had saved some trees screening the "crop." Marge and Stel had split the tub the last two years. The problem was not the lastest project. Nor was it the one or two a month Lenny had put together over the last 3 years. They were long perged, and the disk space overwritten. And he didn't worry about the contents of the newletters. Presumably *somebody* on the list was a ringer, and the cops had a collection of *The GreenFlag.* What woke Lenny up in the middle of the night (besides his cat) was the stuff which they had on that WORM disk which *had not yet happened*. He could probably get away with claiming that the files on the events which had happened were interactive fiction based on news stories. Or could he? Nope, the damn files are dated prior to the "events," he thought. And, even though fewer than half of the projects he had worked on ever came off, there were at least three or four of them they could nail me on. Lenny turned the light on and pulled his palmtop out of the charging stand next to the bed. He stretched the keyboard out to full size and set there trying to put his thoughts in order. After entering his password, he brought up an organizer program. It prompted: State the problem. "I don't want to go to jail for conspiricy. The only way to stay out of jail is to keep the cops from looking through the GreenRage computer files. Or is it? If they can't convence the judge that they need to look through the files, then no problem. If they can, then they come asking me for the password. Assuming they can't crack the encryption-- which seems likely. If I give it, I go to jail, if I don't, I may get jailed for contempt, unless they give me blanket immunity. In either case, my days of managing monkey wrench projects are over." The organizer program came up with: You have used one or more legal terms. We recommend you submit your completed outline to a lawyer. It then proceeded to break the statements into an if-then-else logic tree which did not help Lenny much either. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Thu, 15 Oct 92 02:10:13 PDT To: cypherpunks@toad.com Subject: re: Game items... Message-ID: <2962.2ADD350B@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain Screw this fake scenario shit, here's some real ones: -- Safe sex in the age of AIDS. Guess what -- oral sex is safe. Cum in your mouth and stomach does not transmit HIV. *No one* is tracking healthy people. There were *two* "documented" cases (none of the above type) that seemed to be oral transmission of AIDS. Saying "oral sex is generally safe" would amount to condoning oral sex. Fat chance in the US. -- HIV is not always involved in AIDS. -- Not all people with AIDS die on schedule like the CDC says. AZT kills people. Many people live years and years. Some few haven't died since the "discovery" of AIDS in 85/86. No one is studying them either. -- Access to genuine information on RU-48 (?) the so-called abortion pill. Turns out it does some cool stuff re: breast cancer and even morning-after abortion. -- Access to sexuality information of all or any kinds. Not all people do the ole missionary position. Erotica of all kinds. If any of these things got a reaction out of you, then maybe they'd make good examples for privacy/encryption scenarios. * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Thu, 15 Oct 92 03:12:15 PDT To: cypherpunks@toad.com Subject: re: Re: Mr. Squirrel Message-ID: <2963.2ADD42BF@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain U> > Who uses ethernet?! :-) U> U> Everyone here at UC Berkeley. Well, yes, but my point was really that we don't have one problem with a single solution. What's a gaping hole in one system (physical access) is a big HUH? in another. * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Thu, 15 Oct 92 02:23:21 PDT To: gnu@toad.com Subject: Re: one time pads Message-ID: <199210150922.AA09387@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Re. your point about security and burglary. An intruder could copy a one-time pad, but of course an intruder can also copy the private key to an RSA system as well. I'll admit that physical key control is easier with public key systems: one just keeps one's key disc in one's personal possession at all times, and keeps a couple of backup copies in the hands of close trusted friends or family who understand and will take equal precautions. One could also design physical storage media which are intrusion resistant in the sense of self-destructing if tampered with or fed the wrong password; these would work as well for OTP keys as for RSA keys. In some conceivable applications, physical security can be insured as a matter of the vital interests of the participants. Again, I'm by no means trying to suggest that OTPs be considered for particularly wide application. Rather, that OTPs and a range of other systems be designed, implemented, and made available so that potential users can make their own informed choices. -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hollander Date: Thu, 15 Oct 92 17:08:10 PDT To: "George A. Gleason" Subject: Re: one time pads In-Reply-To: <199210150922.AA09387@well.sf.ca.us> Message-ID: <9210160007.AA18430@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Physical security is not a big issue for RSA (in the pgp implementation) because the secret key ring is itself encrypted. The problem is not so much physical-intrusion-to-get-the-key as it is physical intrusion aimed at modifying software. It would be easy to modify pgp so that the keys are logged, etc, in a way transparent to the user. This is why it is important to keep both the keys and the software that manipulates them off line. It is also important to keep the software from being tampered with. The best way to do this is to put the keys and the software on a hard disk, and put the hard disk in a computer, and carry the computer with you whereever you go. e From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hollander Date: Thu, 15 Oct 92 17:23:16 PDT To: Tom.Jennings@f111.n125.z1.fidonet.org (Tom Jennings) Subject: Re: Game items... In-Reply-To: <2962.2ADD350B@fidogate.FIDONET.ORG> Message-ID: <9210160013.AA19109@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain >-- Access to genuine information on RU-48 (?) the so-called abortion >pill. Turns out it does some cool stuff re: breast cancer and even >morning-after abortion. RU 486 (no, it's not Intel's pharmaceuticals division). This is actually a really good example of something that could be the subject of the game. Medical researchers need it because it has the potential to save lives. However, synthesis and import of it into the United States is banned, no matter what quantities are needed or what use it is needed for. It is an interesting and powerful substance and we should be doing research on it, but instead we are letting a small minority of people with no medical knowledge dictate the policy of our entire nation. Oh well. I hope to have European citizenship someday (especially if Geroge wins). e From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Peter Shipley Date: Thu, 15 Oct 92 18:03:41 PDT To: cypherpunks@toad.com Subject: Re: one time pads In-Reply-To: <9210160007.AA18430@soda.berkeley.edu> Message-ID: <9210160103.AA06271@edev0.TFS> MIME-Version: 1.0 Content-Type: text/plain > >Physical security is not a big issue for RSA (in the pgp implementation) >because the secret key ring is itself encrypted. The problem is not so much >physical-intrusion-to-get-the-key as it is physical intrusion aimed at >modifying software. To add my two cents, I once had some sensitive files solen from me. the cracker had modified the crypt command to record passwords and current directory (since crypt only works on stdin and stdout). In a matter of a few days they have my crypt password and enough infomation from my file to raise some real hell. Note that they did not bother with breaking the crypt or guessing the password they just rigged the system binaries. -Pete PS: this happend a year ago, and last month a copy of the files appeared on some systems owned by the Bay Area Air Quality Management District in SF (baaqmd). PPS: I *know* that crypt is insecure but I had tared/compressed it and des was not avalible on the systems I was working on. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Peter Shipley Date: Thu, 15 Oct 92 18:13:10 PDT To: cypherpunks@toad.com Subject: Who uses ethernet (Mr Squirrel?) In-Reply-To: <9210141810.AA14191@soda.berkeley.edu> Message-ID: <9210160112.AA06320@edev0.TFS> MIME-Version: 1.0 Content-Type: text/plain > >Who uses ethernet?! :-) > I do at home, want to tap it? simple. just crawl under my house and pug in to any jack, don't owrry about bringing batteies there are plenty of 120V outlets. -Pete PS: and soon I plan on using ISDN to bridge by home ethernet backbone onto the internet From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Peter Shipley Date: Thu, 15 Oct 92 18:20:15 PDT To: Tom.Jennings@f111.n125.z1.fidonet.org (Tom Jennings) Subject: Re: Game items... In-Reply-To: <2962.2ADD350B@fidogate.FIDONET.ORG> Message-ID: <9210160119.AA06370@edev0.TFS> MIME-Version: 1.0 Content-Type: text/plain Tom, you did not sign the document with you pgp key, how am I supposted to know that Eric did not edit this in hopes of me having oral sex with my girlfriend? how can I trust this is the real Tom.Jennings and the NutraSweet version?!? > >Screw this fake scenario shit, here's some real ones: > >-- Safe sex in the age of AIDS. Guess what -- oral sex is safe. Cum in >your mouth and stomach does not transmit HIV. *No one* is tracking >healthy people. There were *two* "documented" cases (none of the above >type) that seemed to be oral transmission of AIDS. Saying "oral sex is >generally safe" would amount to condoning oral sex. Fat chance in the >US. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Fri, 16 Oct 92 02:28:15 PDT To: shipley@tfs.COM Subject: Re: Who uses ethernet (Mr Squirrel?) Message-ID: <199210160927.AA11421@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Tom, if you're interested in ISDN, my organisation (Integrated Signal) will probably be in a position to hook you up early next year. We're 90% certain to be putting in a network very close to your neighborhood. -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: "Fen Labalme" Date: Fri, 16 Oct 92 13:38:20 PDT To: "Cypher Punks" Subject: Re: re- Game items... Message-ID: <9210162038.AA10880@relay1.UU.NET> MIME-Version: 1.0 Content-Type: text/plain Subject: RE>re: Game items... >> -- Safe sex in the age of AIDS. Guess what -- oral sex is safe. >> Cum in your mouth and stomach does not transmit HIV. Just don't have eaten chips or have flossed your teeth beforehand. HIV is transmitted semen to blood or blood to blood. >> -- Access to sexuality information of all or any kinds. Not all >> people do the ole missionary position. Erotica of all kinds. I can't resist plugging the San Francisco Sex Information hotline. Call 415/621-7300 with your questions of how to find it, do it better, find someone (animal? thing?) with which to do it with, etc.... They give good phone. Enjoy! Fen From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Peter Shipley Date: Fri, 16 Oct 92 11:47:34 PDT To: cypherpunks@toad.com Subject: Re: Who uses ethernet (Mr Squirrel?) In-Reply-To: <9210161803.AA15862@newsu.shearson.com> Message-ID: <9210161846.AA08767@edev0.TFS> MIME-Version: 1.0 Content-Type: text/plain > >Old hat -- I still remember the days of yore (only about five years >ago, but it seems like an eternity) when I worked at bellcore and >Phil Karn revealed to me that his home network was on the internet. >All I've got from home is a wimpy little UUCP link to this very day. What I was pointing out was how trivial it would be to compromise such networks (not that I have such a network). From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Fri, 16 Oct 92 11:34:23 PDT To: shipley@tfs.com Subject: Who uses ethernet (Mr Squirrel?) In-Reply-To: <9210160112.AA06320@edev0.TFS> Message-ID: <9210161803.AA15862@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: Peter Shipley >> >>Who uses ethernet?! :-) >> >I do at home, want to tap it? simple. just crawl under my house and >pug in to any jack, don't owrry about bringing batteies there are plenty >of 120V outlets. > -Pete >PS: and soon I plan on using ISDN to bridge by home ethernet backbone > onto the internet Old hat -- I still remember the days of yore (only about five years ago, but it seems like an eternity) when I worked at bellcore and Phil Karn revealed to me that his home network was on the internet. All I've got from home is a wimpy little UUCP link to this very day. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Arthur Abraham Date: Fri, 16 Oct 92 18:04:53 PDT To: hh@soda.berkeley.edu Subject: Re: Game items... Message-ID: <199210170104.AA06520@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain re RU-486: has recently been proven to make a nifty "morning-after" pill (is this abortion? only if you believe in the sanctity of blastula) and a study in (I believe) S. CA. is beginning on effectiveness in brain tumors... seems as if this drug has possible wide theropeutic (aw, who can spell?) uses beyond directly sex-lined situations. And RU-P5 is due out 2Q93. -a2. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Arthur Abraham Date: Fri, 16 Oct 92 18:46:46 PDT To: hh@soda.berkeley.edu Subject: Re: Game items... Message-ID: <199210170146.AA14728@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Abortion Pill's Potential Use on Tumors Adds to Debate Over U.S. Market Entree ---- By Ron Winslow Staff Reporter of The Wall Street Journal DD 10/12/92 SO WALL STREET JOURNAL (J), PAGE B8 LP LOS ANGELES -- Medical researchers are studying a potential new * use for the controversial French abortion pill RU-486: treatment of * benign brain tumors. A large-scale clinical trial was launched at the University of * Southern California last week to determine whether the drug effectively slows or halts growth of meningiomas, tumors that occur * on the surface of the brain and spinal cord. TX The answer won't be known for several years, but the study adds another dimension to the debate over whether the drug, known as mifepristone, should be allowed on the market in the U.S. Rousell-Uclaf, its manufacturer, hasn't sought marketing approval in the U.S. because of the heat of the political battle over abortion. The study raises the possibility that a drug that could benefit some patients won't become available because of a political dispute over another application. "There is a good chance there will be legitimate uses for this drug outside of contraception and abortion," said Steven Grunberg, an oncologist at the USC School of Medicine. "Whether U.S. regulatory officials feel this will be sufficient for licensing will be up to them." A study published last week found the drug to be effective as a contraceptive when taken shortly after sexual intercourse. It is already used in France, the United Kingdom and Sweden to induce abortions within the first nine weeks of pregancy. Meningiomas account for 15% to 18% of all tumors in the central nervous system, and while they are benign -- meaning that they don't spread to other parts of the body -- their growth can lead to such problems as seizures, blindness or paralysis. Most can be removed by * surgery, but some grow so close to crucial brain structures that surgery isn't possible. Dr. Grunberg told reporters at a science writers' conference sponsored by the American Medical Association that the large-scale * trial of RU-486 for the tumors comes after a small pilot study of 28 patients turned up encouraging, though not definitive results. In the small study, eight patients experienced improvement in * symptoms or had minor reduction in tumor size, according to brain scans. In a few other patients, growth of the tumor stabilized after treatment began. While not overwhelming evidence of effectiveness, the results were nevertheless sufficient to persuade the Food and Drug Administration to approve a large study that will involve 200 patients at several U.S. medical centers, and will be based at USC, Dr. Grunberg said. Results from the trial aren't expected for at least four years, and based on current medical practice, only a small number of people * would probably benefit from use of RU-486 in meningiomas. The study might have broader impact by drawing attention to other potential benefits of a drug that isn't available in the U.S. because its primary application is to induce abortion. Dr. Grunberg said the drug is also being studied as a treatment for breast cancer, endometriosis and a disorder called Cushing's disease, which is characterized by obesity and hypertension. Several other trials have been approved by the FDA, he added, though none has progressed as far as the meningioma study. * He said his research team came upon RU-486 as a candidate for treating meningiomas because the drug blocks the action of progesterone, a hormone that appears to promote growth of the tumors. "We didn't set out to make a political statement for * RU-486," he said. "It just appeared to fill the bill for what we're trying to do." ******************************************************************** snarf -a2. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: wixer!pacoid@cs.utexas.edu (Paco Xander Nathan) Date: Fri, 16 Oct 92 22:31:21 PDT To: cypherpunks@toad.com Subject: game items Message-ID: <9210170316.AA05655@wixer> MIME-Version: 1.0 Content-Type: text/plain For that matter, vibrators are illegal now for sale in Texas. Most all sex toys have to be renamed as "personal enhancement devices" or sumsuch in retail outlets to avoid seizure. Also, drug testing decoy materials - like powdered fake urine - are illegal in TX. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: fnordbox!loydb@cs.utexas.edu (Loyd Blankenship) Date: Sat, 17 Oct 92 07:16:32 PDT To: cypherpunks@toad.com Subject: Intro & Keystone Message-ID: <9210170556.AA009js@fnordbox.UUCP> MIME-Version: 1.0 Content-Type: text/plain First, as a newcomer, and introduction. My name is Loyd Blankenship. I am the Product Development Manager at Steve Jackson Games, and was the employee raided by the Secret Service that set off the formation of the EFF, our lawsuit against them, and much angst within the government. I also use the nome de' plume "The Mentor" when traversing the computer underground. On to stuff relevant to the list: A group of us here in Austin have spent a great deal of time discussing the advantages of RSA-encrypted e-mail. I'm putting a BBS back up later in the year, and would like to offer secure communications to my users. Since the threat of seizure is very real (the feds still have over $10,000 (1989 street price) of computer equipment of mine since I'm "still under investigation"), this needs to be implemented before the message is ever written to hard disk. To implement this, I'm currently trying to get PGP up on my Amiga, then write the necessary C & AREXX functions to link it in with my BBS's (DLG Pro) email function. The outgrowth of this was the Keystone project. We're going to attempt to get everyone in Austin cyberspace public-key capable, and get a master keyring that will be regularly distributed via a trusted system to other nodes in town. Ideally, you would be able to send RSA-encrypted email from any bbs on any of the local nets to any other bbs -- even if all you know is the destination address. We're going to do this by attempting to make the bbs PGP-friendly. All the user has to do is generate a key pair. The two potential weak links in this chain are line security and key validation. The first is almost insurmountable -- unless the user takes the time to d/l a complete copy of PGP and the Austin Keystone Keyring and encrypt the mail on their home system. But if not, then they have to live with the chance that someone is data-tapping. The second will rely on face-to-face identification -- this is why we're making this a local effort. It will probably be Christmas (when I have a 3-week vacation) before serious strides are made in this, but I'm interested in any comments people may have. Loyd p.s. What is this "game" you are talking about? *************************************************************************** * loydb@fnordbox.UUCP Once you pull the pin, * Loyd Blankenship * * GEnie: SJGAMES Mr. Grenade is no longer * PO Box 18957 * * Compu$erve: [73407,515] your friend! * Austin, TX 78760 * * cs.utexas.edu!dogface!fnordbox!loydb * 512/447-7866 * *************************************************************************** From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Sat, 17 Oct 92 13:51:21 PDT To: cypherpunks@toad.com Subject: one time pads In-Reply-To: <199210150922.AA09387@well.sf.ca.us> Message-ID: <9210172050.AA28275@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain >Again, I'm by no means trying to suggest that OTPs be considered for >particularly wide application. Rather, that OTPs and a range of other >systems be designed, implemented, and made available so that potential users >can make their own informed choices. One time pad systems are expensive enough and in uncommon enough use that I doubt they are going to get written as free software. I personally am not going to work on them, because I don't want to go buy the necessary hardware to generate and hold sufficient key material for a practical application. You also need hardware random number generators for a secure OTP system. Such boxes are not readily available, or come cheap. While not obvious, making random bits is a very deep problem. See Knuth volume 2 for some insights. I suspect that this same argument holds for all the rest of the people in the group as well. I don't know of anybody who wants to implement this system for themselves, given the cost involved. Cryptography is all economics, and the economics here are that one time pad systems are expensive enough that the software that gets written for them will be for in-house use or will be commercial. In either case, someone is paying someone else for developing the software. It might be possible that there are enough people who do want this that there is some money for development. A perfectly possible outcome is the creation of a consortium to hire some implementers who would make some gnu-ware. Such organization does not exist. Until it does, an off-the-shelf OTP system won't exist. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Sat, 17 Oct 92 14:15:21 PDT To: cypherpunks@toad.com Subject: physical security In-Reply-To: <9210160007.AA18430@soda.berkeley.edu> Message-ID: <9210172114.AA28842@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Physical security for pgp is also necessary if you store your pass phrase in memory. As far as modification, detection is good enough, but you'd better make sure your program to detect modifications is not itself compromised! (Does anybody detect an imminent arms race here?) Eric Hollander is correct. Ideally, your keys and your encryption mechanism should be kept secure. At some point in the future, a small card which contains all of this will be standard equipment, as well as a port to plug it into. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Sat, 17 Oct 92 15:10:14 PDT To: cypherpunks@toad.com Subject: Keystone In-Reply-To: <9210170556.AA009js@fnordbox.UUCP> Message-ID: <9210172209.AA29900@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain First, let me congratulate Loyd and the others involved with Keystone for working towards the creation of a local distribution mechanism for keys. Every city in the U.S. needs something like this. If it's not happening in your area, start it. Start by getting PGP and making your own key. Then exchange keys with people you know. We have members of the list in many parts of the U.S., Canada, and Europe. There's plenty of work to do. Look around. If no one else is doing this, you should. >Ideally, you would be able to send RSA-encrypted email from any bbs >on any of the local nets to any other bbs -- even if all you know is >the destination address. We're going to do this by attempting to make >the bbs PGP-friendly. All the user has to do is generate a key pair. There are, roughly speaking, two kinds of privacy; one is provided, and one is defended. Provided privacy is unstable, since the person using the privacy does not create it. Defended privacy is stable, because those who want privacy create it themselves to the level at which they want it. Both systems do provide privacy, no mistake. I would be hesitant to implement a system that _only_ required a user to generate a key pair. This, for the users, is too much provided privacy. It will not teach the users how privacy really works, nor will it give them any good idea how their privacy is being maintained. Defended privacy does not need to be difficult. I would spend effort, instead of modifying BBS software, to make it easier for users to handle encrypted email with their own terminal programs. Now, any privacy is better than none. I don't really know if it is easier to modify your BBS or your modem program. But all other things being equal, make it easier for users to maintain their own privacy. >[...] a master keyring that will be regularly distributed via a >trusted system to other nodes in town. Again, trusted systems can turn into provided privacy. If there is a distributed solution you can think up, use it. >The first [weak link, line security] is almost insurmountable -- >unless the user takes the time to d/l a complete copy of PGP and the >Austin Keystone Keyring and encrypt the mail on their home system. This should not be such an onerous task. It might be now, but that can change. Finding ways for users to manage keys, to get keys, and to look up keys are all interesting and useful problems to solve. Every user should encrypt outgoing mail on the home system before it leaves and decrypt incoming mail on the home system after it arrives. If this is not easy, it should be made easy. Not every user need have the complete directory on their own system. They merely need a way to communicate with those that they want to. This probably means a directory service, where people can download keys for the people they want to communicate with. Moving around a complete directory does not scale well. As far as BBS support, if I want to respond to someone and I don't have the corresponding key, I should be able to initiate a zmodem transfer of that key relatively easily, for instance without leaving the discussion area to go to a download area. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Sun, 18 Oct 92 01:21:11 PDT To: hughes@soda.berkeley.edu Subject: Re: one time pads Message-ID: <199210180820.AA24894@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Sigh... well, I guess I can see if the people I know who are interested, would do it as a freebie... Funny thing is, when I first looked into crypto for dissident purposes, back in 1981 or so, I was interested in a PKS implementation, but someone else in my circle persuaded me that OTPs would be preferable in some cases. Now here we are with a PKS and I'm still making noises about OTPs. Guess the debate is closed for the moment... congratulations, y'all, for good arguements in a good tone. Now the well is about to close for the night, so I gotta scoot. Be back soon... -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: hkhenson@cup.portal.com Date: Mon, 19 Oct 92 02:21:17 PDT To: cypherpunks@toad.com Subject: one time pads. Message-ID: <9210190136.1.13588@cup.portal.com> MIME-Version: 1.0 Content-Type: text/plain I can suggest a way to "distribute" a one time pad, even though the people never meet. Just agree over the phone on which CD ROM to use, and some forumula for an offset into the CD ROM. You might want to throw away some of the data to make the bit stream less regular, but with 600 meg, who cares? Keith Henson From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Mon, 19 Oct 92 08:48:48 PDT To: cypherpunks@toad.com Subject: one time pads. In-Reply-To: <9210190136.1.13588@cup.portal.com> Message-ID: <9210191548.AA01490@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Keith's CD-for-a-pad idea is a variant of a book code. In a book code, parts of the key are in various standard books, often the bible. Advantages: easier key distribution. Disadvantages: key material is public. Should an internal spy learn the few bits of addressing information (which CD, where), the cipher is compromised. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Mon, 19 Oct 92 17:08:26 PDT To: hkhenson@cup.portal.com Subject: one time pads. In-Reply-To: <9210190136.1.13588@cup.portal.com> Message-ID: <9210191948.AA13028@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: hkhenson@cup.portal.com >I can suggest a way to "distribute" a one time pad, even though the >people never meet. Just agree over the phone on which CD ROM to use, >and some forumula for an offset into the CD ROM. You might want to >throw away some of the data to make the bit stream less regular, but >with 600 meg, who cares? Keith Henson This seems equivalent to the old "dictionary" or "book" cyphers that people sometimes used. Good cryptanalysts broke them routinely. I'll leave it to your imagination how one might do it, but I'll just note that if you picked a few arbitrary bytes, say bytes 30-40, of all the CDs in the record store, you would find that those few bytes likely distinguish all but prehaps a token number of CDs. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Mon, 19 Oct 92 17:09:14 PDT To: hughes@soda.berkeley.edu Subject: one time pads. In-Reply-To: <9210191548.AA01490@soda.berkeley.edu> Message-ID: <9210192003.AA13314@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: Eric Hughes >Keith's CD-for-a-pad idea is a variant of a book code. In a book >code, parts of the key are in various standard books, often the bible. >Advantages: easier key distribution. >Disadvantages: key material is public. Should an internal spy learn >the few bits of addressing information (which CD, where), the cipher >is compromised. Actually, in practice internal spies were almost never needed to break book cyphers. They in fact provide only laughable security. Traditional ones didn't even require that the cryptanalyst ever determine what book was being used! Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nobody@soda.berkeley.edu Date: Mon, 19 Oct 92 23:22:30 PDT To: cypherpunks@toad.com Subject: More private PGP...? Message-ID: <9210200622.AA10349@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain One of the things I've noticed about PGP is that it makes it pretty obvious that you're sending an encrypted message. The big -----BEGIN PGP MESSAGE----- at the start pretty much gives that away. In most cases, this is fine, but sometimes it may not be desirable to make it this obvious. Sending encrypted messages may call unwelcome attention to yourself. Also, some people are experimenting with packet radio on the amateur bands, and it's not legal to send encrypted messages there. What I think would be nice would be an "innocent" mode for PGP in which it created files which looked like something else. For example, what if your encrypted output file looked like: begin 666 testpat.gif MI\44:#G4D>QQXR!-M,Z20O1K&5D0, 5-4F.X<%MT M2:V94,K;XE@B?]%IHF+_WGI%(]#=F]/[LV+&! M,NH0(!3B35CW#!-Z7"B_L'=-C 8DLB-(J R"3?EE9<.>QE4Y?T$66IA7B@W? end This will be recognizable, if you've seen many, as a uuencoded file, a common encoding for non-ascii files. The header line suggests that it is a graphics file. Tons of these types of files are sent across email networks every day. Sending your encrypted messages in this form would give you a lower profile. Still, if someone goes to the effort to uudecode your message, and examines the resulting file, it will be obvious that it's not a GIF file because it lacks the proper headers. Instead, with the current PGP implementation it will be obvious that it is in fact a PGP file, because the header format matches the PGP spec. Again, I think it would be better if PGP in this mode were able to produce a file without headers which will give away what it is. Even better would be the ability to mimic headers of some other types of files, such as the .ZIP, .ZOO, or Unix "compress" format which are often used in binary files people mail around. Another thing that I think is kind of bad about PGP in the context of avoiding traffic analysis is that it puts the key ID of the destination person in the header. There was some discussion during development of a mode in which no key ID information would be in the header; the only way you'd have of knowing if the message was for you was to try decrypting it. (There is a checksum which is used internally to tell if the decryption was done with the right key.) This way you could broadcast messages to some group, and no one could know which person in the group you were sending to. These "anonymous destination" messages could be encoded with a key ID of zeros, and the PGP software could easily be modified to let the user try a decryption on such a message, reporting success or failure. How useful do these kinds of features seem to people? Would they really be helpful or is this just paranoia? Hal 74076.1041@compuserve.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Tue, 20 Oct 92 01:56:22 PDT To: hkhenson@cup.portal.com Subject: Re: one time pads. Message-ID: <199210200855.AA27037@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Re use fo CD ROMs for OTPs. That would seem to be a variation on the old theme of the book cipher, which is *not* random and therefore *not* secure. Also, agreeing on key procedures over the *phone* in *clear voice* is kind of like sex without a condom. Not secure. Not safe. Potentially deadly. While we're on the subject of link encryption, the same response pertains to the suggestion made by someone from SJG here (whose name I ought to know but my memory for names has more holes than Bush's economic plan) about key distribution and transmission of cleartext over phone lines. It *doesn't matter* if it's encrypted at the BBS server, if it goes in clear over the phone. Keyword in context recognition is no problem when dealing with ASCII. Various agencies (you know who) have raised this to a fine art. The telephone line is precisely the link in the chain which is weakest and needs most to be protected. If the nasty-wasties break down your door and go for your hard drive, it's already too late. Like worrying about a condom after the fact. Now as a matter of record, it's been demonstrated that a processor emits electromagnetic radiation back over the phone lines as well as electrical power lines, which can be picked up at a distance. So consider for a moment that there is a BBS serving dissidents, who Big Brother wants to monitor. Seeing all the encrypted traffic, they install a device on the phone line and the AC to pick up what the mircoprocessor is doing. And they see it doing crypto, and they see the cleartext which is recovered, and get the keys, and the whole damn thing may as well be transparent. So for BBSs and such, I would argue that it's necessary to have electromechanical relays to isolate the computer from the phone lines when encrypting or decrypting; ideally isolate it from the AC as well (using an uninterruptable power supply, which will run the computer on batteries for some period of time, say 45 minutes). So you have a great big red toggle switch next to the computer, and for some period during the day when doing all the crypto processing, throw the switch to the Safe position to get it off the phones and AC lines. This might make BBS use a little less convenient (in that email becomes available the day after it was posted), but at least it's not literally leaking everyone's secrets into the airwaves. This general area is part of a larger topic called TEMPEST. Anyone else interested in pursuing this angle...? -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Tue, 20 Oct 92 02:16:09 PDT To: nobody@soda.berkeley.edu Subject: Re: More private PGP...? Message-ID: <199210200915.AA27714@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Hal, I think those would be vry useful. Now of course, we don't want to advocate that radio users in the United States do anything like sending ciphertext over the airwaves, but we might want to develop something that we can ship to the Gusanos who want to take Cuba back for the Mafia, or maybe in a better vein, something that the Tien-an-men kids can use when overthrowing the Commies in China. Good ideas about message headers. Since the source code for PGP is widely available, it would seem a straightforward matter to alter the program to include the new features. What I'd really like also is a Mac version.... -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nobody@soda.berkeley.edu Date: Tue, 20 Oct 92 07:52:54 PDT To: cypherpunks@toad.com Subject: Tempest. Message-ID: <9210201452.AA01970@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Re TEMPEST technology: (Note that TEMPEST is the technology for _protection_ against electronic eavesdropping on your computer emissions. There is presumably a code word for performing such snooping, but it must be secret.) I've read that the worst emitter is your CRT screen. In fact, they say that you can sometimes put a TV-type monitor next to your computer monitor and get a faint, ghosty image of your CRT screen on the second monitor. If you get this much without any amplification, it's under- standable that high-quality equipment can pick up an image from a greater distance. The best way to avoid this, IMO, is to use a laptop. The LCD display of a laptop does not use the large electromagnetic fields that a CRT display does. Laptops also use lower power levels in general so they should emit less. I don't really know whether the "raw" CPU activity of your computer could be picked up and interpreted at a distance. With as many different signals as there are on the address and data busses, along with all the other wires you have, I can't really see how anything meaningful could be picked up with remote monitoring. It would seem that they'd be totally jumbled. So, for BBS use, where the system is operating automatically, I'd say that it would be OK as long as you don't display any cleartext or key/password information on the screen. You could just turn the monitor off when it's operating. For home use, a laptop has the advantage that it can have greater physical security (because it's smaller and more portable), you can carry your decryption keys with you, you can download to it at work or school and decrypt without trusting the multi-user systems they have there, and it should be relatively immune to electro- magnetic snooping. Hal 74076.1041@compuserve.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Tue, 20 Oct 92 08:33:46 PDT To: cypherpunks@toad.com Subject: More private PGP...? In-Reply-To: <9210200622.AA10349@soda.berkeley.edu> Message-ID: <9210201533.AA07309@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain >One of the things I've noticed about PGP is that it makes it pretty >obvious that you're sending an encrypted message. [...] Sending >encrypted messages may call unwelcome attention to yourself. First, let me get on record as saying that Hal's "innocent mode" is a good idea that should be implemented. But it's not really a good long-term solution from a social point of view. Encrypted traffic should become the norm, not the exception. Flagging that you're sending encrypted traffic should be encouraged. When questioned about this, people should respond in shocked tones "What do mean? Aren't you encrypting _your_ email?" and then proceed to suppress gentle laughter at them when they say no. When it's cool to encrypt, only the uncool will be plain. So, then, more peer pressure! Consider someone asking you about your encrypted mail to be an opportunity to start a conversation about their position on personal privacy. When your sysadmin asks why your mail can't be read, tell him you are defending your privacy and ask if there is any problem with that. Then, when the sysadmin puts in a filter for PGP traffic, use innocent mode. >Another thing that I think is kind of bad about PGP in the context >of avoiding traffic analysis is that it puts the key ID of the >destination person in the header. Absolutely. Ditto for signatures. Both should be able to be selectively removed. In any case, it should be possible to have nothing appear on the outer envelope. Another feature for PGP would be automatic message padding. To properly do a mix you need to quantize the message lengths. If PGP were to automatically pad with random data, it would save a lot of integration work for the mix. PGP already has a random number generator, after all. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Tue, 20 Oct 92 09:15:10 PDT To: cypherpunks@toad.com Subject: Tempest. In-Reply-To: <9210201452.AA01970@soda.berkeley.edu> Message-ID: <9210201614.AA13762@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain About Tempest. The ability to monitor is real; it's more powerful than you would first imagine. You can get a lot of insight into what is possible by looking at what is sold as parts for Tempest certification. There is some trade publication devoted entirely to such matters; it's called EMI/RFI News, or Interference Protection News, or something like that. It's free to qualified subscribers. The articles are interesting, but cannot delve into the really interesting stuff. But the ads! Look at what people are selling, and remember that it is protecting against something. Stuff like copper impregnated gasket material, both for computer cases and for doors (in walls). Copper braid and cloth. Conductive glues and caulks. Special connectors. Electrical isolators. Fiber optics. (Aside: If you don't know how to be a qualified subscriber, you're no hacker. Look closely at the subscription card and then figure out where the publisher of a free magazine gets its money.) What is possible? CRT monitoring. A Dutch guy named van Eyck demostrated six years ago or so a CRT monitoring system which he built out of spare parts. It consisted of an TV roof antenna, a non-detent UHF tuner (which you can make yourself by removing the detent plate from an old TV), and a multi-scanning monitor. No amplification beyond what was in the tuner, no sync stabilization, no special directional antennas or any other tricks. He was able to reliably pick up monitor emissions from 100 meters, if I remember correctly. Fancier equipment knows what your screen sync rate is, uses bandpass filters, uses better antennas, knows to look for mostly-persistent frame information, looks for emissions signatures, and is able to read one CRT out of a hundred at half a mile. I suspect this is a low estimate of the ability of modern equipment. Hal mentions using flat panel displays to combat emissions. This works, as evidenced by the continued existence of Grid Computer. Remember Grid, who came out with these way-expensive gas plasma laptops around 1985/6? The reason they sold so many of those and are still around was that a large number of them were Tempest certified. (Even larger revenues!) I understand that the Tempest spec Grids had a thin layer of gold foil in front of the screen, even so. Yes, gold thin enough to see through. Signal wire monitoring. Using twisted pair or coax cable, reduces transmitted energy down to very low levels, improving energy transfer and reducing monitorability. But even with zero radiated energy there is still the near field of the wire which can be inductively tapped. No conductive contact is necessary. If you can put a wire next to my phone line somewhere, you can tap my phone. It's by nature a high impedance tap, requring sensitive ampilifiers but at the same time difficult to find even by a reflectometer. Without a twisted pair, the situation is worse. Keyboards for the PC use a serial protocol at a fixed frequency. The cables are not twisted pair. I haven't heard anything about that specifically, but I presume that keystrokes can be read extremely easily. CPU monitoring. Yes, it's possible. I've heard that it is possible to actually run a CPU in parallel with a monitored one. In order to do this, you need to correlate signals in real time across a fairly wide RF spectrum. Each CPU pin or I/O bus signal occurs in a different physical location inside the case. The case is active in terms of emmission, reflecting signals around like mad. All these different physical locations and reflections give rise to phase differences and interference patterns. Once you figure out what the signatures of the various signals are, you can separate them out from each other by correlation and deconvolution. George's concern about emissions through phone lines falls into this category. Other stuff. I've heard rumors about using microwave pinging to determine stuff about electrical equipment. Or about implanting passive devices that alter the EM field locally in order to make monitoring easier. It's safe to presume that there is some amazing stuff going on. Read The Puzzle Palace for more hints. (Like the valley in WV which is one big antenna.) Emissions monitoring is also all economics. The price to monitor increases with each more sophisticated attack. CRT's are easy, CPU's are hard. I would like to see public research in this area, just like there is public research in cryptography. Until the public has a better idea of what various attacks cost, there can't be rational decisions about emissions security. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hollander Date: Tue, 20 Oct 92 11:40:12 PDT To: nobody@soda.berkeley.edu Subject: Re: Tempest. In-Reply-To: <9210201452.AA01970@soda.berkeley.edu> Message-ID: <9210201839.AA08315@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Like I said, just carry everything (keys and software) on your laptop. As soon as the Mac port of the pgp is finished, that's what I'll do. e From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: fnordbox!loydb@cs.utexas.edu (Loyd Blankenship) Date: Tue, 20 Oct 92 14:43:30 PDT To: soda.berkeley.edu!hughes@cs.utexas.edu Subject: Re: Keystone Message-ID: <9210201753.AA009kv@fnordbox.UUCP> MIME-Version: 1.0 Content-Type: text/plain :I would be hesitant to implement a system that _only_ required a user :to generate a key pair. This, for the users, is too much provided :privacy. It will not teach the users how privacy really works, nor :will it give them any good idea how their privacy is being maintained. I take the opposite view -- I dare *not* supply such a system. Any user that is interested enough in 100% privacy will be encouraged -- both from the email prompt and through the message bases/file areas -- to d/l a copy of PGP. I'll probably write a tutorial on using it as well. But many users do not have the interest/time/ability to set up PGP on their home system. For them, I want to provide the best possible privacy given the ease with which anyone who can find their local LMOS can tap (voice or data) a line... :Defended privacy does not need to be difficult. I would spend effort, :instead of modifying BBS software, to make it easier for users to :handle encrypted email with their own terminal programs. I don't have my user's terminal program -- I *do* have the bbs software. :Again, trusted systems can turn into provided privacy. If there is a :distributed solution you can think up, use it. I don't know any way to maintain an up-to-date, central keyring without someone being in charge of regular updates. I'd make it available via Fido, FTP, BMS and regular d/l. Loyd *************************************************************************** * loydb@fnordbox.UUCP Once you pull the pin, * Loyd Blankenship * * GEnie: SJGAMES Mr. Grenade is no longer * PO Box 18957 * * Compu$erve: [73407,515] your friend! * Austin, TX 78760 * * cs.utexas.edu!dogface!fnordbox!loydb * 512/447-7866 * *************************************************************************** From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tom.jennings@f111.n125.z1.FIDONET.ORG (tom jennings) Date: Tue, 20 Oct 92 16:26:17 PDT To: cypherpunks@toad.com Subject: Depository Proposal (revised) Message-ID: <3194.2AE470FA@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain Just thought I'd forward on something that's cooking in Fidoland. This guy has code running already. I haven't even looked at it yet myself If it's a crock, please be kind and forward suggestions to the author... tomj@fidosw.fidonet.org -------------------- begin forwarded message (Please note that examples still have not been included with this text) Public Keys Depository Proposal By Marcos R. Della (1:125/180 or marcos@zippy.sonoma.edu) Def: De.pos.i.to.ry (di-POZ-i-tohr-ee) n. a storehouse, a place for safekeeping of things -+---------------------------------------------------------------------+- With the latest release of the PGP20 program, public key availability has fallen into the hands of the individual. This provides a relative degree of security over messages that are sent from user to user in various formats (text, binary, etc) over different transportation mechanisms. I will not go into the system that allows public keys to work nor public key history. Instead I'll point you to the rather complete documentation that comes with the PGP program. Unfortunately, there is a major drawback to this system (also pointed out in the PGP documentation). Public key distribution has few security elements involved to insure the validity of a particular key. PGP attempts to address this problem by providing a "signature" system to each public key to give reasonable validity to its origin. Unfortunately, this depends upon trust of the individual who signs the key to begin with. Who polices the policemen? Unfortunatly, the issue of key validity is yet another topic that cannot be easily addressed since authenticity lies in one persons trust of another. Yet there still needs to be a system in which keys can be distributed or held for later use. This system should be multiply redundant and have some degree of immediate access in order to make the information stored useful. One such system would be a depository, a place to store public keys for later retrieval. This proposal will attempt to describe a system whereby you can get around the validation of public keys problem without requiring someone to police the Depository itself! -------- Problems Involved: - How do you know the key depositor isn't faking his/her keys? - How do you verify (at the depository) that a key being deposited is from the key originator or is even valid? - What is to prevent the depository from faking keys that is "signs"? - How can this system be resonably redundant and easy to access? First off, the depository is NOT a validation center. The system never will verify the users as existing or if they are even honest users. The depository key signature only verifies that the key has been deposited and is available for access at any time. Again, the depository DOES NOT verify users, only the fact that a deposit has been made. (A better form of deposit slip) If a user wants to deposit his/her key, what is to prevent the sysop from intercepting this public key, making a substitution replacement, and then forwarding the new public key? Unfortunately, there are sysops out there that have already done this in some respects. Thereby the system has to place the responsibility upon the user for key deposit verification. To prevent the sysop from changing the deposit, the user should use the Depository Public Key (hereafter referred to as DepoKey) to send his/her key for deposit. Again, what prevents the "bad" sysop from just throwing this message away (obviously he can't read it) and sending a fake message (also encrypted with the DepoKey)? Although this eventually thwarts the entire system (the sysop cannot fake the users public key unless the user uploads it in plain text to the sysop), it still causes problems. To prevent this, the user should include some sort of text in the deposit that the depository will mail back to the user, ENCRYPTED along with the user's public key. When the user receives a valid message back that contains his original text, things are fine. If the user does not receive a response in a few days or gets an incorrect return message, then the user should send a cancel message to the depository and re-deposit his or her key. The complete the handshake, the user should send an authentication back to the depository stating that the key was recieved correctly (instructions on how to do this should be returned with the key). If a return reciept isn't back in a resonable period of time, the depository will remove the key from its deposit keyring. NOTE: This will never invalidate a public key, it will only prevent it from being distributed via the depository system. What is to prevent the depository from faking keys that it "signs"? Well, in order to be effective with fake keys, you need to be in the transport path of the messages that you are planning on "stealing". Since the depository is not a major hub or node (except possibly to a few people) this negates any effect of faking keys. Also, once a user has received verification that the depository has his public key, he can then also post it anywhere. The depository will return his public key with a depository signature on it. This allows the user to upload a verified key to anywhere. When keys are distributed with a depository signature on them, then they are on file with the depository in case someone wants to withdraw them later. As long as the public key for the depository is made worldwide public, this system will work. As for creating a multiply redundant system, there should be several sites that are listed as depositories. These systems will on a weekly basis, exchange acknowledged keys (ie, keys that have undergone the handshaking process) with one another. A user can then request a key from ANY of the depository sites and get the same information. For those that want certified keys (other than from the users) such as a BBS system needing the public key of another, there will be a withdrawal mechanism built into the depository to pull single or multiple keys. Also, the complete public keyring may optionally be pulled (FREQing). ----------- The actual mechanism: Below is the Depository Public Key. Any public key that has been signed with this depository key will be assumed to have undergone the handshake process to verify that the originator of the key pair has in fact issued a valid key. This signature only verifies the deposit (a reciept). *** THIS KEY DOES NOT VERIFY THE IDENTITY OF THE USER!!! ONLY THAT *** *** THE USER WAS IN FACT THE ORIGINATOR OF THE PUBLIC KEY *** *** AND HAS DEPOSITED IT INTO THE PUBLIC KEY DEPOSITORY!!! *** For user identification, there should be a second or third signature from a BBS or known friend. This will give the key a verification level. If the user wishes to deposit a key with another person's signature, there will be no problem since the handshake method still insures the source and destination of the message. (Note: This is preferred since depository keys will then be distributed with dual signatures) The depository allow four functions: Deposit, Withdrawal, Cancel, and Acknowledgement of Deposit. To use these function... DEPOSIT: Address a message to "Depository" at one of the listed depositories at the end of this document. The subject will be "Deposit" and the text body will contain your Public Key (in Ascii format) and some small body of text that will be reflected back to you. NOTE: The small body of text and your public key should be encoded WITH the Depository Key. WITHDRAWAL: Address a message to "Depository". The subject will be "Withdrawal" and the text body will contain what you are looking for on each line just as if you were polling your own PGP program. You will be sent back a list of keys with the depository signature verifying the message. Note that a * for the body text will give a LONG list back to you... For fidonet, this MIGHT require a poll to recieve your return list. See Appendix A CANCEL: Address a message to "Depository". The subject will be "Cancel" and the text body will contain the text "CANCEL PUBLIC KEY" with your signature on the message. The cancel will not take place without your signature! You will receive a cleartext response to this. All this does is to remove your public key from the depository keyring. If this comes with a "kill" signature for the key, then it will be moved from the deposit keyring to the invalid/killed keyring. ACKNOWLEDGE: Address a message to "Depository". The subject will be "Acknowledge" and the text body will contain the text "ACKNOWLEDGE" with your signature on the message. Without the signature, your public key will continue the daily countdown to keyring removal. A cleartext message will be returned upon any receipt of this message. Anything that doesn't fit one of these will be rejected and a return message will be bounced back. ------------------------------------------------------------------------- *** WARNING *** This proposal ONLY provides a method of storing keys for public distribution and withdrawl. This in NOW WAY verifies or even attempts to verify the authenticity of the issuer of the key. *** WARNING *** ----------------------------[ CUT HERE ]--------------------------------- Depository #1 (1:125/180) [KeyID:77854F] "Depository #1 [Public Keys]" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAirV7H4AAAEEAMgk39sU7OvZGr/Ig/g0Kaw2cY3FpQOFvRXp9OXmlAch3FBA Ow2/oD8dbKdiQamuIMFw6qpg0Bw2k8mhKXCfFhLIZjH3FJeqKQrV7UvELBJdCT4q b7wRg8jeLos2rR9a4jt+s0srNS/LznfLvquESEhMuzcxSTC27OyxS4Fbd4VPAAUT tBtEZXBvc2l0b3J5ICMxIFtQdWJsaWMgS2V5c10= =rC+3 -----END PGP PUBLIC KEY BLOCK----- --- GEcho 1.00/beta * Origin: The Babble Underground (Home of the Jabber QWK Reader) (1:125/180) SEEN-BY: 125/111 125 180 185 374/14 ;; -------------------- End forwarded message -- Tom Jennings / World Power Systems email: tomj@fidosw.fidonet.org FidoNet: 1:125/111, BBS +1-415-863-2739 postal: Box 77731, San Francisco CA 94107 USA -- tom jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!tom.jennings INTERNET: tom.jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: G5100035@NICKEL.LAURENTIAN.CA Date: Tue, 20 Oct 92 10:12:23 PDT To: cypherpunks@toad.com Subject: Unsubscribe me from mailing list Message-ID: <01GQ68KC14008WWO6L@NICKEL.LAURENTIAN.CA> MIME-Version: 1.0 Content-Type: text/plain I can no longer handle the mail volume from your mailing list. Please unsubscribe me from the list. Thanks. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: No_Such_Address@atdt.org Date: Tue, 20 Oct 92 11:06:12 PDT To: cypherpunks@toad.com Subject: Mac Version PGP Message-ID: <9210201806.AA07990@atdt.org> MIME-Version: 1.0 Content-Type: text/plain No one has been able to get me the source-code to PGP, and when I ftp'd it from wherever, it came ZIP'd in a format that my unzipper doesn't recognize. (Maybe I've been ZIP superceded). Anyway, it hasn't been very convenient to get a hold of it for me. But, it should be fairly straight forward to throw it into THINK C. THINK C supports a console with command-line. You would not necessarily have to Mac-ify it (although it would certainly make it more aesthetically pleasing); so porting to the Mac is not a dead-end port. THINK C should be able to compile and execute PGP as-is. As soon as I can get the source, I'll put my words into action. (re: Macifying it: It's simple enough to slap together an interface on top of something like PGP; that's one, maybe two dialog boxes with a bunch of radio buttons and check boxes and a routine to parse it all and hand the info over in a way PGP expects. BFD. So, criticisms I've heard about it being a hassle and a pointless exercise to port PGP to the Mac are without merit, as far as I'm concerned.) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: shawnb Date: Tue, 20 Oct 92 15:15:53 PDT To: cypherpunks@toad.com Subject: Fakemail Message-ID: <9210202215.AA29362@toad.com> MIME-Version: 1.0 Content-Type: text/plain Cyperpunks.... Man you guys generate lots of stuff... Anyhow I noticed that some of you are using fakemail... Are you using a shell script for this? The only fakemail scripts I've seen have not really worked. Could someone forward a copy to me? Thanks. Shawn From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Tue, 20 Oct 92 15:27:38 PDT To: cypherpunks@toad.com Subject: TEMPEST, Eavesdropping, and PDAs Message-ID: <9210202226.AA28803@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Eric Hughes posted a nice summary of the TEMPEST situation (interception of RF for eavesdropping on computers). I'll just add a few comments. > About Tempest. > > The ability to monitor is real; it's more powerful than you would first > imagine. And the NSA has reportedly restricted several papers on this, though they can't do much about the stuff coming from abroad. Their chief concern doesn't seem to be folks like us, but rather concerns about vans parking outside high tech and defense contractors and slurping up what they can from non-TEMPEST (all caps, for some reason) terminals and computers. And someone asked about building Faraday cages. Don't even try! In 1972-3 I worked inside a Faraday cage in the lab of Dr. Paul Hansma (who's now famous for his atomic force microscope work--small world), and it was real tough to shield against high frequencies (above 500 MHz). Modern computers run at 50MHz and faster and the signal edges are of course much faster. RF emissions are a major hassle, and even 30 dB of shielding will still mean enough emissions for a dedicated listener to pick up. > Hal mentions using flat panel displays to combat emissions. This > works, as evidenced by the continued existence of Grid Computer. > Remember Grid, who came out with these way-expensive gas plasma > laptops around 1985/6? The reason they sold so many of those and are > still around was that a large number of them were Tempest certified. > (Even larger revenues!) I understand that the Tempest spec Grids had > a thin layer of gold foil in front of the screen, even so. Yes, gold > thin enough to see through. BTW, I have one of the original magnesium-cased, bubble-memoried GRiD Compasses. Tres elegant (and even "way cool"....Not! It heats up something fierce, with the magnesium case acting as a heat sink). (I got this at Weird Stuff Warehouse, complete with a magnesium-cased disk drive, cables, etc., for $250. Fully functional, but not a lot of software written for "GRiD-OS." Maybe I'll bring it to the next Cypherpunks meeting.) > monitoring easier. It's safe to presume that there is some amazing > stuff going on. Read The Puzzle Palace for more hints. (Like the > valley in WV which is one big antenna.) Ditto on this book recommendation: all would-be cypherpunks should read James Bamford's "The Puzzle Palace." Though published in 1982, it revealed a lot about such "No Such Agency," so much so that the director of NSA, upon encountering Bamford at a dinner, refused to shake his hand and said "Sir, I consider you an unindicted felon!" > Emissions monitoring is also all economics. The price to monitor > increases with each more sophisticated attack. CRT's are easy, CPU's > are hard. I would like to see public research in this area, just like > there is public research in cryptography. Until the public has a > better idea of what various attacks cost, there can't be rational > decisions about emissions security. I think the longterm solution to this problem is the same as that for the key problem: small, highly portable, self-contained computers for doing the most sensitive work and for providing passwords to remote systems. Smartcards are one approach, though they obviously are highly constrained in what they can do other than act as ATM or VISA cards. (Laptops are one idea. Following Eric's suggestion that we look into TEMPEST issues, perhaps we could "rate" different laptops and PCs for emissions. Just a thought.) Apple's "Newton" PDA ("Personal Digital Assistant"), General Magic's whatever (talk to Fen L., who works there, but who won't say much), Eo's Hobbit-based PDA, and other systems (Sharp, Casio, etc.), offer a better platform, at least for the long term. With 100 MIPS performance, LCD screens, and no dangling keyboards and cables, these gizmos should be favorably positioned for security-conscious applications. RF emissions should be low to begin with (and can be characterized, of course); additional shielding should be easier to achieve than with full-sized units. PDAs also are small enough that people will carry them everywhere, thus both enhancing security against tampering, and also making them workhorses for security applications. With a good interface to desktop machines, the critical security functions can be done inside the PDA (e.g., accessing a terminal or remote system using zero knowledge protocols, where the PDA answers a challenge question without revealing the actual password or whatever secret key). The announced PDAs also have slots for "PCMCIA" cards, small credit-card-sized cards that can add functionality and memory. The lack of a keyboard in the smallest of these units will be a limit (though external keyboards are options...and with some care, these keyboards can even be made TEMPEST class, though leakage will still persist. A battery-operated keyboard with fiber-optic link to the PDA might be one approach.). The issue of hooking these PDAs to desktop machines and networks is an interestesting one. Wirless links would seem to be risky, except that if all critical computations are done _inside_ the PDA then what gets transmitted is not really "fragile" (in the eavesdropping sense). I suspect that someone will offer a small fiber optic link (like the one I have going between my CD player and my DAT machine). And it will be a couple of years before these become common. But it's about 2-3 years from now that our mission gets really interesting, anyway. Digital money, anonymous voting and conferences (imagine using wireless, encrypted links in meetings to negotiate without opponents knowing..just one of several small business product niches), and all kind of other crypto anarchy ideas. PGP 3.0 for PDAs! -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP 2.0 and MailSafe keys by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hollander Date: Tue, 20 Oct 92 16:53:46 PDT To: cypherpunks@toad.com Subject: another service Message-ID: <9210202353.AA04723@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain I have thought of another service, like the depository, which might be useful to the user community: a time stamping notary service. This would have less security problems than the depository and would also be neccessary if RSA'ed documents are to replace contracts and other paper documents used in business. It would be easy to implement. A machine is set up with a hardware random number generator. This is used to generate a time-stamp key pair, perhaps every day or every hour. A user sends a document to this computer, which then signs it with the private half of the time-stamp key and then remails it to the user. Note that the document sent by the user is probably already encrypted and/or signed; sending it to the time-stamper does not compromise it in any way. The time stamper also keeps publishing the public half of its keys, to a wide enough audience that it would be impossible for any one person (or Agency) to modify all of them. Users could keep their own archives of them. After the time period has elapsed, the time-stamper should erase the private key corresponding to the time period. This is the only time that trust is involved and that the system might be compromised. If a private key were leaked, a time-stamp could be forged. This would allow users to keep dated, notarized documents in their files, so they could later prove that they had certain information at a certain time. Ideas? Thoughts? e From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: "Fen Labalme" Date: Tue, 20 Oct 92 17:45:27 PDT To: uunet!atdt.org!No_Such_Address@uunet.UU.NET Subject: Re: Mac Version PGP Message-ID: <9210210045.AA28410@relay1.UU.NET> MIME-Version: 1.0 Content-Type: text/plain Subject: RE>Mac Version PGP > No one has been able to get me the source-code to PGP, and when > I ftp'd it from wherever, it came ZIP'd in a format that my > unzipper doesn't recognize. There are several mac un-zip programs available for anonymous ftp from sumex.stanford.edu (cd info-mac/util; mget unzip-11.hqx mac-zip-10.hqx). > But, it should be fairly straight forward to throw it into > THINK C. A person here has put a short amount of effort into "macifying" PGP. He's gotten it to compile in Think and MPW, but it won't run yet. According to him, the technical reason is that some sort of "goofy bus-error bullshit" is occuring, and so, if you figure it out, please let this list know (as well as possible posting it to alt.crypt.sources, if such exists). We will do the same. Good luck! Fen From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Tue, 20 Oct 92 17:15:26 PDT To: cypherpunks@toad.com Subject: Re: another service In-Reply-To: <9210202353.AA04723@soda.berkeley.edu> Message-ID: <9210210014.AA05539@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Eric Hollander writes: > I have thought of another service, like the depository, which might be > useful to the user community: a time stamping notary service. This would > have less security problems than the depository and would also be neccessary > if RSA'ed documents are to replace contracts and other paper documents used > in business. Bellcore is offering some form of this service, or plans to. Stuart Haber, one of the codevelopers, described this at last year's Hackers Conference and presented a paper at the Crypto '90 conference, or possibly the Crypto '91. (I have a Xerox of the paper someplace and may be able to dig it up if you're interested) -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP 2.0 and MailSafe keys by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: mark@coombs.anu.edu.au (Mark) Date: Tue, 20 Oct 92 02:19:05 PDT To: cypherpunks@toad.com Subject: Home security... In-Reply-To: <199210200855.AA27037@well.sf.ca.us> Message-ID: <9210200918.AA18129@coombs.anu.edu.au> MIME-Version: 1.0 Content-Type: text/plain >This general area is part of a larger topic called TEMPEST. Anyone else >interested in pursuing this angle...? What's the best sources for faraday cages and TEMPEST etc? And does anyone out there implement anything of this type of security at home to protect against monitoring? The cost of such an exercise would be rather prohibitive to say the least. Just curious.. Mark From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Wed, 21 Oct 92 01:16:08 PDT To: mark@coombs.anu.edu.au Subject: Re: Home security... Message-ID: <199210210815.AA06441@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Tempest: there are companies which make cages for Macs and PCs, I don't have addresses but they can probably be found with some searching of ads. The main application it would seem, is not the individual home user (unless s/he's a notorious digital dissident) but rather the encrypted BBS, particularly one which decrypts and re-encrypts or retransmits messages. Consider the labor cost of monitoring a computer, and you can see it would be reserved for the ones that are "significant." Keeping your computer off the phones and AC while doing crypto processing, can be fairly easy. Unplug the darn modem from the phone socket. (Gee that was simple, wasn't it?) Use a laptop and run it entirely on the batteries while doing crypto processing. You can go buy an old laptop pretty cheaply these days... Or get an uninterruptable power supply for your main computer; cost will vary from $600 to $1500 depending on how much time you need to be running on the large batteries which are converted into AC to run the computer. -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Wed, 21 Oct 92 09:43:25 PDT To: cypherpunks@toad.com Subject: Keystone In-Reply-To: <9210201753.AA009kv@fnordbox.UUCP> Message-ID: <9210211643.AA11195@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Eric: >:I would be hesitant to implement a system that _only_ required a user >:to generate a key pair. Loyd: >I take the opposite view -- I dare *not* supply such a system. [...] >But many users do not have the interest/time/ability to set up PGP on their >home system. For them, I want to provide the best possible privacy given the >ease with which anyone who can find their local LMOS can tap (voice or data) >a line... Where is the key pair generated? It must be on the BBS since your user may not have PGP running. The private key isn't private! The work to do public key encryption in the first place is hardly valuable if the owner of the private key doesn't hold it. If you just want inter-BBS privacy, why not set up each BBS with a PGP key pair, and use that for transfering messages? There's not much difference in security. A monitoring sysop would be able to read all the traffic originating on that board in either system. The difference is that such a monitoring sysop would not be able to read replies. Why? Because the private keys are kept on the originating board. But it sounds as though you're trying to prevent against external monitoring and that you trust your sysops. In this case there is no advantage to issuing keys to individuals; it's just not worth the effort. Loyd: >I don't have my user's terminal program -- I *do* have the bbs software. This is the unfortunate fact of the situation, I acknowledge. But do you know what terminal programs are in the most common use? I suspect most of this stuff could be done with script programming in the various terminal packages. Do you know, in aggregate, how many users of each terminal program you have? You can poll your users to find out. You'll need this data to allocate your effort. And you've got lots of people willing to help, even if they can't because they are working on other projects. Everyone on this list, for example. Let me repeat, for those of you who did not previously know you were willing to help. Everyone on this list should be willing to help Loyd write scripts for his users to use PGP. Cypherpunks write code. This will mean someone who knows Procomm, Crosstalk, Qmodem, Telix, etc. for the PC, someone who knows the various Mac, Amiga, Atari, and other machines. This will mean someone to write nice pretty visual interfaces for PGP to put all the PGP options on menus where they are all visible. This will mean people to think about BBS/terminal protocols. This will mean lots of individual contributions, no single of which need be large, but whose sum will be. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Wed, 21 Oct 92 10:11:42 PDT To: cypherpunks@toad.com Subject: TEMPEST, Eavesdropping In-Reply-To: <9210202224.AA28714@netcom2.netcom.com> Message-ID: <9210211711.AA11833@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain >Their chief concern doesn't seem to be folks like us, but rather >concerns about vans parking outside high tech and defense contractors >and slurping up what they can [...] When banks start signing with private keys, then we get an even more interesting monitoring problem. >And someone asked about building Faraday cages. Don't even try! Sometimes it is cheaper to build a whole building to be tempest-spec than to buy all tempest-spec electronics. What I have heard about such stuff is solid copper walls and no windows. No exacly your classical Faraday cage; more like your classical Gaussian surface. :-> TEMPEST is an acronym. I don't remember for what. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Wed, 21 Oct 92 10:13:36 PDT To: cypherpunks@toad.com Subject: another service In-Reply-To: <9210202353.AA04723@soda.berkeley.edu> Message-ID: <9210211713.AA11854@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Re: digital timestamping. Eric Hollander says: >Ideas? Thoughts? Yes. Send code. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Wed, 21 Oct 92 08:23:37 PDT To: tcmay@netcom.com Subject: another service In-Reply-To: <9210210014.AA05539@netcom2.netcom.com> Message-ID: <9210211427.AA03115@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: tcmay@netcom.com (Timothy C. May) >Eric Hollander writes: >> I have thought of another service, like the depository, which might be >> useful to the user community: a time stamping notary service. This would >> have less security problems than the depository and would also be neccessary >> if RSA'ed documents are to replace contracts and other paper documents used >> in business. >Bellcore is offering some form of this service, or plans to. Stuart >Haber, one of the codevelopers, described this at last year's Hackers >Conference and presented a paper at the Crypto '90 conference, or >possibly the Crypto '91. (I have a Xerox of the paper someplace and >may be able to dig it up if you're interested) Haber isn't offering quite the service described -- he worked out a much nicer notarization and time stamping protocol thats really neat. Every day or two a critical number spat out from the service gets published in the classifieds of the New York Times so people can independantly verify that there is no cheating. By the way, technically, the service doesn't do timestamping, just a verified ordering of notarized documents. Unfortunately, there is no mathematically provable way to know what time it is -- you must trust someone on that. Stu's a really nice guy -- maybe someone should encourage him to join this list. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Karl L. Barrus Date: Wed, 21 Oct 92 13:26:56 PDT To: cypherpunks@toad.com Subject: the acronym TEMPEST Message-ID: <9210212026.AA00628@tree.egr.uh.edu> MIME-Version: 1.0 Content-Type: text/plain > TEMPEST is an acronym. I don't remember for what. > Eric TEMPEST = Transient ElectronMagnetic Pulse Emission STandard. Pretty cool sounding acronym :-) /-----------------------------------\ | Karl L. Barrus | | barrus@tree.egr.uh.edu (NeXTMail) | | elee9sf@menudo.uh.edu | \-----------------------------------/ From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Wed, 21 Oct 92 14:07:37 PDT To: cypherpunks@toad.com Subject: TEMPEST, Eavesdropping In-Reply-To: <9210211711.AA11833@soda.berkeley.edu> Message-ID: <9210211934.AA09886@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: Eric Hughes >>Their chief concern doesn't seem to be folks like us, but rather >>concerns about vans parking outside high tech and defense contractors >>and slurping up what they can [...] >When banks start signing with private keys, then we get an even more >interesting monitoring problem. Consider that the international clearing and settlement systems for interbank transactions process several TRILLION a day in electronic transactions, and then consider what diverting just a tiny little bit of that to yourself would be worth. Security in banks is ALREADY crucial. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Karl L. Barrus Date: Wed, 21 Oct 92 13:44:45 PDT To: cypherpunks@toad.com Subject: fast elliptical encryption Message-ID: <9210212044.AA00695@tree.egr.uh.edu> MIME-Version: 1.0 Content-Type: text/plain In the winter NeXTWorld magazine, the article ("Tales from the Crypt") on page 94 mentions various topics of interest: public key encryption, export restrictions, the role of the NSA, etc. (It's just a one page article and doesn't go into much depth). Anyway, NeXTStep 3.0 is bundled with fast elliptical encryption for NeXTMail. As a result, 3.0 is export restricted. Does anybody know about the "fast elliptical encryption" public-key system? How different is it from good ol' RSA? Is it related to the elliptic-curve factoring algorithm (am I remembering this correctly - I don't know how elliptic curve factoring works, but I remember seeing a reference to it somewhere)? Just curious... /-----------------------------------\ | Karl L. Barrus | | barrus@tree.egr.uh.edu (NeXTMail) | | elee9sf@menudo.uh.edu | \-----------------------------------/ From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: "Campbell James A" Date: Wed, 21 Oct 92 14:29:41 PDT To: "cypherpunks" Subject: Put me on your mailing list! Message-ID: <9210212129.AA27437@toad.com> MIME-Version: 1.0 Content-Type: text/plain Hey, I'd like to be on the mailing list for CYPHERPUNKS. My address is: ujacampbe@memstvx1.memst.edu If you need this too, here's my PGP 2.0 public key: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAirkL4AAAAEEANAomYnlPXopnms9RtU0ln9CiLJljssOeflC9A+QIDujXhPT yApbL6VPqSUSoFF/e72xTJixyrwBQhw5lAvfvQPEiGIFQQYxviF+Qg/+6/JVvLCj vnGVFl9kKTEYVeONxBNGiaXuSE0VMQLx47iP9AU+wYw62aXmTNtW1BUtX5BHAAUR tDBKYW1lcyBBLiBDYW1wYmVsbCA8dWphY2FtcGJlQG1lbXN0dngxLm1lbXN0LmVk dT4= =0rCj -----END PGP PUBLIC KEY BLOCK----- Thanks! James A. Campbell Memphis State University Memphis, Tennessee From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Wed, 21 Oct 92 22:35:21 PDT To: cypherpunks@toad.com Subject: Keystone In-Reply-To: <9210220333.AA009m7@fnordbox.UUCP> Message-ID: <9210220541.AA13526@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Ah. A small PGP subset. You hadn't mentioned this. When you said you weren't requiring the user to run PGP, I assumed key generation must occur on the board. As for your fatal flaw I hadn't spotted, I had spotted it, and the location of the private key was the critical point. If the key is on the BBS, the message goes out in the clear. Look, it boils down to this. If the message traffic to the BBS is to be encrypted, then the user has to generate a key on his own machine and decrypt it on his own machine. There's no way around that. But the user interface problem can be solved. Just make a bunch of .com files which do nothing but spawn pgp by invoking the correct arguments. Very simple; a few lines of C is all. Even the PGPPATH can be set before the spawn. It's an easy encapsulation. It will run a bit slower for load time, but not appreciably. And you won't have to recompile PGP from the distributed executables. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: gnu@cygnus.com Date: Wed, 21 Oct 92 23:35:44 PDT To: Eric Hughes Subject: Re: Keystone In-Reply-To: <9210220541.AA13526@soda.berkeley.edu> Message-ID: <9210220637.AA20200@cygnus.com> MIME-Version: 1.0 Content-Type: text/plain We have a small project cooking, to use Diffie-Hellman key exchange to choose a random key to encrypt Internet connections (telnet, rlogin, ftp, smtp). This same protocol can also be used over an ordinary modem connection between a user's PC and a BBS, preventing eavesdropping or wiretapping of that phone call. It would also be able to protect phone calls between a PC and a Unix timesharing system, regardless of what networks lie in between, if we wrote a simple login program that handled the modem protocol. (It doesn't protect against active re-routing of the call, e.g. by substituting another machine for the BBS, but we could work on that as Phase II.) (I suggest that the initial Diffie-Hellman handshake all be done in ASCII encoding, no matter what the medium, so that the same protocol can be used on all media, binary-transparent or not.) This scheme would require support in the BBS and in the user's PC terminal program. Given a working Unix implementation, it would be relatively easy to add to the terminal program, if source code for any decent terminal programs was available. This is where Unix shows a real advantage, since you can get free source for just about program, while "free" PC programs means free binaries. If anyone knows of a reasonably popular PC terminal emulator for which source code is freely available and distributable, let us know. (Or, if anyone knows the author of a popular commercial PC terminal emulator program, tell the author that they could consider licensing Diffie-Hellman from RSA for commercial use and adding it to their proprietary terminal program. They're unlikely to do so, since it costs money, unless some very popular BBS's can also be upgraded to do it -- standard commercial chicken/egg problem which free source code solves.) On the BBS side, I've heard the idea of freeing the Fido source code as copylefted code. That would make it easy to add things like login session encryption for the modem users. John Gilmore From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: whitaker@eternity.demon.co.uk (Russell E. Whitaker) Date: Thu, 22 Oct 92 00:00:52 PDT To: cypherpunks@toad.com Subject: "Cypherpunks write code" Message-ID: <2580@eternity.demon.co.uk> MIME-Version: 1.0 Content-Type: text/plain Eric Hughes writes: > > Cypherpunks write code. > > This will mean someone who knows Procomm, Crosstalk, Qmodem, Telix, > etc. for the PC, someone who knows the various Mac, Amiga, Atari, and > other machines. This will mean someone to write nice pretty visual > interfaces for PGP to put all the PGP options on menus where they are > all visible. This will mean people to think about BBS/terminal > protocols. This will mean lots of individual contributions, no single > of which need be large, but whose sum will be. > > Eric > Count me in on the Procomm scripting. I *may* do something for Telix, too. Who knows? I may sell the scripts/interfaces on AMiX. ;-) Russell Earl Whitaker whitaker@eternity.demon.co.uk Communications Editor 71750.2413@compuserve.com EXTROPY: The Journal of Transhumanist Thought AMiX: RWHITAKER Board member, Extropy Institute (ExI) ================ PGP 2.0 public key available ======================= From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Thu, 22 Oct 92 08:51:19 PDT To: cypherpunks@toad.com Subject: Keystone Message-ID: <9210221550.AA23915@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Re: adding D-H key exchange to PC software gnu@cygnus.com writes: >Given a working Unix implementation, it would be relatively easy to >add to the terminal program, if source code for any decent terminal >programs was available. But source code is not available. The trouble is that all the decent terminal programs for PC's are shareware or commercial (or were originally shareware and have become commercial). I too would like to know of any source-available PC terminal programs, but I suspect there are none because of the prevailing shareware culture. Re: getting an author to license D-H key exchange The reason this will not happen is not the bootstrapping problem (chicken/egg), but that there is no perceived value to an encrypted link. The sysop is already has access to everything on the dedicated machine and may even have a policy of scanning all messages. External hackers can't really get in because shell access isn't really done remotely. The only ones you are protecting against are people with a hard tap on the phone line itself. For most people, this is not a concern. Since there's no perceived value and since all the software would require license from RSADSI, it won't happen that way. Re: using a protocol layer avalon@coombs.anu.edu.au writes: >Rather than rewrite the terminal progs, why not rewrite the BIOS level >drivers and such ? (if its possible). That's not possible either. Most terminal programs write directly to the hardware. This is single-tasking, standardized hardware, remember, and the original BIOS interface for the serial port was totally unusable. Some communications programs use FOSSIL drivers, but many (if not most) terminal programs don't support it. (FOSSIL is a BIOS-level serial port interface description which could hooked into or rewritten to support a protocol.) Look, I wish all this stuff were in use. Everyone should encrypt all their communications links as a matter of policy. (That includes voice, and if you thought the PC terminal program bootstrapping was difficult ...) Let's move incrementally, though. If we can get people to at least encrypt all of their e-mail, that will be an excellent start. One incentive would be for the BBS operators to phase in a policy that they will accept no e-mail which is _not_ encrypted. Comments? Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Thu, 22 Oct 92 10:52:24 PDT To: cypherpunks@toad.com Subject: re: Keystone Message-ID: <3225.2AE6E91B@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain re: PGP interface to email. I've completed my "RM" program. The PGP interface is single-keystroke, and includes optional pass-phrase management. I've released it with source under the copyleft agreement. It can be downloaded or filerequested from me if anyone's interested. (MSDOS and .MSG format only) --- ReadMail * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: fnordbox!loydb@cs.utexas.edu (Loyd Blankenship) Date: Thu, 22 Oct 92 08:33:10 PDT To: soda.berkeley.edu!hughes@cs.utexas.edu Subject: Re: Keystone Message-ID: <9210221550.AA009mh@fnordbox.UUCP> MIME-Version: 1.0 Content-Type: text/plain :But the user interface problem can be solved. Just make a bunch of :.com files which do nothing but spawn pgp by invoking the correct :arguments. Very simple; a few lines of C is all. Even the PGPPATH :can be set before the spawn. It's an easy encapsulation. It will run :a bit slower for load time, but not appreciably. And you won't have :to recompile PGP from the distributed executables. That's a real good idea. I shoulda thunk of it myself. :-) Loyd *************************************************************************** * loydb@fnordbox.UUCP Once you pull the pin, * Loyd Blankenship * * GEnie: SJGAMES Mr. Grenade is no longer * PO Box 18957 * * Compu$erve: [73407,515] your friend! * Austin, TX 78760 * * cs.utexas.edu!dogface!fnordbox!loydb * 512/447-7866 * *************************************************************************** From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Thu, 22 Oct 92 11:19:49 PDT To: cypherpunks@toad.com Subject: re: Keystone Message-ID: <3230.2AE6EFBC@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain Hughes: U> But source code is not available. The trouble is that all U> the decent terminal programs for PC's are shareware or U> commercial (or were originally shareware and have become U> commercial). I too would like to know of any U> source-available PC terminal programs, but I suspect there U> are none because of the prevailing shareware culture. U> I'll give you all of my Fido/FidoNet and FidoTerm sources. You can already have ReadMail. U> communications programs use FOSSIL drivers, but many (if U> not most) terminal programs don't support it. Commercial people still sneer at amateur systems like FidoNet. Their loss. FOSSIL is widely supported otherwise. FidoTerm and Fido/FidoNet both support FOSSIL, as do "all" FidoNet programs. U> One incentive would be for the BBS operators to phase in a U> policy that they will accept no e-mail which is _not_ U> encrypted. Comments? SHEESH!@+#)(#$ You oughta see what most sysops think. It's embarrassing. In their defense, NO ONE WILL TELL US what is reasonable. I know, I know how much is presently undefined and without precedent, but the broadest general parameters and guidelines are not that obscure. I'm also part of the BBSLAW mailing list (out of EFF) and it's finally contained some applicable stuff. What you wanna bet the lawscum won't let me repeat in any manner the recent thread on email? (Yes I'm asking.) (Most sysops are terrified that an in-transit, third-party message will contain some illegality and they will all be BUSTED. Hence, it is routine for them to review personally every in-transit message, and kill or bounce them! I am not kidding. (I know this must have been dealt with in the Internet (is kumr/cygnus/etc liable when I tell you that RICHARD NIXONS VISA CARD NUMBER is 4131 34534 456456 456546?) but somehow, no one's ever passed this info on to us.) --- ReadMail * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG rom fidogate!f111.n125.z1.FIDONET.ORG!tom.jennings@kumr.lns.com Thu Oct 22 11:19:49 1992 Return-Path: Received: from kumr.lns.com by toad.com id AA22497; Thu, 22 Oct 92 11:19:49 PDT Received: by kumr.lns.com (/\==/\ Smail3.1.25.1 #25.3) id ; Thu, 22 Oct 92 11:19 PDT Received: by fidogate.FIDONET.ORG (mailout1.26); Thu, 22 Oct 92 11:15:22 PDT Date: Thu, 22 Oct 92 11:03:26 PDT Message-Id: <3229.2AE6EFB9@fidogate.FIDONET.ORG> From: tom.jennings@f111.n125.z1.FIDONET.ORG (tom jennings) Subject: thread (was Re: A To: cypherpunks@toad.com X-Mailer: mailout v1.26 released Just a slightly amusing message forwarded from PUBLIC_KEYS... From: Wes Cowley@1:125/180 To: Wes Perkhiser@1:125/111 Subject: Loss of thread (was Re: A ;Status: (read 2 times) ;^AINTL 1:125/111 1:125/180 ;^APID ReadMail ;^AMSGID RM1:125/111=2AE68513 >----------------------- Do not change this line -----------------------------< WP>>"Hi, how are you, and what's your key?" WP>>P.S. Will that be a new pick-up line? It beats "What's your sign?" "Do you want to swap keys, or just come up to my pad, one time?" * OLX 2.1 TD * The computing field is always in need of new cliches. --- DCI/Chauncy 0.7 * Origin: Bird Lake - (813)265-3256 (1:377/14.0) SEEN-BY: 100/520 102/890 105/36 125/111 125 180 185 135/71 340 163/438 170/109 SEEN-BY: 216/21 234/1 253/513 261/1136 285/27 312/2 374/14 26 48 98 377/3 14 15 SEEN-BY: 377/33 37 396/1 2200/101 ;; -- tom jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!tom.jennings INTERNET: tom.jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: sdw@meaddata.com (Stephen Williams) Date: Thu, 22 Oct 92 10:09:30 PDT To: gnu@cygnus.com Subject: Re: Keystone In-Reply-To: <9210220637.AA20200@cygnus.com> Message-ID: <9210221600.AA21898@bugatti.meaddata.com> MIME-Version: 1.0 Content-Type: text/plain .. > real advantage, since you can get free source for just about program, > while "free" PC programs means free binaries. If anyone knows of a > reasonably popular PC terminal emulator for which source code is > freely available and distributable, let us know. PC Kermit, of course. The best vt100 emulator around, last I used them heavily. > sdw -- Stephen D. Williams Local Internet Gateway Co.; SDW Systems 513 496-5223APager LIG dev./sales Internet: sdw@world.std.com CIS 76244.210@compuserve.com OO R&D Source Dist. By Horse: 10028 Village Tree Ct., Miamisburg, OH 45342 GNU Support ICBM: 39 34N 85 15W I love it when a plan comes together From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: omega@spica.bu.edu (The Omega) Date: Thu, 22 Oct 92 09:25:56 PDT To: cypherpunks@toad.com Subject: BBS E-mail policy Message-ID: <9210221623.AA00440@spica.bu.edu> MIME-Version: 1.0 Content-Type: text/plain >> One incentive would be for the BBS operators to phase in a policy that they will accept no e-mail which is _not_ encrypted. Comments? << And how does your BBS software tell whether or not you've just sent encrypted mail, plaintext mail or line-noise? (in an encryption/decryption-at-user's-end scenario) -- Omega@spica.bu.edu From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: "Scott Collins" Date: Fri, 23 Oct 92 00:06:14 PDT To: "Cypher Punks" Subject: Diffie-Hellman Message-ID: <9210230706.AA04122@relay2.UU.NET> MIME-Version: 1.0 Content-Type: text/plain Subject: Diffie-Hellman >Since there's no perceived value and since all the software would >require license from RSADSI, it won't happen that way. It was not my understanding that RSA held any patents, copyrights or other controls over Diffie-Hellman key exchange. The 'big-number' math required is not difficult and is fully documented in Knuth's "The Art of Computer Programming", vol2: Seminumerical Algorithms; section 4.3: Multiple Precision Arithmetic. Also note that this multiple precision code is available in the PGP source in the file mpilib.c. The exchanged key could easily be a DES (or other fast symmetric cypher) key -- and usually is. Unless you want to perform an authenticated key exchange with Diffie-Hellman as described in "Authentication and Authenticated Key Exchanges" [Diffie, Van Oorschot and Wiener in "Designs, Codes and Cryptography", 2, 107-125 (1992)] using certificates signed with the RSA algorithm, then RSA doesn't have to enter the picture at all. Is my understanding of RSAs controls incorrect? From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Thu, 22 Oct 92 13:35:59 PDT To: gnu@cygnus.com Subject: Keystone In-Reply-To: <9210220637.AA20200@cygnus.com> Message-ID: <9210221929.AA16268@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: gnu@cygnus.com >We have a small project cooking, to use Diffie-Hellman key exchange >to choose a random key to encrypt Internet connections (telnet, >rlogin, ftp, smtp). This same protocol can also be used over an >ordinary modem connection between a user's PC and a BBS, preventing >eavesdropping or wiretapping of that phone call. It would also be >able to protect phone calls between a PC and a Unix timesharing system, >regardless of what networks lie in between, if we wrote a simple login >program that handled the modem protocol. (It doesn't protect against >active re-routing of the call, e.g. by substituting another machine >for the BBS, but we could work on that as Phase II.) I would suggest that it be done during phase one. Spoofing attacks are very important things to guard against, and thanks to PGP there is a handy dandy set of code out there to steal from to provide for public key based authentication of the link. Indeed, I would go further and suggest that the protocol be designed so that it does not reveal the entities forming the link to outsiders (unless one end should intentionally advertise who it is, the assumption should be that both ends know who the other end is a priori). There is also a very good implementation of the IDEA cypher in PGP, which should run well as the conventional cypher for the link (although I would suggest having the protocol negotiate the cypher just in case IDEA gets replaced later on). I am very interested in seeing such a protocol standardized because I have another use for it -- secure telephones. Given modern DSPs to do and cheap V.32bis modems, excellent secure voice communications are feasable. The presense of code in the public domain to handle secure encrypted links could be easily dropped right in to this application. >(I suggest that the initial Diffie-Hellman handshake all be done in >ASCII encoding, no matter what the medium, so that the same protocol >can be used on all media, binary-transparent or not.) I agree that this should be a negotiated option in the protocol (prehaps with some sort of test done at the beginning of the link for line transparency), but I'm not sure it should be mandatory as that eighth bit get significant at times. >If anyone knows of a reasonably popular PC terminal emulator for >which source code is freely available and distributable, let us know. Kermit is the obvious choice. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: jjaloszyns@bluejay.mich.fred.org Date: Fri, 23 Oct 92 10:04:47 PDT To: cypherpunks@toad.com Subject: TEMPEST Message-ID: <9210231704.AA25073@home.merit.edu> MIME-Version: 1.0 Content-Type: text/plain There has been quite a bit of concern about certain people (agencies) using a TEMPEST machine and invading privacy. Most of the things to defeat this that have been taked about have revolved around shielding. What would be the problem with having another device to emit random signals on the same frequency that your monitor operates on? Has this already been implimented? Legal? jon ------------- 43.31.28N, 84.41.41W Jon Jaloszynski Student 9-12 at Shepherd HS, Shepherd Shepherd, MI From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: bill@anubis.network.com (Bill O'Hanlon) Date: Thu, 22 Oct 92 14:13:15 PDT To: cypherpunks@toad.com Subject: Re: Keystone In-Reply-To: <9210221929.AA16268@newsu.shearson.com> Message-ID: <9210222112.AA06121@anubis.network.com> MIME-Version: 1.0 Content-Type: text/plain > >I am very interested in seeing such a protocol standardized because I >have another use for it -- secure telephones. Given modern DSPs to do >and cheap V.32bis modems, excellent secure voice communications are >feasable. The presense of code in the public domain to handle secure >encrypted links could be easily dropped right in to this application. > I've had much the same idea. There are a lot of people out there with PCs equipped with Soundblasters and V.32 modems. I can't think of a better way to fight back against that ridiculous FBI Telephone legislation. -- Bill O'Hanlon Network Systems Corporation bill@network.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: DELTORTO@AppleLink.Apple.COM (Imaja, David Del Torto,PAS) Date: Thu, 22 Oct 92 16:28:44 PDT To: CYPHERPUNKS@TOAD.COM Subject: temporary request Message-ID: <719795393.8323950@AppleLink.Apple.COM> MIME-Version: 1.0 Content-Type: text/plain Greetings CypherFolk, I, one of your newest members, am on vacation in Europe (right now I'm in Holland enjoying the "coffee" shops) and am temporarily restricted to using AppleLink as my gateway to Internet. Because it costs $0.50 to $0.80 per piece of email, I asked Eric to _temporarily_ remove me from the general alias until I return to the US in December, saving me major bucks. When I get back, I'll announce that you can send me mail at "ddt@well.sf.ca.us". I enjoyed the repartee I sampled and look forward to joining in as I learn more. Offer of the Week: If anyone needs me to physically pick up a PGP key from someone here in Europe, I have a train pass good for another month (maybe longer if I can alter it again) and will consider any request that will take me to interesting locations and connect me with interesting folks. Further Request: If any of you send any interesting stuff to the group alias (e.g. Russ Whitaker's article on "computer cryptography" from the Economist) and think it might be of general interest to someone learning about the whole encryption process (i.e. me), please cc me at "deltorto@applelink.apple.com" anytime. This would be appreciated. I also encourage anyone who has helpful learning material to forward it to me so I can get up to speed. I am working on an interesting project I would like to share with the right people, but I am not prepared to discuss it in public. Does anyone have a copy of PGP 2.0 that runs on a Macintosh? If you email it to me, I will cover any costs you incur. Coolness. Until we all meet in person, dave From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Thu, 22 Oct 92 23:02:09 PDT To: cypherpunks@toad.com Subject: BBS E-mail policy In-Reply-To: <9210221623.AA00440@spica.bu.edu> Message-ID: <9210230601.AA26160@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Re: distinguishing between encrypted mail, plaintext mail, and line-noise. I'm really glad this question came up. I passed over it before because I was more interested in the social issue, but the technical one is important. The basic technique is the foundation of cryptography: information theory. For this application, you can just measure the entropy; it alone should be able to distinguish between the three sources. The entropy measures how well one can statistically predict the output of a source. A random source has eight bits of entropy per byte. As randomness decreases, so does the entropy measure. (Mail me if you want references in order to learn this stuff yourself.) Now line noise, let's say, will appear random. So its entropy should be right near the maximum, 8 bits. Text encrypted with PGP using the ASCII armor uses only 64 characters out of 256 possible, or one fourth of the total available. Its entropy would be 2 bits per character. English text is usually around four and five bits per character, if I remember right. To calculate the entropy, you first make a table (of size 256) of character frequencies normalized to the range [0,1]. Call these p_i. The entropy is then (TeX here) $ \Sum_{i=0}^{256}n - p_i \log_2 p_i $. (The log base 2 give bits instead of natural units). Now see if this number is in one of the following ranges: [1.5 .. 2.5] encrypted text [3 .. 6] regular text [7 .. 8] line noise This is a very simple measure. There are other measures to look for the deviation from an expected distribution, which give much more accurate distinctions. One can very easily separate languages from each other just by looking at such measures. Note that none of these techniques ever look at the content. Nor do they look at digraph (two-letter combinations) or trigraph statistics. In fact, the content is completely destroyed by the scanning process! Lots of this stuff is known; this is how the big boys crack codes. I'm glad there arose a natural context to explain some of this stuff. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nobody@soda.berkeley.edu Date: Thu, 22 Oct 92 23:10:13 PDT To: cypherpunks@toad.com Subject: Eavesdropping on a printer's signature Message-ID: <9210230609.AA26646@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain While doing a summer (1980?) co-op with Raytheon Submarine Signal division in Newport RI, a milk-truck-sized van pulled up out front and opened a sliding side door. Inside was a line printer that was busy printing out the same text that an internal (in the middle of the building, perhaps 150 feet away) line-printer was printing. There were mistakes, but it was readable. My guess is that with all the electromechanical pulses the printer was emanating this was pretty easy. Probably harder to do with a laser printer... From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Thu, 22 Oct 92 23:22:28 PDT To: cypherpunks@toad.com Subject: Keystone In-Reply-To: <3230.2AE6EFBC@fidogate.FIDONET.ORG> Message-ID: <9210230622.AA26831@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Re: about a policy to require encrypted email. Here is a statement I would like to see become policy and law: "A provider of communications services cannot be held liable for the consequences of encrypted communications that pass though its system." Here is the argument to support it. If I am a common carrier, I am already off the liability hook by the nature of common carrier. Suppose I am not a common carrier, for example because I provide a value-added service such as electronic mail. Also suppose that I can't observe the contents of traffic that flows through my system because it is encrypted. Then I have no means to take any action whatsoever with regard whatever consequences might occur from that traffic. I cannot be held responsible for actions I cannot take, much less know of the existence of. Such a policy would give BBS operators a complete defense against claims of liability arising from email traffic. It doesn't solve the problem for public discussion areas, but it's a good start. It would also drive the deployment of encryption technology. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: avalon@coombs.anu.edu.au (Darren Reed) Date: Thu, 22 Oct 92 06:55:03 PDT To: cypherpunks@toad.com Subject: terminal progs to do pgp... Message-ID: <9210221354.AA06975@coombs.anu.edu.au> MIME-Version: 1.0 Content-Type: text/plain Rather than rewrite the terminal progs, why not rewrite the BIOS level drivers and such ? (if its possible). At least this way, it would be one hack which would work on all terminal programs...you'd just need a way to turn it on/off which I'm sure wouldn't be that hard :-) cheers, darren From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: gnu@cygnus.com Date: Fri, 23 Oct 92 00:28:19 PDT To: cypherpunks@toad.com Subject: Re: Keystone In-Reply-To: <9210230622.AA26831@soda.berkeley.edu> Message-ID: <9210230728.AA25822@cygnus.com> MIME-Version: 1.0 Content-Type: text/plain > "A provider of communications services cannot be held liable for the > consequences of encrypted communications that pass though its system." Far too simple. Suppose the provider is a BBS operator who *knows* what their users are passing through the system? Suppose the provider has keys to the encrypted communications? Suppose those keys are only to be used under duress (e.g. under a court order)? Suppose the provider is a parent and the user is their teenage daughter? Suppose the encryption is easily breakable? The principle you are looking for is that if the service provider has no *control* over the content, then they should have no *liability* for it either. The courts are gradually making that happen. But control relates directly to the specific facts of the particular case -- not whether encryption is in use. The case law on liability for content is gradually being made. So far, no particularly horrible precedents have been set (I don't think there are precedents yet in the arrest-the-record-store-owner-for-rap- records-the-cops-don't-like issue). In a good decision, Compuserve was let off the hook for a message sent by someone who Compuserve even paid to moderate a corner of their service -- because Compuserve didn't control the content of that corner. I realize that this group has a tendency toward extremism, but let's temper that with a bit of wisdom, too. John From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Fri, 23 Oct 92 02:31:20 PDT To: omega@spica.bu.edu Subject: Re: BBS E-mail policy Message-ID: <199210230930.AA18783@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Eric, count this as another vote for default encryption of all communications links. Omega: the way to tell is to run a frequency count on the text. If it follows the usual distribution for the language it's in, then it's probably plaintext. In which case the BBS rejects it. Voice: yeah, it's a pain in the tail. One thing I thought might be interesting is to use two digitisers: one for the voice input, another for a keystream which is derived from a radio or TV program signal which can be picked up simultaneously by both correspondents. XOR the two streams together and then do whatever you have to do to make the encrypted results transmissable. I actually tried building an analog version of this about ten years ago (might even bring it to one of our meetings, just for fun). Analog voice "encryption" is actually pretty worthless (I didn't know how worthless until I experimented with it) from a security standpoint. Voiceprint modification may have some uses. About five or six years ago I built one of those: based on a pitch shifter with a graphic EQ on the input side and another on the output side. Worked, sort of. Now there is a phone you can buy with something similar built in. -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Fri, 23 Oct 92 02:39:14 PDT To: hughes@soda.berkeley.edu Subject: Re: Keystone Message-ID: <199210230938.AA18939@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Re BBSs and encrypted email. Of course it would eliminate liability; well I would expect the Powers That Be to simply outlaw the use of encryption on BBSs or find some legal convolution which has a similar result. The only way we can win on this is to do what we're doing: get this stuff out there far & wide before anyone has a chance to stop it. -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Fri, 23 Oct 92 09:30:05 PDT To: cypherpunks@toad.com Subject: Diffie-Hellman In-Reply-To: <9210231456.AA20396@anchor.ho.att.com> Message-ID: <9210231629.AA10278@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain >I'm pretty sure Public Key Partners (closely related to RSA) holds >the patent, just as they hold RSA's. This is what I remember about PKP. Public Key Partners is a consortium of four, two industry and two academic members. RSA Data Security and Cylink are the industry partners. I believe that Stanford and MIT are the academic ones. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tribble@xanadu.com (E. Dean Tribble) Date: Fri, 23 Oct 92 14:46:09 PDT To: uunet!soda.berkeley.edu!hughes@uunet.UU.NET Subject: Keystone "A provider of communications services cannot be held liable for the consequences of encrypted communications that pass though its system." In-Reply-To: <9210230622.AA26831@soda.berkeley.edu> Message-ID: <9210231631.AA11756@xanadu.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain The Compuserver decision some months ago supported this indirectly: Compuserver was held not liable for mail and postings on their system, because they don't claim to read them. I don't beleive Compuserve is a common carrier, so the precedence supports the result you want. dean From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tribble@xanadu.com (E. Dean Tribble) Date: Fri, 23 Oct 92 14:48:24 PDT To: cypherpunks@toad.com Subject: Call for papers Message-ID: <9210231638.AA11816@xanadu.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain Call for Papers "Technological Strategies for Protecting Intellectual Property in the Networked Multimedia Environment" Cambridge, Massachusetts, February 3-5, 1993 sponsored by: Coalition for Networked Information Information Infrastructure Project Science, Technology and Public Policy Program, Harvard University Interactive Multimedia Association Program on Digital Open High Resolution Systems, Massachusetts Institute of Technology This workshop will map the territory between security issues and the need for practical, user-friendly systems for marketing information resources and services. It will survey the technological landscape, evaluate the potential benefits and risks of different mechanisms, define a research agenda, and frame related implementation and policy issues. The workshop will give special attention to how and where within the overall infrastructure different technologies are best implemented. It will present and analyze models for explaining protection systems and strategies. Papers are invited on the foregoing and on the capabilities and relationship of the following technologies and strategies: -- billing servers -- type of service identifiers, header descriptors, and other forms of labeling and tagging -- fingerprinting -- digital signatures -- contracting mechanisms and EDI licensing of intellectual property -- copy protection and serial copy management -- authentication servers and site licensing -- software envelopes -- encryption -- display-only systems -- concurrent use limitations -- structured charging -- technology assessment and risk analysis The workshop will be held at MIT and Harvard on February 3-5, 1993. Participation at the two-day event would be limited to 35- 40 invitees, but the papers will be revised for publication as part of Information Infrastructure Project's publication program. Abstracts of proposed papers should be sent to: Thomas Lee DOHRS/CTPID MIT E40-218 Cambridge, MA 02139 tlee@farnsworth.mit.edu 617-253-6828 Fax: 617-253-7326 or 617-253-7140 ________________________________________________________________ The global Internet offers the beginning of a networked, multifunctional, multimedia environment for both resource-sharing and marketing information products and services. Although underlying technologies may change, the applications and practices developed now are shaping the universal broadband infrastructure of the future. However, concern for copyright protection remains a major impediment to private investment in information resources and services. Owners of information resources are fearful of releasing proprietary information to an environment which appears lacking in security and has no accepted means of accounting for use and copying. Complex library systems may be designed and developed around nonproprietary information, but until there are mechanisms to accommodate proprietary information, the utility of the systems will remain limited by the nature of the material made available. Information technology enables the vision of a distributed, interoperating multimedia environment in which information from a universe of different sources can be combined and recombined to meet specific user needs. Ironically, the vision is threatened by the absence of systematic controls. Mindful of this problem, Congress directed that the National Research and Education Network (the follow-on to the federally funded portion of the Internet) -- (1) be developed and deployed with the computer, telecommunications, and information industries.... (5) be designed and operated so as to ensure the continued application of laws that provide network and information resources security measures, including those that protect copyright and other intellectual property rights.... (6) have accounting mechanisms which allow users or groups of users to be charged for their usage of copyrighted materials available over the Network.... [15 USC 5512(c)] The Act also requires the Director of the Office of Science and Technology Policy to report to Congress by the anniversary of the Act (i.e., December 9, 1992) on "how to protect the copyrights of material distributed over the Network...." [15 USC 5512(g)(5)] Despite this statutory language, federal agencies have yet to address these issues. Many believe that the protection of intellectual property on the NREN as on any network is a private sector problem which needs to be addressed at an applications level, not within the design of the network. Indeed, these intellectual property problems are not new; to a large extent, they represent traditional copyright problems which have been exacerbated by electronic technology, digitization of information, personal computers, and less advanced forms of networking. But the prospect of pervasive, high-bandwidth, interconnected wide-area networks presents the problems in the most complete context. There is a tension between the goals of protection, on the one hand, and interoperation and usability, on the other, that has defeated technological solutions in the past. ADAPSO's proposed hardware lock failed to gain industry acceptance, and software copy protection has been abandoned except in certain high-value niche markets. The microcomputer software industry has come to rely on the threat of lawsuits in the vulnerable corporate environment as a means of copyright enforcement. Nonetheless, a hardware-secured environment incorporating serial copy management has been mandated (as an amendment to the Copyright Act) for the next generation of digital audio technology. In the emerging environment, the conventional distinction between products and services breaks down. Products are networked, and network-accessible services are linked to products. Rights must be acquired to cover all forms of delivery, because multiple delivery paths are likely and the dominant technologies and markets cannot be predicted with confidence. On the other hand, the control and security offered by different technologies may also determine the choice of distribution paths. For these reasons, the workshop will look at the networked multimedia environment as a whole, from mass-market products to specialized services. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tribble@xanadu.com (E. Dean Tribble) Date: Fri, 23 Oct 92 14:42:19 PDT To: uunet!soda.berkeley.edu!hughes@uunet.UU.NET Subject: BBS E-mail policy Now see if this number is in one of the following ranges: In-Reply-To: <9210230601.AA26160@soda.berkeley.edu> Message-ID: <9210231641.AA11868@xanadu.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain [1.5 .. 2.5] encrypted text [3 .. 6] regular text [7 .. 8] line noise This is a very simple measure. There are other measures to look for the deviation from an expected distribution, which give much more accurate distinctions. One can very easily separate languages from each other just by looking at such measures. Where does uuencoded [compressed] binary lie? I would suspect it lies right around where encrypted text is. Presumably straight encrypted text is statistically random [7..8], but that when you8 encrypt to just the ascii subset is when you lose the entropy. dean From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Fri, 23 Oct 92 10:27:18 PDT To: cypherpunks@toad.com Subject: Keystone In-Reply-To: <9210230728.AA25822@cygnus.com> Message-ID: <9210231726.AA11213@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain My proposal: > "A provider of communications services cannot be held liable for the > consequences of encrypted communications that pass though its system." First let me point out that this wording is intended to be clear, not to be legally useful. This wording cannot stand for itself without reference to the rest of the body of law. I never intended it to. It is also a mistake to think that I am advocating the converse, namely, that the provider would be responsible for all unencrypted communications. Nor do I think that this should be the only defense a provider has available. gnu: >Far too simple. Suppose the provider is a BBS operator who *knows* what >their users are passing through the system? The defense of encrypted communications is not germane here. Such knowledge did not come from the communications because they were encrypted. If the provider could read them, then they weren't encrypted to the provider. Therefore such knowledge came from some other source. A claim that arises from such knowledge is not met by this criterion. The defense of encrypted communications is not a blanket defense. >Suppose the provider has keys to the encrypted communications? Then the defense does not apply. If the provider has keys to the communications, then they are not encrypted as far as the provider is concerned. The question is not the _form_ of the communications, but their _legibility_. >Suppose those keys are only to be used under duress (e.g. under a >court order)? If the keys are in the possession of the provider and the provider and the user have an agreement that the provider is not to use them in any way other than archiving them, then the law cannot expect the provider to routinely breach that agreement to search for possibly illegal content. The court may then subpoena these keys if necessary. >Suppose the provider is a parent and the user is their teenage >daughter? The defense of encrypted communications is not germane here. There is a parent/child relation which creates a claim which the encrypted communication defense is irrelevant to. >Suppose the encryption is easily breakable? The test of due diligence may be applied. If the state of the art is that the encryption is unbreakable, then the communications should be consider to be encrypted. If the cipher is automatically crackable, such as monoalphabetic substitution, then the communications should be consider _not_ encrypted. Remember, the question is not _form_, but _legibility_. >The principle you are looking for is that if the service provider has >no *control* over the content, then they should have no *liability* >for it either. No, this is not the principle I was getting at. I was referring to a principle which was more restricted in its use but which is also clearer in its interpretation. This defense is a subset of the defense of no control. If you can't read the content, then _a fortiori_ you can't control it either. It's really very clear that if you have no basis for distinguishing communications except for size, time, sender, and recipient, that you can't act on anything that passes through the system. >The courts are gradually making that happen. This is a good sign. I heartily approve. But it is easier to define legibility with regard to encryption than it is to define control. Referring to encrypted communications is much less ambiguous and should be considered a step in the larger direction. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Fri, 23 Oct 92 10:33:40 PDT To: cypherpunks@toad.com Subject: TEMPEST In-Reply-To: <9210231704.AA25073@home.merit.edu> Message-ID: <9210231733.AA11337@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain It should be possible to jam your own emissions, but that same noise might cause be picked up by your own equipment as well and cause errors. Also remember that most of these signals are detected by correlation, which detects a signal even with a very high S/N ratio. So it's not obvious just how to jam. My first guess is to phase-lock onto your own emmissions and then broadcast random bits at higher strength. With E/M monitoring, just like cryptography, you don't really know how to make defenses unless you know how to attack. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: wcs@anchor.ho.att.com (Bill Stewart) Date: Fri, 23 Oct 92 07:55:30 PDT To: cypherpunks@toad.com Subject: Re: Diffie-Hellman Message-ID: <9210231456.AA20396@anchor.ho.att.com> MIME-Version: 1.0 Content-Type: text Unfortunately, Diffie-Hellman *is* patented, and I'm pretty sure Public Key Partners (closely related to RSA) holds the patent, just as they hold RSA's. To quote Steve Bellovin: U.S. Patent Number: 4200770 Title: Cryptographic Apparatus and Method Inventors: Hellman, Diffie, Merkle Assignee: Stanford University Filed: September 6, 1977 Granted: April 29, 1980 [Expires: April 28, 1997] So we're stuck with it being patented until 1997. Too bad - I was starting to think along the same lines about doing a D-H-based mailer. It's non-trivial, if you have to worry about active eavesdroppers swapping mail messages on you, and it's easier to do if there's a trusted Key Distribution Center, and if you think about all the cases carefully you tend to re-create either Needham-Schroeder or the Everhart-Osborn Bell Labs patent (~1980++), but you can certainly do it for the common case that says the Bad Guys are only listening to your mail and not tampering with it. Bill Stewart, wcs@anchor.ho.att.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tribble@xanadu.com (E. Dean Tribble) Date: Fri, 23 Oct 92 14:41:59 PDT To: cypherpunks@toad.com Subject: multiple message destinations Message-ID: <9210231806.AA12129@xanadu.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain Mail typically wants to get sent to multiple receivers, all with different private keys. I vaguely recall that the way PGP works is it generates a symetric cypher key and encrypts the message with that, then encrypts the generated key with the public key of the intended receiver. Is that how it works? Given that, it should be straightforward (and maybe it already does) encrypt the generated key with several public keys so you get one package that can be unsealed by any of several different receivers. Are there other ways to handle sending to multiple receivers? dean From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: "Campbell James A" Date: Fri, 23 Oct 92 11:23:11 PDT To: "cypherpunks" Subject: Removal from distribution list Message-ID: <9210231823.AA08903@toad.com> MIME-Version: 1.0 Content-Type: text/plain Please remove my address: ujacampbe@memstvx1.memst.edu from your mailing list. Thank you. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Fri, 23 Oct 92 12:41:02 PDT To: bill@anubis.network.com Subject: Keystone In-Reply-To: <9210222112.AA06121@anubis.network.com> Message-ID: <9210231827.AA19677@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: bill@anubis.network.com (Bill O'Hanlon) >>I am very interested in seeing such a protocol standardized because I >>have another use for it -- secure telephones. Given modern DSPs to do >>and cheap V.32bis modems, excellent secure voice communications are >>feasable. The presense of code in the public domain to handle secure >>encrypted links could be easily dropped right in to this application. >> >I've had much the same idea. There are a lot of people out there with >PCs equipped with Soundblasters and V.32 modems. >I can't think of a better way to fight back against that ridiculous >FBI Telephone legislation. Its not quite that simple. The amount of computing horsepower needed to do a good digitized voice compression algorithm like CELP is way beyond what a PC can do without a DSP. However, having most of the link layer encryption stuff out of the way will make the rest of the work much easier. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Fri, 23 Oct 92 12:44:33 PDT To: gg@well.sf.ca.us Subject: BBS E-mail policy In-Reply-To: <199210230930.AA18783@well.sf.ca.us> Message-ID: <9210231845.AA19935@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: George A. Gleason >Voice: yeah, it's a pain in the tail. One thing I thought might be >interesting is to use two digitisers: one for the voice input, another for a >keystream which is derived from a radio or TV program signal which can be >picked up simultaneously by both correspondents. XOR the two streams >together and then do whatever you have to do to make the encrypted results >transmissable. Its so simple to just built fully digital systems that use real public key encryption, I don't see why anyone would want to use something like you are proposing. Your system would provide virtually no real security. I really suggest that anyone who is serious about doing this stuff read unabridged (hardcover only) version of "The Codebreakers" by Kahn. He gets into lots of historical examples of how stupidly designed cryptosystems have cost people their lives. Ususally, people have very poor ideas of what is and isn't secure. I suggest that some historical perspective may give people more respect for how hard it is to do this stuff right. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Fri, 23 Oct 92 12:46:25 PDT To: wcs@anchor.ho.att.com Subject: Diffie-Hellman In-Reply-To: <9210231456.AA20396@anchor.ho.att.com> Message-ID: <9210231904.AA21331@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: wcs@anchor.ho.att.com (Bill Stewart) >Unfortunately, Diffie-Hellman *is* patented, and I'm pretty sure >Public Key Partners (closely related to RSA) holds the patent, just >as they hold RSA's. >Too bad - PGP violates PKPs patents. Everyone is using it. I'm not encouraging patent violations -- I'm just noting fact. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: jjaloszyns@bluejay.mich.fred.org Date: Sat, 24 Oct 92 10:01:06 PDT To: cypherpunks@toad.com Subject: Re: Keystone Message-ID: <9210241700.AA13531@home.merit.edu> MIME-Version: 1.0 Content-Type: text/plain Speaking of that stupid FBI phone legislation, do you know where I can obtain an exact copy of the bill? If you have it, please mail it to me. thanks... jon ------------- 43.31.28N, 84.41.41W Jon Jaloszynski Student 9-12 at Shepherd HS, Shepherd Shepherd, MI From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Fri, 23 Oct 92 23:20:44 PDT To: cypherpunks@toad.com Subject: entropy measures In-Reply-To: <9210231641.AA11868@xanadu.xanadu.com> Message-ID: <9210240620.AA08036@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Dean: >Where does uuencoded [compressed] binary lie? I would suspect it lies >right around where encrypted text is. Right. >Presumably straight encrypted >text is statistically random [7..8], but that when you encrypt to >just the ascii subset is when you lose the entropy. Exactly. uuencoding will have a slightly lower single-character entropy than the ASCII armor PGP uses because just about every line begins with the letter 'M'. This will skew the distribution slightly. But a better way of distinguishing uuencoding and ascii armor is to see that in falls in the same entropy class, and then just looking at the alphabetic subsets used. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Fri, 23 Oct 92 23:27:22 PDT To: cypherpunks@toad.com Subject: multiple message destinations In-Reply-To: <9210231806.AA12129@xanadu.xanadu.com> Message-ID: <9210240626.AA08212@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Dean: >Are there other ways to handle sending to multiple receivers? 1) You can send it to a service which copies the message and resends it as many times as you need. Or send it yourself. 2) You can have the multiple recipients each share a key and let them trust each other. (Not recommended for the paranoid). 3) You can use a secret sharing system which is tied to a private key, such that revealing the secret allows for the derivation of the private key. The secret itself is a different private key. (I'm not up on the details of these schemes.) Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tribble@xanadu.com (E. Dean Tribble) Date: Sat, 24 Oct 92 02:31:19 PDT To: uunet!soda.berkeley.edu!hughes@uunet.UU.NET Subject: multiple message destinations In-Reply-To: <9210240626.AA08212@soda.berkeley.edu> Message-ID: <9210240854.AA15621@xanadu.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain Doies the scheme I suggested (and I'm sure is not original) work? Using all the various private keys to encrypt a single cypher key that the rest of the message is encrypted with? dean From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Sat, 24 Oct 92 09:24:30 PDT To: xanadu!tribble@uunet.UU.NET Subject: multiple message destinations In-Reply-To: <9210240854.AA15621@xanadu.xanadu.com> Message-ID: <9210241624.AA12449@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Re: multiple encryptions of a message key. Yes, it works. Sorry. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Hal <74076.1041@CompuServe.COM> Date: Sat, 24 Oct 92 09:02:41 PDT To: Subject: Multiple messages + entropy Message-ID: <921024155350_74076.1041_DHJ67-1@CompuServe.COM> MIME-Version: 1.0 Content-Type: text/plain The Internet PEM (Privacy Enhanced Mail) standard uses the concept which Dean Tribble mentioned of multiple encryption (using each recipient's public key) of a single session key which encrypts the message. PGP's data structures do not currently provide for this but could be extended pretty easily to allow it. On the entropy measure - I thought entropy was how many bits of information you get per character. Encrypted binary text would be pretty close to 8 bits per character. The RFC1113 Ascii encoding used by PGP reduces this to 6 bits per character (e.g. a character set with 64 printable characters) neglecting line separators and message beginnings and endings. So there should be a little less than 6 bits per character for encrypted, Ascii-encoded messages. Hal 74076.1041@compuserve.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: fen@netcom.com (Fen Labalme) Date: Sat, 24 Oct 92 13:09:09 PDT To: jjaloszyns@bluejay.mich.fred.org Subject: ftp.eff.org:/pub/EFF/legislation/new-fbi-wiretap-bill Message-ID: <9210242007.AA14367@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain The following is the latest version of the FBI Digital Telephony Proposal, introduced in May 1992. This version removes the previous language that authorized the FCC to set standards and now places it solely in the hands of the Attorney General. Fines are $10,000/day for non compliance with services within the public switched network having 18 months to comply and services outisde having three years. The proposal now manadates that the capability for remote government wiretapping must be included into the system. This proposal clearly enhances the ability of the FBI to monitor communications. It takes the unprecendented step of placing control over certification of telecommunications equipment in the hands of the Attorney General and requires that the equipment be constucted to allow government have the ability to monitor communications from a "government monitoring facility remote from the target facility." All telecommunications users should be concerned by the privacy and security implications of creating systems that have holes for the government or any other knowledgable user to plug into. 102nd Congress 2nd Session S. _____ [H.R. _____] IN THE SENATE [IN THE HOUSE OF REPRESENTATIVES] M. ________________ introduced the following bill; which was referred to the Committee on__________________ A BILL To ensure the continuing access of law enforcement to the content of wire and electronic communications when authorized by law and for other purposes. Be it enacted by the Senate and the House of Representatives of the United States of America in Congress assembled, SEC. 1. FINDINGS AND PURPOSES. (a) The Congress finds: (1) that telecommunications systems and networks are often used in the furtherance of criminal activities including organized crime, racketeering, extortion, kidnapping, espionage, terrorism, and trafficking in illegal drugs; (2) that recent and continuing advances in telecommunications technology, and the introduction of new technologies and transmission modes by the telecommunications industry, have made it increasingly difficult for government agencies to implement lawful orders or authorizations to intercept wire and electronic communications and thus threaten the ability of such agencies effectively to enforce the laws and protect the national security; and (3) that without the assistance and cooperation of providers of electronic communication services and private branch exchange operators, the introduction of new technologies and transmission modes into telecommunications systems without consideration and accommodation of the need of government agencies lawfully to intercept wire and electronic communications would impede the ability of such agencies effectively to carry out their responsibilities. (b) The purposes of this Act are to clarify the responsibilities of providers of electronic communication services and private branch exchange operators to provide such assistance as necessary to ensure the ability of government agencies to implement lawful court orders or authorizations to intercept wire and electronic communications. SEC. 2. (a) Providers of electronic communication services and private branch exchange operators shall provide within the United States capability and capacity for the government to intercept wire and electronic communications when authorized by law: (1) concurrent with the transmission of the communication to the recipient of the communication; (2) in the signal form representing the content of the communication between the subject of the intercept and any individual with whom the subject is communicating, exclusive of any other signal representing the content of the communication between any other subscribers or users of the electronic communication services provider or private branch exchange operator, and including information on the individual calls (including origin, destination and other call set-up information), and services, systems, and features used by the subject of the interception; (3) notwithstanding the mobility of the subject of the intercept or the use by the subject of the intercept of any features of the telecommunication system, including, but not limited to, speed- dialing or call forwarding features; (4) at a government monitoring facility remote from the target facility and remote from the system of the electronic communication services provider or private branch exchange operator; (5) without detection by the subject of the intercept or any subscriber; and (6) without degradation of any subscriber's telecommunications service. (b) Providers of electronic communication services within the public switched network, including local exchange carriers, cellular service providers, and interexchange carriers, shall comply with subsection (a) of this section within eighteen months from the date of enactment of this subsection. (c) Providers of electronic communication services outside of the public switched network, including private branch exchange operators, shall comply with subsection (a) of this section within three years >from the date of enactment of the subsection. (d) The Attorney General, after consultation with the Department of Commerce, the Small Business Administration and Federal Communications Commission, as appropriate, may except from the application of subsections (a), (b) and (c) of this section classes and types of providers of electronic communication services and private branch exchange operators. The Attorney General may waive the application of subsections (a), (b) and (c) of this section at the request of any provider of electronic communication services or private branch exchange operator. (e) The Attorney General shall have exclusive authority to enforce the provisions of subsections (a), (b) and (c) of this section. The Attorney General may apply to the appropriate United States District Court for an order restraining or enjoining any violation of subsection (a), (b) or (c) of this section. The District Court shall have jurisdiction to restrain and enjoin violations of subsections (a) of this section. (f) Any person who willfully violates any provision of subsection (a) of this section shall be subject to a civil penalty of $10,000 per day for each day in violation. The Attorney General may file a civil action in the appropriate United States District Court to collect, and the United States District Courts shall have jurisdiction to impose, such fines. (g) Definitions--As used in subsections (a) through (f) of this section-- (1) 'provider of electronic communication service' or 'private branch exchange operator' means any service or operator which provides to users thereof the ability to send or receive wire or electronic communication, as those terms are defined in subsections 2510(1) and 2510(12) of Title 18, United States code, respectively, but does not include the government of the United States or any agency thereof; (2) 'communication' means any wire or electronic communication, as defined in subsections 2510(1) and 2510(12), of Title 18, United States Code; (3) 'intercept' shall have the same meaning as set forth in section 2510(4) of Title 18, United States Code; and (4) 'government' means the Government of the United States and any agency or instrumentality thereof, any state or political subdivision thereof, the District of Columbia, and any commonwealth, territory or possession of the United States. DIGITAL TELEPHONY AND INTERCEPTION BY CRIMINAL LAW ENFORCEMENT AGENCIES The telecommunications systems and networks are often used to further criminal activities including white collar and organized crime, racketeering, extortion, kidnapping, espionage, terrorism, and trafficking in illegal drugs. Accordingly, for many years, one of the most important tools in the investigation of crime for Federal and State criminal law enforcement agencies has been the court authorized interception of communications. As illustrated below, the majority of original authorizations to intercept wire or electronic communications are conducted by State criminal law enforcement agencies. Interception Applications Authorized State Federal Total 1984 512 289 801 1985 541 243 784 1986 504 250 754 1987 437 236 673 1988 445 293 738 1989 453 310 763 1990 548 324 872 Total 3440 1945 5385 Approximately, 3/8 of authorized interceptions were conducted by Federal agencies, while 5/8 of the authorized interceptions were conducted by State criminal law enforcement agencies.1 The recent and continuing advances in telecommunications technology, and the introduction of new technologies by the telecommunications industry, have made it increasingly difficult for government agencies to implement lawful orders or authorizations to intercept wire and electronic communications, as well as to implement pen register and trap-and-trace court orders or authorizations. These new technologies inadvertently undermine the ability of criminal law enforcement agencies to enforce effectively the criminal laws and protect the national security. Without the assistance and cooperation of the telecommunications industry, these new technologies will impede the ability of the telecommunications industry, these new technologies will impede the ability of the government to enforce the criminal law. Accordingly, the purpose of this bill is to clarify the existing responsibilities of electronic communication services providers and private branch exchange operators, as established, for example, in 18 U.S.C. ____ 2518(4), 3124(A), (B), to provide such assistance as necessary to ensure the ability of government agencies to implement lawful orders or authorizations to intercept communications. Over the past twenty-five years, the working relationship between the criminal law enforcement community, particularly the Federal Bureau of Investigation as the federal government's primary criminal law enforcement agency, and the telecommunications industry, in response to the appropriate court orders or authorizations, has provided government agencies with timely access to the signals containing the content of communications covered by the court orders or authorizations. As a general proposition, this has involved providing the means to acquire the communication as it occurs between two individual telephone users at a remote location, not dissimilar to a call in which the two originating parties do not know that a third party is listening, and in which the third party (the criminal law enforcement agency) records the authorized and relevant calls. Historically, and with relatively few exceptions, the telecommunications industry has provided the criminal law enforcement community with the ability to monitor and record calls: 1. at the same time asthe call is transmitted to the recipient; 2. in the same form as the content of the call was transmitted through the network, notwithstanding the use by the target of custom features of the network; 3. whether stationary or mobile; 4. at the government monitoring facility; 5. without detection by the target or other subscribers; and without degrading any subscriber's service. However, the introduction of new technology has begun to erode the ability of the government to fully effectuate interceptions, pen registers and trap-and-race court orders or authorizations that are critical to detecting and prosecuting criminals. As technology has developed, the telecommunications industry has not always ensured the continued ability to provide the same services to the criminal law enforcement community. The telecommunications industry's introduction of certain types of new technology poses real problems for effective criminal law enforcement. Legislation is necessary to ensure that the government will be provided with this capability and capacity in the future by all providers and operators and to maintain a level playing field among competitive providers and operators in the telecommunications industry. There have been instances in which court orders authorizing the interception of communications have not been fulfilled because of technical limitations within particular telecommunications networks. For example, as early as 1986, limited capabilities became apparent in at least one network which will only be corrected later in 1992. This technical deficiency in a new technology forced criminal law enforcement agencies to prioritize certain interceptions to the exclusion of other court orders. Accordingly, for approximately six years, there have been court orders that have not been sought by the criminal law enforcement community or executed by the telecommunications industry and, as a consequence, important criminal investigations have not been brought to fruition or have been less than efficiently concluded. This is one classic example of new technology affecting adversely the criminal law enforcement community: a microcosm of what may be expected on a nationwide basis without enactment of this legislation. Section 1 of the bill states Congressional findings and purpose. Section 2 is divided into seven subsections.. Subsection (a) establishes as a matter of law the responsibility of electronic communication services providers and private branch exchange operators to continue to provide, within the United States, the capability and capacity for criminal law enforcement agencies to intercept wire and electronic communications when authorized by law. These subsections delineate the existing attributes of wire or electronic communication interception. 1. Concurrent with Transmission. The application for a court order to intercept telecommunications conversations or data transmissions is rarely a leisurely process. For example, on the Federal side, the development of the required affidavits, submission to the Criminal Division of the Department of Justice for approval, transmission of approval to the Assistant United States Attorney, the appearance of the Assistant before a judge to request the order and the delivery of the judge's order to the appropriate telecommunications company is frequently completed in a very short time. However, crime waits for no one and the system for approval of interceptions must and does conform with the realities of the activity that is sought to be investigated and, if appropriate, prosecuted as criminal offenses. Since time is of the essence, current law requires that service providers and operators provide the government forthwith all information, facilities and technical assistance necessary to accomplish its mission. It is critical that the telecommunications industry respond quickly to execute the court order or authorization. The ultimate problem of timeliness, however, is the real-time monitoring of the intercepted communications. As serious and potentially life- threatening criminal conduct is detected, it may be necessary to move quickly to protect innocent victims from that conduct. Accordingly, "real-time" monitoring is critical. 2. Isolated Signal and Services Used. Nearly all of the communications network is partially "analog" at this time. In conducting an interception, for example, of a telephone conversation, the government is allowed to monitor and record criminal conversation such as a conspiracy, minimizing the acquisition of non-criminal or innocent conversation. When an electronic communication services provider or private branch exchange operator introduces a new technology--such as a digital signal--the communications are converted into a different and more efficient form for transmission, but a more difficult form to monitor during interception. The bill requires only that the provider or operator isolate and provide access to the electronic signal that represents the content of the communications of the target of the intercept2 from the stream of electronic signals representing other communications. This provision seeks to ensure that, in the new electronic environment in which signals are mixed for transmission and separated at another switch for distribution, the government does not receive the communications of any individual other than the individuals using the target's communications point of origin and receipt; the government must remain subject to the minimization standards of 18 U.S.C. __ 2518(5). This provision also makes it clear that an electronic communication services provider or private branch exchange operator is not required to provide for reconversion of the isolated communication to analog or other form. The government expects that this process will be accomplished by the government. 3. Mobility and Features. Increasingly, criminal acts are being conducted or discussed over cellular telephones or by using special telecommunications features. As this mobility is introduced, the electronic communication services providers and private branch exchange operators would be required to assure the capability and capacity for criminal law enforcement agencies to continue lawful interception. Further, this subsection makes it clear that features used by the target do not defeat the court order or authorization. For example, communications which have been addressed to the telephone number of the target, but which may have been programmed through a call-forwarding feature to another, otherwise innocent, telephone number, must be captured and made available to criminal law enforcement authorities pursuant to court order or authorization. This requirement will obviate the need for applications for authority to monitor otherwise innocent telephone numbers that receive, only intermittently, calls forwarded by the target. The effect of this provision is to further minimize monitoring of calls of innocent parties. Similarly, certain speed dialing features that mask the telephone number called by the target must be identified for criminal law enforcement investigation. The ability to consistently determine the destination of calls is critical to minimizing the monitoring of innocent calls. 4. Government Monitoring Facility. Government agencies do not normally request the use of telecommunications industry physical facilities to conduct authorized interceptions nor is it encourage by the industry. Normally, the government leases a line from the electronic communication services provider's or private branch exchange operator's switch to another location owned or operated by the government. This minimizes the cost and intrusiveness of interceptions, which benefits the service provider or operator, as well as the government. Accordingly, the ability to monitor intercepted communications remotely is critical. 5. Without Detection. One of the reasons that governments operate their own facilities is to reduce the risk of detection of the interception, which would render the interception worthless. At the present time, the existence of an interception is unknown to any subscriber and is not detectable by the target, notwithstanding folklore and spy novels. This provision merely ensures that the secrecy of effective interceptions will be maintained. 6. Without Degradation. Maintaining the quality of the telephone network is in the interest of the government, the industry and the public. Presently, the existence of an interception has no effect on the quality of the service provided by any network to the target or any subscriber. This provision ensures that the quality of the network will continue to be uncompromised. Absent the assistance delineated by this legislation, the execution of court orders and authorizations by the government could well disrupt service of the newer technological systems, a result that this legislation seeks to avoid. Subsection (b) provides that electronic communication services providers and private branch exchange operators with the "public switched network" must be in compliance with the minimum intercept attributes within eighteen months after enactment. Thereafter, new technologies must continue to meet these minimum attributes. Subsection (c) provides that electronic communication service providers and private branch exchange operators that are not within the "public switched network" must be in compliance with the minimum intercept attributes within eighteen months after enactment. Thereafter, new technologies must continue to meet these minimum attributes. Subsection (d) provides that the Attorney General may grant exceptions to the affirmative requirements of subsection (a), as well as the implementation deadlines of subsections (b) and (c). In considering any request for exception, the Attorney General will consult with Federal Communications Commission, the Small Business Administration and the Department of Commerce, as appropriate. Accordingly, the Attorney General has the authority to except, for example, whole classes, categories or types of private branch exchange operators where no serious criminal law enforcement problems are likely to arise, such as hospital telephone systems. This subsection also permits the Attorney General to waive the requirements of subsections (a), (b) and (c) on application by an electronic communication services provider or private branch exchange operator. Accordingly, if a particular company can not comply with one or more of the requirements of subsection (a), or needs time additional to that permitted under subsections (b) or (c), the Attorney General may grant an appropriate waiver. Subsection (e) provides that the Attorney General has exclusive authority to enforce the provisions of the bill. While a number of States have authority to seek and execute interception orders, they will be required to seek the assistance of the Attorney General if enforcement of this legislation is required. This section also provides for injunctive relief from violations of the provisions of the bill. Subsection (f) provides for enforcement of the provisions of the bill through imposition of civil fines against any company that is not excepted from the provisions of the bill, does not acquire a waiver of the provisions of the bill, and fails to meet the requirements of subsection (a) after the effective dates set out in subsection (b) or (c), as appropriate. A fine of up to $10,000 per day for each day in violation may be levied; for most companies in the telecommunications industry this amount is sufficient to ensure that compliance will be forthcoming. Although this provision is not expected to be used, it is critical to ensure that compliance with the provisions of the bill will occur after the effective dates of the requirements of subsection (a). Subsection (g) carries forward a number of definitions from the current provisions for the interception of wire or electronic communications under "Title III." The definition of "government" that is currently in use includes all States, territories and possessions of the United States, as well as the United States, is made applicable to the bill. [Footnotes] 1Interceptions for foreign intelligence and counterintelligence purposes are not counted within the figures used here, but would likewise benefit from enactment of the legislation. 2 Whether the content is voice, facsimile, imagery (e.g. video), computer data, signalling information, or other forms of communication, does not matter; all forms of communication are intercepted. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: fen@netcom.com (Fen Labalme) Date: Sat, 24 Oct 92 13:24:14 PDT To: jjaloszyns@bluejay.mich.fred.org Subject: Re: fbi-wiretap-bill (& ftp.eff.org) Message-ID: <9210242023.AA15395@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain >> Speaking of that stupid FBI phone legislation, do you know where I can >> obtain an exact copy of the bill? If you have it, please mail it to me. Mail sent. Also, a pointer to ftp.eff.org is worthwhile to note. I just grabbed a new copy of the bill from there, under /pub/EFF/. Below are some file listings from their archives. Enjoy! Yours in networking, Fen Labalme fen@genmagic.com fen@netcom.com Just say "Know!" General Magic Broadcatch Technologies We Are Everywhere Member of the League for Programming Freedom , the Electronic Frontier Foundation , and the Computer Professionals for Social Responsibility ftp> cd pub/EFF 250 CWD command successful. ftp> ls 200 PORT command successful. 150 Opening ASCII mode data connection for file list. eff-issues legislation about-eff Index mission-statement legal-issues .message about-eff.ps papers local-chapters historical newsletters newsnotes 226 Transfer complete. 160 bytes received in 0.012 seconds (13 Kbytes/s) ftp> cd legal-issues 250 CWD command successful. ftp> ls 200 PORT command successful. 150 Opening ASCII mode data connection for file list. bbs-defamation privacy-vs-amendments Index copyright-law-software copyright-libraries bill-of-rights-overview ecpa-laymans-view email-privacy-biblio-2 media-and-law email-privacy-research search-seizure-files review-liability tempest-legal-issues bbs-and-the-law against-look-and-feel computer-security-intro cyberspace-legal-matrix electrifying-speech eff-fbi-analysis private-open-society 226 Transfer complete. 411 bytes received in 0.038 seconds (11 Kbytes/s) ftp> cd ../legislation 250 CWD command successful. ftp> ls 200 PORT command successful. 150 Opening ASCII mode data connection for file list. ecpa-1986 Index computer-crime-laws fbi-wiretap-bill telecom-act-hr3515 ecpa-1986-senate-bill tribe-proposed-amendment nren-bill-text gpo-windo-info privacy-act-1992-calif gore-infrastructure-bill new-fbi-wiretap-bill 226 Transfer complete. 230 bytes received in 0.024 seconds (9.3 Kbytes/s) ftp> From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: deckard@chezrob.pinetree.org (Stephen Pandke) Date: Sat, 24 Oct 92 14:49:54 PDT To: cypherpunks@toad.com Subject: Removal From Mailing list Message-ID: MIME-Version: 1.0 Content-Type: text/plain Unfortunately, I must request that I be removed from your mailing list. ] Stephen Pandke --- Stephen Pandke - deckard@chezrob.pinetree.org C.R.I.M.E. BBS - (Chez Rob's Int'l Mail Exchange) 613/230-5307 (data) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: shawnb Date: Sat, 24 Oct 92 20:33:12 PDT To: cypherpunks@toad.com Subject: pgp key distribution Message-ID: <9210250333.AA11925@toad.com> MIME-Version: 1.0 Content-Type: text/plain I'm pretty new to this mailing list, so something along these lines may have already been proposed, but I was considering the possibility of putting together a list of pgp public keys for distribution through this list. My own collection of keys is pretty small, and I would pernally like to expand this, but I think this would provide a great service to the group as well. Let me know what you all think. Shawn From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: David Cabana (MTH) Date: Sat, 24 Oct 92 17:43:41 PDT To: cypherpunks@toad.com Subject: pgp Message-ID: <9210250037.AA19290@ultrix.csc.usf.edu.> MIME-Version: 1.0 Content-Type: text/plain Where in the U.S. can I ftp a copy of PGP? I tried Kauri.vuw.ac.nz, but their README asked that I not transfer files. I would like to respect their wishes... Thanks, drc From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Peter Shipley Date: Sat, 24 Oct 92 20:54:34 PDT To: shawnb Subject: Re: pgp key distribution In-Reply-To: <9210250333.AA11925@toad.com> Message-ID: <9210250354.AA00857@edev0.TFS> MIME-Version: 1.0 Content-Type: text/plain jyanowitz@hamp.hampshire.edu is already creating a list (you can find it posted to alt.security.pgp). As for me I maintain two public rings one is a collection I have collected via direct contact (friends mostly) the other is jyanowitz's list plus random other rings). -Pete Ps: I do not know jyanowitz (etc etc, but while we are on the subject) but I guess I should relay his request for people to email him your keys and public rings my casual key: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQA9AirUzbUAAAEBfjC3p5COEUMJ3xzrq4sJCTaU5MgvzC94tp8yxxBJeKUGo7xx gMShBCnIZp+xlFiyxQAFE7QYUGV0ZXIgTSBTaGlwbGV5IChjYXN1YWwptAZjYXN1 YWy0JlBldGVyIE0gU2hpcGxleSA8c2hpcGxleUBiZXJrZWxleS5lZHU+ =OR9u -----END PGP PUBLIC KEY BLOCK----- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: joeb@arden.linet.org Date: Sat, 24 Oct 92 21:11:19 PDT To: cypherpunks@toad.com Subject: remove from mailing list Message-ID: <9210242237.aa22143@src4src.linet.org> MIME-Version: 1.0 Content-Type: text/plain Please unsubscribe me from your list. The mail load is just too much. I noticed that there are alot of people that subscribe then unsubscribe. You may want to consider mentioning in your ads the nature of this forum. I assumed it was a periodical newsletter of some kind. I would speculate from the frequency of subscribers that quickly un-subscribe that many are under the same assumption. This topic is very interesting but the mail is just too much. If you guys come out with a newsletter of some kind I'd be very interested. Thanks and sorry for the extra work. - JoeB From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Sat, 24 Oct 92 19:34:56 PDT To: tribble@xanadu.com Subject: multiple message destinations In-Reply-To: <9210231806.AA12129@xanadu.xanadu.com> Message-ID: <9210250201.AA07719@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: tribble@xanadu.com (E. Dean Tribble) >Mail typically wants to get sent to multiple receivers, all with >different private keys. I vaguely recall that the way PGP works is it >generates a symetric cypher key and encrypts the message with that, >then encrypts the generated key with the public key of the intended >receiver. Is that how it works? >Given that, it should be straightforward (and maybe it already does) >encrypt the generated key with several public keys so you get one >package that can be unsealed by any of several different receivers. Yes, that should work. PGP doesn't do it, but it would be straightforward to change it so it could. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Sat, 24 Oct 92 22:03:00 PDT To: shawnb@ecst.csuchico.edu Subject: pgp key distribution In-Reply-To: <9210250333.AA11925@toad.com> Message-ID: <9210250427.AA08570@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: shawnb >I'm pretty new to this mailing list, so something along these lines may >have already been proposed, but I was considering the possibility of >putting together a list of pgp public keys for distribution through this >list. My own collection of keys is pretty small, and I would pernally >like to expand this, but I think this would provide a great service to the >group as well. Let me know what you all think. I keep seeing people propose things like this, and I can't for the life of me understand why. The only way to know for sure that someone's key is theirs is a signature from a trusted introducer anyway, so people can just ask each other in clear for public keys and it doesn't do a lick of harm -- if they have a trusted signature, you can use their key for communication and if they don't, you have to find another way to verify the key. People making lists of keys and distributing them seems fairly useless to me. Can anyone tell me if I am being really really thick here? Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Hal <74076.1041@CompuServe.COM> Date: Sat, 24 Oct 92 21:47:19 PDT To: Subject: Re: remove from mailing list Message-ID: <921025044014_74076.1041_DHJ64-1@CompuServe.COM> MIME-Version: 1.0 Content-Type: text/plain What we _ought_ to do is to remind people that they should send their unsubscribe notices to cyherpunks-request@toad.com, _not_ to the list address. That way we wouldn't all have to be bothered by reading these messages, and the list volume would be that much lower! From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Sun, 25 Oct 92 12:08:31 PPE To: cypherpunks@toad.com Subject: re: multiple message destinations Message-ID: <3266.2AEAF026@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain U> 1) [...] Or send it yourself. As a paranoid person myself (I use the two phrases "sufficiently paranoid" (me, and most of us in here are sufficiently paranoid -- to at least consider the issues) and "insufficiently paranoid" -- people who conduct business over cordless or cellular voice, etc -- these paren'd subtexts are getting out of hand -- as a paranoid person myself I would only trust sending them myself. It's really a "code" issue -- given a list of addressees, will the miserable program you're using do the work for you. --- ReadMail * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Sun, 25 Oct 92 13:08:17 PPE To: cypherpunks@toad.com Subject: re: pgp key distribution Message-ID: <3269.2AEAFD72@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain U> From: shawnb@ecst.csuchico.edu (shawnb) U> I'm pretty new to this mailing list, so something along U> these lines may have already been proposed, but I was U> considering the possibility of putting together a list of U> pgp public keys for distribution through this list. My The FidoNet has an echo ("newsgroup") where each message ("article") is someones public key. Here's my keyring, for what it's worth: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAirSicsAAAEEALQ8l1jjbcASxKkdlHACfaE+em9i996Sos8ox50JjhZNu9N6 mft8V0App0eXTYAEumnz+CVVJXjzMUgloGs1ZnyvqkT3VhaF6CyUSUFwXIym/IUk buvs3qqEU55yGTl1s2gcjgiqyL/1jmOIdaaMQNrQ4/4x28gaOFQYMJXaJ+w1AAUR tC5XZXMgUGVya2hpc2VyIDx3ZXMucGVya2hpc2VyQHdlaXNlLm9tYWh1Zy5vcmc+ iQCVAgUQKtRrakq2SryVeKUXAQGF4AP+JDQawppDmAteShKF6Be24MGpByxYnIYR XyHpKOIcGx45S7FZOoS+mGzU4VXRYF9reHvfYGnz0GGjZ962K5tFJSSupF7ccxBi nLA3EYltX8iIufbyLwoS6Bb2gmX6Z5kfDVcffvlw8RqWFAwxows6QU8VvadLa40B mEjvVqzAIgiZAI0CKuQvgAAAAQQA0CiZieU9eimeaz1G1TSWf0KIsmWOyw55+UL0 D5AgO6NeE9PIClsvpU+pJRKgUX97vbFMmLHKvAFCHDmUC9+9A8SIYgVBBjG+IX5C D/7r8lW8sKO+cZUWX2QpMRhV443EE0aJpe5ITRUxAvHjuI/0BT7BjDrZpeZM21bU FS1fkEcABRG0MEphbWVzIEEuIENhbXBiZWxsIDx1amFjYW1wYmVAbWVtc3R2eDEu bWVtc3QuZWR1PpkAjQIq43aAAAABBACqyZ7OXOK217FIvtParcy1nOgZUcLqrapK Fq0nefdbEHLiaB+i1jeTdSoUqehMi3+ZiDICDxuVF6yBqCDsrl3tOd8mLC3Pe6Bk W4gCi6KI2XrIpb1DCKc4EscjzWSku2E0lYiLAfkh4BTwzxcbTr6Yj9CJjVb1JJ46 YDMOhX+YvQAFE7QrRGFyaW4gQ293YW4gPGNvd2FuQGNlcmlhbnRodXMucGluZXRy ZWUub3JnPpkAjQIq4AX1AAABBADPMVf0NZ/LoWxUJXf+a3dTG0xIHW+FCfKbn5os 9ZLwQTV/tloYGolyVSEqIjS7EgxtoFfiqzJyMkN5o4ctxCXs/xcBKfwiib6ffLPn cz5hNInkylhUu6b9K0ZDV5kfzdoeTR2H8SDT2e3vn/GOlCGosOzJS2crKfwnisK+ iFySIQAFEbQJVGVkIFJvbGxltBMyMDEwOjEwMC8xLjBAU0RBbmV0tBIxOjEwNS8z Ni4wQGZpZG9uZXSZAI0CKtfw+gAAAQQAxHc5YohUHjHM3UGj91c39vsntGzR/8cH +m0RokT7/F/F3zXNdLTumHlD92OK4hdAPWEp+xVAygyKKDp+LBFI4JTPhx2iNELm yum5SusJMf1FW+2m6zIK/0gzMqgd2QDb6GsMsFqxlDctnIrz9uqZCJuD3LfHjucw 9RbQfSEuxUsABRe0Okd1eSBNYXJ0aW4gMToxNDMvMjY5IChndXkubWFydGluQGYy NjkubjE0My56MS5maWRvbmV0Lm9yZymZAI0CKtXkPgAAAQQA2srhlr3MEdQ+rcQv atnLX5mhZavCVuyc44Ezhn1EG/kd0vafg93Y5EJTplPryrPeABmuC72RhJ2kdEnZ nsAxO+SkJzX3/FlnVyatu7VVosR2Wcl5pLQMhaYz0ZhRRoIv1GIqAnMmcD/SbBFD puSkzTD4Mjn7TPHJo6l60efyPZUABRG0J01pa2UgTGFzdGVyIDxsYXN0ZXJtQG9o bS5lZS51dHVsc2EuZWR1PrQfTWlrZSBMYXN0ZXIgPDE6MTcwLzEwOUBmaWRvbmV0 PpkAjQIq3Pf5AAABBADTqwU2BaFR8+VElyuQ7VXkGn2IcVPZYxH1pqTRI7G+HTnB iaZl2dT24CkSD5uO7TPAPxFl0A1hDzt03cv3SMdIkfbAxWzI1dwno0+Wy5z84puf tYPjaXA08Dc1L8pAiZzDYtx95NBCKqirjbTFuOl7BUB2HYpjv+K+Xqpu25EANwAF EbQxQmFycnkgS2Fwa2UgPEJhcnJ5LkthcGtlQGYzMy5uMTI1LnoxLmZpZG9uZXQu b3JnPpkAjQIqwncSAAABBACvXC8GUY83UrGJPzD2CG098ZiWfu9yMTPKz2ji+TK4 e0KI5M13DWa+1bWPm+WWv0dYnJrKSmQ7sYbKK3owd/byvNIYC6QfN2Nl0C8RcNk4 lduLlOlEWXzQuLKPaZhqx9uahtibSnHmf705lDnXN4ijPAd5ooc30tf/+yHKJrNc 0wAFE7QtSmFzb24gWWFub3dpdHogPGp5YW5vd2l0ekBoYW1wLmhhbXBzaGlyZS5l ZHU+iQCVAgUQKtBLM//7Icoms1zTAQFkqQQAndM0KgNy0hBQEI7QUrxMBE1nNzvg 5hpoqBO0nCmlckhzB1JZfUATCU9zkNyZ9VifFuGSnoj1HgPYl4lEDOtASZm8MUup bSb1T1JMdkM6C50t9WjPl6LIj0tldHLGefDqpOTantqCdyz8WuRqUJ7S/JKPTNQ0 t5LidT1o4s3/M42ZAE0CKtrZngAAAQIA9UJPv2NsjfiajySZ3ihHPNNUA3J+pBke dcQ6JVpsB1/BS1NVx8KGKivpPXgFtYvtR4oBEZEVlLCZWKoJnH6ZvQAFEbQiUmlj aCBWZXJhYSA8MToxMzUvOTA3QGZpZG9uZXQub3JnPokAlQIFECrchQltbThSc0ua WQEB4uIEAKN+Cl7wUI/1tFckEfZc7WDbsN8F3wP+mZVanZOeQi8KlViSsatQ7D9E 1LfjNo/03BE7vDODpm3l/RHhQLwfDkMuS49EBDF0qhIn45X4v6ImUrF4Fs1MRPQE 10lnoWQs2CjStPmSWhG2jvL7xMPSy1r8m4n6dxGcyxCFML8ckyU8mQCNAiraG3wA AAEEAJuaF6NRnKvVEU3edX8OUxMdb+k3ZRfd2KM3b7+7mahkMqTfKj/wiNpqbnnV /pKoD3jf35KjO0i+Oa5spGCc3I7VCDDcKhHV6iZcYD0lpF2ySh5sUFsRGqWO4oo/ jyzrNgzV0awrg2IYT5u7ClLXbpuZGcdIKbTNdZuaN9X1csanAAUTtDFKaW0gQ2Fu bmVsbCA8SmltLkNhbm5lbGxAZjIxLm4yMTYuejEuZmlkb25ldC5vcmc+iQCVAgUQ KtpDRG1tOFJzS5pZAQHn0wP+LkupLVZYBbGPfXdkHaCxwRWEc5xBfIRO2SwpJZBB HclFuu0OxxOuilc6bAiswbPHoMSP0MnOChOa+g0BFxhRjfKVXiXhP2Oo1lqAZ41r 7E9h4oYs4YYo7fjM1lZZtezWNKIibuW57lhdyvLMbDx6oxCP55AG7zTWRzL0DQnY sjOZAI0CKtHW8wAAAQQApMSslBzYEUQzIER/SRu3xXTdruTE0EQ4CZfa9ZNhVbTx e6joVfUzLTSno6iwzjEJgSeL/yPIukK3hH2whUXLD87dcR+dhSuuK7ans2owRo+c CfH3zKTyMleHZEAVoTSOaDPVVUfUaDpukr0ujXMBa8DAIuoJrsKPiJ6a6GXD6cEA BRe0JkppbSBHcnVicywgVzhHUlQgPDE6MjM0LzFARklET05FVC5PUkc+tB9KaW0g R3J1YnMgPDE6MjM0LzFAZmlkb25ldC5vcmc+tBNKaW0gR3J1YnMgPDE6MjM0LzE+ iQCVAgUQKtT1Lm1tOFJzS5pZAQEfUAQAjYXS5sbp/8ewlqx/TAa/S7n9DSgppoBE Qrqp4uFDInSWvyVz5VsGgbV7tP1Sxntvt9++xwfn2LdSPPDfBLElAiZ+Fd6yRwVd 7wWVbmFml0xFxHwhR6sfovEZ9Mr0RjdeefZhTuN3jWV7EQBHxyFlUQehf7jG104T n45Sv0x7CIu0FkphbWVzIEMuIEdydWJzIDxXOEdSVD6ZAI0CKtW12AAAAQQArC5O dv3qYspAvcmybjWopLbXQJ2EINYd3xiTEnKqKkdyytTIDVIFdmd7sbaaAz9fuGZ4 Gg66Fp+Y3PeVYizkiGIMqpxqcXaLbAaO2A+ZCpmYjbB6s9ZzqcjHUsPF1gg7v1Ll DPDGVA1eNxNqcjpAW1PAfN+mL1UhH8u5b+eWBQEABRG0JVBhdWwgU2NoZW5ja2Ug PDE6MTM1LzM0MEBmaWRvbmV0Lm9yZz6JAJUCBRAq1k5AbW04UnNLmlkBAS6nA/9B MkQ9xoehzuOVyvBRqU7dIDiGR2TKp9q+XTe5tflTqfAhGDJeiUrxVt+FsflXJTQg Hmu6RLXNLyVdZv7N5EyfrQ+SRyxpmPLjsWWCk9CBQ9N0yvGOOgXJHJ/fNDRlW6Ce 67qS0czMyhVe5clvBnGg0dOWddUWOvNYN/u+9G3wxJkAjQIq0f0bAAABBADgjzog l/b8dE3nct9bIGDrHyLFXMVvcVfK5DUsKvNrah9aGjMF2fPxu5Lujk6btTynY0If AHuzz/7i7UMfDhLD8YBHBJJNJ28C2TogiIS9jZg+AOWtUvUA+yJ3s1r9CAWgXWFi hTYWmu6f9FWBq3WnSKYqre6djqPZrd7oItiG4QAFEbQhVG9tIEFsbXkgPHRvbWFA c2FpbC5sYWJzLnRlay5jb20+mQCNAirQwOsAAAEEAPELC7P7vLHK5hz9urWhk9BJ +2i9U1Yzzm6MKM/SI+UAVcXsYTP5g9kGJLUpLVq7KxalB1Rqbvg9FjjIaoiQ+ze7 JIPC5X+e0uU43iLMHkgz2mCg56p9hpgkDxwM3R+cHQ1cr2qrSJb8sClbYtknbgec NM0JMusvUNwtSKqN9fslAAURtExNYXJpYW5uZSBDb3dsZXkgPDE6Mzc3LzNAZmlk b25ldC5vcmcsIG0ubG92ZUBiaXgsIDcxMzMwLjI3MjFAY29tcHVzZXJ2ZS5jb20+ iQCVAgUQKtEZf21tOFJzS5pZAQHMqAP9EKg/17mW/gi0eWiUT/PpY+R+jBi0VtXA dq3HZo+VAFEyARt/fqiOuotiC7OFtnsuTPVtarOSxRpz/5bWdIr7AGIdbnwD2dmZ wvqWDBjvPDzQK1MwPPDpyqRtlEdU9LpwFkn9rVy77KShivrp4xHTVu4RjQUZ8EE5 8ilDyhDolZSJAJUCBRAq0MaYednIlhgdxdUBAaqkA/4gm475FKoXXM9X0/1KH7HR qAiu+VnrfvljT6GJt8c0BGtVsELLAGODAWCuzmP21IWlRznGvipnFXPoTrfi9bkj BijCKmdhB/atLi9FB+YO2B3PWtwmUnWbIa7CQO9vxe4t8jYbyDiICAv72dLJXTHg MxPJAuFIO0ECqScYfb3ol5kAjQIq0LpgAAABBACUmiHr4bN1FBXm/zO/6Yt1bpyZ rbcxLv/0pFk7/FkaPghdXXyjMZWSnosbw/2dVMMv3R1vJB1mWGl6W+tOkqjeqteO AE5Cf/iZHTGE4doS0pGdF8wa6e+mPFRZa/lV+3D9Rh0qDqoAlc0FShvd3aGUEI7e iIB7cGF52ciWGB3F1QAFEbQ9V2VzIENvd2xleSA8MTozNzcvMTQsIDcxNDQxLjMx NTRAY29tcHVzZXJ2ZS5jb20sIEJpeDp3Y293bGV5PokAlQIFECrQx1HcLUiqjfX7 JQEBEoAD/0YzuJ4LMxKY3CunHyOHmGbAcOEXcG6jqH3GarymZgisy1s1OZB5V5ak 4CzrGCj7Yj8k35KDjp+IcQHDM1JpUDUKB5p1iLblWOWmIa0Zb7SgS4gYDY042knk leCYpP39mrBC91SSFrGIWjM+wB9J1Izs8N5bWe0EEJonplR701/omQBtAirXWtcA AAEDALKH2cKuVzOuSo2NTQVwNtiysY+7piD8FZxzjvDGgOYGVJMagPP3ohPmlKVw mky6ljqtDVaGKDNBmWQlYy4KINpcPI801PtTnqzvLGa3aVs1hMX7mt218hn/G1O2 n+mdCQAFEbQ5RGF2aWQgUG93ZXJzIChkdHApIDxkYXZpZC5wb3dlcnNAZjU0Lm4x MjUuejEuZmlkb25ldC5vcmc+mQBNAirXO6sAAAECANunzqcH3SLKWFweZ3BAUXO3 OuAISoBxocBtjmgsvndahwdXFGkQzSPgf6uWt3HIksD0a6sKPOrQjUXODZuyxIMA BRG0OERhdmlkIFRyb3kgUG93ZXJzIDxkYXZpZC5wb3dlcnNAZjU0Lm4xMjUuejEu Zmlkb25ldC5vcmc+mQBNAirXWbAAAAECAKOREYOarMoniJ492Q11sfFe5jNAwqb7 p5UyUCPJmcWXZ4mlHIWkmhqOXUM4VArnYKVIrddBDbkaEVBAW2UrY20ABRO0I0No dWNrIEhheW5lcyA8MTozMDgvNjBARklET05FVC5PUkc+mQCNAirUKygAAAEEALVQ CansIsa6a+WfQiSOZDko678W7O4A/A7iUmJszodnQD+FVy+L2mcsL9pAjNwhAlHs Bb35FOVyD9XasQoyVFUZUrF7n6M5RruGGMrs5Pv2m1tVzkeZcSTWyPS7ovLQXRlt BuS9QbdZu5j8CzMM6g6GvvbqrK01TG5mb1FL1TGDAAURtAtKaW0gQ2FubmVsbJkA jQIq0KeFAAABBAC72+eRnJzbsIhU9gvXFkTddv48TQY0tQoCo9xa9Y8ocZaaemjQ 4uZqb1Hu0pgcTLdz0fM5FL9ZONnINKLkP+neAHhhY1CVLC/1wi4No4XCUvoW+mrW d0gO5rZCETi1866/oQNtl5WttsMicmp+955B/y5LL56lj0aWu/QAnbJS3wAFEbRH UmlkZGxlLCBNaWNoYWVsIEguICA8bWlrZS5yaWRkbGVAaW5ucy5vbWFodWcub3Jn ICAxOjI4NS8yN0BmaWRvbmV0Lm9yZz6JAJUCBRAq1G3WSrZKvJV4pRcBAQ41BADK KK/0vQqSZRfNZ48miAHrM7gwMxmLQzncqHC4H0dio3cx5r4frtmILtb75S/RZ5dT Ghkcyj90F4Zi5S80GvP7LgSOMArzw8WybQWmbWiR55DU6JzSEF8KvX3Re85WCy8m eV7HxvLJ9aF6vjptfCapqZPHAN2p0AFeIJIRRb0wrZkAjQIqrDZMAAABBADCljOd puRFotKHCuLtXAtjz8h0+rWr5PTwt0weVwWA3oH93bJXUaZ4yY9a/mjtPBRTvkCx CPcLQar39Tzz+Yi1+7A9riFZSR9eDD7clbY5vWSm/CTLQlu+NOOQYLRwQvckN1e7 1zVeYzOnRNqHJx+ACP6QRaxiyTyoEwOvWCFMNwAFEbQmSGFsIEZpbm5leSA8NzQw NzYuMTA0MUBjb21wdXNlcnZlLmNvbT6JAJUCBRAqrjNU4nXeDv9n9wsBAcq1A/97 qFdsvhbonK63dqA2sIDsPRI3MehPk8vT1T6ir35S7NM2Mhn3hVUoAW00gz91/dTd xevJ8nZfSfVQOkEQhnpRzNXGUbpAidAGGymH6cFDdMYxBh7A63doE+YlpQd7wWb4 vumG7OK0qvoMmc1Ztf/qEazHp99n89q9Ai4FLR6JNpkAPQIq1mizAAABAYDJSSC4 n8a1x/H5CcCW3kh1wGNUPfwMz8mxlctA8f6u9Ba93SoTOl6EhIGsNhM859kABRG0 Fk1hcmMgZGUgR3Jvb3QgKGNhc3VhbCm0I01hcmMgZGUgR3Jvb3QgPG1hcmNAa2c2 a2YuYW1wci5vcmc+mQCNAirWUOIAAAEEAMwYAT+znuzvB5vAdm4jB+EJiKdnoA1E vxL+Wa4L4W9Q2np1cgblqEvH8uN7nDvy8HX56LMDu6FzlWRHlNqK9z4XgQ7BYKue vNhcxyHQE5/NxlKtI5oSEg11mLLU5nS0EZ9EUwEhQWMhYI5PitvxTVM9tcKifqW/ BMyG4cAURCo/AAURtCJTdGV2ZSBDbGlmZm9yZCA8MToxMjUvMjA5QGZpZG9uZXQ+ mQBNAirV2r0AAAEB/i78BfdkmEIqKt2EhdlFAJc44rB3ZMzChez5zVcB9jRpUz1o MY2M2GnucGRUcvMSvZeF/aqCVIHuodDfqyGYYTkABRG0L1NlY3JldF9TcXVpcnJl bCA8U2VjcmV0X1NxdWlycmVsQFRyZWVob3VzZS5DT00+mQA9AirUzbUAAAEBfjC3 p5COEUMJ3xzrq4sJCTaU5MgvzC94tp8yxxBJeKUGo7xxgMShBCnIZp+xlFiyxQAF E7QYUGV0ZXIgTSBTaGlwbGV5IChjYXN1YWwptCZQZXRlciBNIFNoaXBsZXkgPHNo aXBsZXlAYmVya2VsZXkuZWR1PpkAjQIq0QwSAAABBADUsUTcG5jiohLNic8LAX59 ykQN8vF9CUnB/BQq5au7ShhVYKfAuGztlAkPk0/KdVeXG7Ae+feMpCAHYvZQnn8V z9I/yHdzQVekNQkOG2JxT3C2pQWes5RiAfUyHcCsXoJapVMVXDwRqb/GGTmCSbjs Zesexg9tCMydbzScJkT/zwAFEbQpTWFyY29zIFIuIERlbGxhIDxtYXJjb3NAemlw cHkuc29ub21hLmVkdT6JAFUCBRAq3gxmzT/tLvUlcRcBAV06Af4v/SjkJqxjmSwQ 71TngTsSJEEchXRbGdgHc22eZulnI1BXq2Y+IGpJR1IkQDO9aia17sx/bWi6aY60 lRKe4NzZmQCNAiqwg10AAAEEAMVNMI766ljeuW01xqXKYYV5lmDPvb+6dCQK3m1i BQdan0nopm35j1DIRp3UJZogAe5eimsQg1TALDhTq310OZs9+L6B/HxeX3+4BadI Dad4g+xIlvaFY1Ut/hMdZNkw0tzNZOdUPiO4jYIyirReAUiMCm6jXzkTRITj7/vx xWtPAAURtDNSdXNzZWxsIEUuIFdoaXRha2VyIDx3aGl0YWtlckBldGVybml0eS5k ZW1vbi5jby51az6ZAE0CKrtlMAAAAQIAwCr9FqO5gRboIusjiAAaXo1gb/erXefm 2czvKvWmzm6ARZgOrxcWCr6oUVd5dFEbIbJPFaz3OJkY/DS+zBmQCQAFE7QqQnJh ZCBDLiBNY0NhcnR5IDxmNjE3Lm4xMjUuejEuZmlkb25ldC5vcmc+mQCNAiq2rm8A AAEEAMuZvHCZd4CGhdDcfVfJjx6H/cB5UFJ0FhkzaluDZ37FK7nn9BXhcECVA2o3 TQWPjIh/787s2r3gFSERaI4HlFaXjWvIJ/3BYgkKCxbSmzN9PIrA/QPvNXyv/rE2 XBEFoR9ixWz8W9JEEkkwjSuR3o1/W80iM/sGslOJmEM5slffAAURtCpTaGF3biBL LiBRdWlubiA8Zjc1NTAubjEwNi56MUBmaWRvbmV0Lm9yZz6JAJUCBRAq0NfZbW04 UnNLmlkBAaxzA/9GvJvWV/Y1URG190TA1epJyUG2RRrtii/bMqgBXKH6kEVhMznJ 0M+/huF4213nctZE08RynCBsgpVxQ+y6oBC/Gxw9Yuci1PAB033+NZAbc7cJaOxg mZX7PS6o96s1/Rhl2RHlhDscJd9KgX111hLFJBayvOFIfy9Aimt76WFulpkAjQIq zS3+AAABBACzMsjb4rG9UyVR8oYL7WvZ6Q8BaCSDqSaq7/HK+TqXgjoZE4cYVg/3 WJkmRM8ZbuOwVA49Ssg0Xpj9KINC6dsbMSS5gIhlineM2JR6ioVwICSbsylivDug Tn2VGxWMAgihqJ2z7Tz3VD6eSgpbkqSwXU9gULJNKJFtbThSc0uaWQAFEbQoQ2hy aXN0b3BoZXIgQmFrZXIgPDE6Mzc0LzE0QGZpZG9uZXQub3JnPokAlQIFECrQxmzc LUiqjfX7JQEB/P4D+we6e8+QVJnyYWSWHTKEkUgGZFT9y776QmRmQ3RsnupcY/lh dl9qwl6IQHdo50CXRghRPukPMz+rU204pKCJLENIWz+cRSHyqdy8nsstOjM4dgoq WB8h0QchlNavm0LAmKLTCKgJ7WlnGFxHY+ngeqVMbHpbxR/UUAFf3DyYLiTpiQCV AgUQKtC8BHnZyJYYHcXVAQFqNwP/cktczkLkRwlce+4c7rwvn7nvuuI5gPVlsOdG LpqtnJ6cEgOPYgzHqW8tQrTecfUTm1TTtVKknwEP5YDxCYDcjlvM31n/S7fr4BeQ S/uatCxDqho/8kFFbOW4c6fetV3lag0pROxXWlCGYIYJ9dzRViSvvlS4UCHmPbNw mUdXG1iJAJUCBRAqzWPKGFfk3bG2uCMBASKOA/41iPyVsZbigbE043TQc2O/XTMd eqyy7P6O7fwE/Q+h5Qthl0pd1SeO3krxqjaXLgjZ07pIsb/+6nhU8UkfCEuFdW9Y E7ucOIYH2TSnASvv0WA57xbNluPVbui8gBRtrqpoFd9qIynPbhCxuwsqON7tinww RAygidEyvG4lVVeEq4kAlQIFECrNNyttbThSc0uaWQEB0AAEAIE9A80ah78d5T73 ZmHvHluXjMYBi96N07ix9/wPGa5moEoArV1UL8OZ/OsVXTALH58Pp48m6A96Dz1r H+uel6Jlu9NyRRNVzw4kXv5dYC8/ou7K7hvgB61ugAxtS7PzzjFrotd9IUDd/bkm P94lZ0XeFkE3wPlMN1Jlkot5k2X0mQCNAirGZZEAAAEEAL6UcTrYPKFcQjTs1vTb xGqN1t3WvF2x9N8ZrPfIKwThfPPppUXkCl6Gz0Y/kfu9WbhDoiBnMKIrvXTtsW+h 0f2Lm8Et9RrtMBR9G+CNpIPs+lJNZ9js8rIujX7uanBt/VK/Z0hwdIrzJ8YBEafV 6KJg3lHmfutndxhX5N2xtrgjAAURtDRHSyBQYWNlICBbMTozNzQvMjYgPGdrcGFj ZUBmMjYubjM3NC56MS5maWRvbmV0Lm9yZz5diQCVAgUQKs3JC21tOFJzS5pZAQHy JAQAlMgaSBlNourM5deAGSrgqbinr/T/0nNKCfPpZ3SwKe27No+NEbFmHCpPPjrN SVJoGDN1p8ePSnZdvuqb94cJCGwkdHBWd2c0xAjU4zUY7G+ddogmXfE/7mGdWtXL 7Xtga0vpDZdQ2AubKKCRntaXGNzrqP/5e6csUAhUHd5VLLOZAI0CKrDAUAAAAQQA tjl87QTiBTb4jkruf5IgK7Ig01Saj/PZQu8ruZTbkJbXqkb9RN7q2bbG8RLYjJxc EzCR6a9atG7NNteSuQf4/yu52MxmqIF0BikLD3vqtxMSLKYQpGdXjjAS3T4NhBj4 Z7QS3cijYnWpiMmhHb0egsVV1S3hOnIIZitHZ+yaIMEABRG0K0FyamVuIEcuIExl bnR6IChMRU5UWiBTT0ZUV0FSRS1ERVZFTE9QTUVOVCmZAI0CKm3yLAAAAQQAsYqA tuURAJ9xkSJD6MEWfDmDQH6jXoYw+yxgEojttaCMZsEOqeRCgwZqA0mlwbm1fZsq kl16CLTVKnbZA4yllt2u/8pdFYen8mOs0sBken0H6eWixtGs8uEZlkD86DJToPYa wacwNxNpw8PjfCjWD5FSkO/5SMyv4nXeDv9n9wsABRG0LFBoaWxpcCBSLiBaaW1t ZXJtYW5uIDxwcnpAc2FnZS5jZ2QudWNhci5lZHU+iQCUAgUQKs04AW1tOFJzS5pZ AQErqQP4zrYEvXhV77y90m2Vew8ZbDD/pxSpVWwgM16uU7CBVlAvMqTs/24qT3qJ 4Pcl2K6P1gCVj0Y+m4PFO07UYEm5UX00BYEZxiFFT4w5CO/4BJfrIu3oIdaadSYx dBz1uJYZouoE+kEvd35tIppVPXuGLRXdeojXuw/VOGUYgV9aU4kAlQIFECpvUjT0 ygCBjeci2QEBOfsEAL90+6LOAaROuDLyKKvcG8yTSg/HbkRUrpYsX8ya2O9NRvr2 sLx1zehE5/nRUKI1Tk2pzp5J94qaS50mjlW+a7Kf5tMz9JVpDPeU8Y3k7+Pnb+DG 4lhXBkyUvV3AiqK3x89ZW/jRozIHM+JdT7gyUQ3Vtf2P/4zTvlHyocusmGIgmQCN AipswZkAAAEEAMrcqvIwyKcvxWjFbUIq7/hhzWTrpeThdIxJl7T6P1sX9U6axBhS a1qE8LxwzTZ7/fhqaUlcZbrho5WODDqge325k7c2DCiIGxG+awndQR7a6X28/U05 aQXQiMnS+IgDOLo6gCtGUFoLDoUob5AuljqHlOrQovmoIPTKAIGN5yLZAAURtCdC cmFua28gTGFua2VzdGVyICA8bGFua2VzdGVAZndpLnV2YS5ubD6JAJUCBRAqbfKQ 4nXeDv9n9wsBAcIXA/9w7xBNQn8sTkmfBy6S6tFk7GFGHvQA/9eryxHlqjDDhBKQ eSJJGvPHmNQQ32CnVuv6M54qxT9iusopMv1RFS4ZXTB9u5KV4ajBGvkGfMsHLYgi AEcdUwndShAm6St/zRoJzQ3ae0mAFk9MYJKYcMuJYL3wCZjrrI5YNrrhSO52w5kA jQIqezKiAAABBADWbUO71XAVqN9dlef3kGRtlsSA9gnOkoRCzVlo4hFvO792Ie/Y 1p/c5pz2YAyU+9C0beZHVWHwofAdUmdpF3iz2q+4viODLN2UbD2E7hoPjm3HLLjg iRCKy7lBjtEofLm0TU2mSuAZOR4zKaNcCRcRcSCYtAiJZA/6EarpnZl9RwAFEbQl UGV0ZXIgR3V0bWFubiA8cGd1dDFAY3MuYXVrdW5pLmFjLm56PokAlQIFECqkeZfi dd4O/2f3CwEBrsYD/AqgSbc7d3qYO5Gww2MxZX4gA04nzHbyx3XnX6xWUOU6w+Rx /X/00hP42og+P3Rf+pBg0y4KiIe7hY2TOb6neh3qpcpxkHQKtUkRQd6zYFNRuYoR NTgeusTiiAv0cL6RYaZFWt44RzbOr3tJZrz3uPHLz2nvDvec4zPHvMoWyeVFmQBN AiqKPnYAAAECAM4DUPnxdjb43Il+yDkRUO8TgzOW/hjTs1/blllrVe8HDlABqHZM ib0aNFhKRFYjvsNS3xk34N65vtlI/HoTNvUABRG0IUhhcnJ5IEJ1c2ggPEhhcnJ5 QGNhc3RsZS5yaWdhLmx2PokAlQIFECqmFtb0ygCBjeci2QEBqVwD/A/8vnke2KFN yFLTOdYhiAZlbpPuo621TIYWVxPJ+D+TVkELdn7HWmDpDGQ8l/7XmuDEBrGjFiQj 1Mv67+rnEqhA4ufKyKS57GuSZ90G99iLLimCiA9ytQyRz8Wi8GUzh2lpv7/478Nv xEgya3nVM6LwkXodv4OYPVxUnLoSNFGFmQBNAiqc8q0AAAEB/i6Q/XxMaNqWP1tY 4D8vHr5KiwFz1XvE9F5ltPVPeW2I0EORg6u7xSlreXo9OvRd0BbF+UdOAjH7Pwvh v9xiBCMABRG0IkplYW4tbG91cCBHYWlsbHkgPGpsb3VwQGNob3J1cy5mcj6JAJUC BRAqp3Bp9MoAgY3nItkBAegyA/sEwCWN7IU1T0NVNkcOcqe+lCn8P42UfX1RUKqC fErqT51BAPnSIz0naWFQII8ZE41FQQ6iuKnbfKpmIi4VelzcjzsEwdw15cdnyV8O 9FXQ25ysMe1C6LkodMU20XMjH7744n0NG15PWbNcmwNOQ2119tw+u9rRuuC6PFWF vX0wVZkATQIqxyFfAAABAgDhOocrwWVLJVToItdrune/+sjCF1+GiiEXH1d8Gv8r B5frpXeGoAtWFvmIpmHgPv21zgcR/2Pykc0/7S71JXEXAAURtDFUb20gSmVubmlu Z3MgPHRvbWpAZmlkb3N3LmZpZG9uZXQub3JnLCAxOjEyNS8xMTE+iQCVAgUQKtDh Nm1tOFJzS5pZAQGRrAP+PVrIqMEPeiAmt/K9gjW2xWOVQar5X7v++C/8BqIYj8mm mGddvQa098te5C1OyunMTK0XtFz7kIvcDJhfKzmp+rdI6TfGURvasmirRFAPxPd9 +lJcIQyInHiRDARFub1xGOQ+Q1ndXsaX1f0O93vz/kjXY0SoC8IURY0OFhPF1paJ AJUCBRAqy4RiGFfk3bG2uCMBAaH+A/9S3C84z9CK/NLl1Tczz2hxG6R4C41pwPPR 49LX1wNDafec1RyhDUPVP37kc+Rtu6xxZsvsAk19s7KwwYE5Sp+IRsDk8+Qg3545 wfDVUNfV7fShf7ZW3tZY2ybZp3GP3TzH8JFpQjxRy1z1sNyIhZSaNYUb8awDN+uM mt8zU1SbDw== =TN0Q -----END PGP PUBLIC KEY BLOCK----- --- ReadMail * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Sun, 25 Oct 92 13:08:18 PPE To: cypherpunks@toad.com Subject: re: Re: pgp key distribution Message-ID: <3270.2AEAFD74@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain U> From: shipley@tfs.COM (Peter Shipley) U> I maintain two public rings one is a collection I have U> collected via direct contact (friends mostly) the other is U> jyanowitz's list plus random other rings). I'm surprised by the number of people who, when they receive a key in the mail, certify it themselves. I leave mine also uncertified unless I got it directly. I don't sign nuttin. --- ReadMail * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Sun, 25 Oct 92 13:08:19 PPE To: cypherpunks@toad.com Subject: re: pgp key distribution Message-ID: <3271.2AEAFD74@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain U> From: pmetzger@shearson.com (Perry E. Metzger) U> for the life of me understand why. The only way to know U> for sure that someone's key is theirs is a signature from U> a trusted introducer anyway, so people can just ask each U> other in clear for public keys and it doesn't do a lick of I think it is valuable for a number of reasons, none of which are traditional encryption reasons. One: Mostly, in my world, I don't need SECURITY, I need PRIVACY. A paper envelope sealed with water-soluble glue is just fine. It stops casual snoops, like the lock on your car door does. None of which will stop a determined thief, but like Eric says, it's economics -- this level of security is inexpensive as hell. Two: it gets people introduced to the very basic concept that there *is* privacy (security) available, and possible. In the FidoNet, and the BBS world, this is important. Three: In FidoNet, we've got 16,000 sysops, doubling every 18 months, worldwide. Traditional key systems are not only wildly impractical, they're unnecessary for traditional reasons -- who much security to I need to talk to someone 5,000 miles away I've never met? Four: If I need *real* security, I will (or better!) obtain keys in "traditional", secure ways. I can plug these keys into my casual privacy system, which will hopefully encompass the technological mechanisms of en/decryption, signing, plaintext handling, and all the assorted baggage we'll have to drag around anyways. Five: it will entrench some disasters; bum, or faked keys, humongous duplicates, inexperienced people forgetting their secret pass phrases so they can't even issue key-removal certificates (this has happened already; its a MAJOR pain in the ass), one "person" with a zillion IDs, inconsistent IDing, etc etc etc etc etc. Oh well. In fact, no system gets implemented right. Period. To pretend it will is folly. Because of the nature of the beast (patents, feds looking for backdoors, stupidity, centralist, authoritarian types trying to exert control, etc, I'm pushing, hard and fast, to get systems set up LIKE CRAZY of all sorts, with all of them being completely distributed and decentralized. Sufficiently Paranoid. --- ReadMail * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nathanf@cup.portal.com Date: Sun, 25 Oct 92 16:21:58 PPE To: cypherpunks@toad.com Subject: Removal from list Message-ID: <9210251610.1.16692@cup.portal.com> MIME-Version: 1.0 Content-Type: text/plain Please remove me from the list. My address is nathanf@cup.portal.com Thank you. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Sun, 25 Oct 92 20:10:41 PPE To: cypherpunks@toad.com Subject: Registering Keys with Big Brother Message-ID: <9210260209.AA18958@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Arise, cypherpunks, evil plans are brewing in the bowels of the Beast! I just read a summary of influential crypto guru Dorothy Denning's talk at the recent 15th National Computer Security Conference (held in Baltimore, don't you know, so con-vee-nient to Fort Meade). See the recent RISKS articles in comp.risks (esp. 13.86). Since RISKS is copyrighted, and we wouldn't to do anything to make the lawscums unhappy, I'll summarize: * Denning proposes that anyone using public key encryption over public networks be required to register their private keys with, for example, the Justice Department. * To avoid the risks of someone else getting the key, she suggests the private keys could be encrypted with the _public key_ of Justice, and then held by an independent agency. (Ostensibly, the encryption and registration could be done by the user himself, though some means of verifying compliance would have to be devised.) * To make use of the private key (for example, to read e-mail encrypted with the key), the government would have to get a court order, present it to the independent agency, take the key back to Justice, decrypt it with the private key of Justice, and then proceed with their surveillance and whatnot. This is ostensibly like the procedure for wiretapping. However, it would screw up the use of encryption in many ways. Registering a key would precluded frequent key changes, would probably cost some fee (on the order of $50, like a driver's license, I'd guess), and would of course greatly complicate the use of digital pseudonyms and all the other neat stuff we've talked about (but which caution tells me not to discuss here on an open and unsecured list...you can check my .sig to see where I stand, of course). My hunch is that Denning and the other "quaint" (cf. Sterling's "The Hacker Crackdown" for a description of how the crypto bigwigs interact with hackers at CFP and elsewhere) cryptheads have alerted the government to the _real_ threat of cryto tools. Position papers are being released as trial balloons, to prepare the way for a "Crypto Crackdown." I hope I'm wrong. We need more information. Let's talk to someone who went to this conference and get the Proceedings as quickly as possible. Cryptically Yours, --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP 2.0 and MailSafe keys by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hollander Date: Sun, 25 Oct 92 21:29:49 PPE To: Eric Hughes Subject: Re: BBS E-mail policy In-Reply-To: <9210230601.AA26160@soda.berkeley.edu> Message-ID: <9210260429.AA29646@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Re: entropy I seem to remember that English text is about 1.5 bits per character. I can find a reference if you're interested. e From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hollander Date: Sun, 25 Oct 92 21:41:19 PPE To: Eric Hughes Subject: Re: entropy measures In-Reply-To: <9210240620.AA08036@soda.berkeley.edu> Message-ID: <9210260440.AA00199@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain >uuencoding will have a slightly lower single-character entropy than >the ASCII armor PGP uses because just about every line begins with the >letter 'M'. This will skew the distribution slightly. But a better >way of distinguishing uuencoding and ascii armor is to see that in >falls in the same entropy class, and then just looking at the >alphabetic subsets used. It's not that simple. The entropy of a byte is the number of bits needed to represent it. If what is uuencoded is extremely repetitive, the entropy will be low, maybe even less than one. On the other hand, if it were random data, it would just be slightly lower than ascii armor. Binaries are somewhat repetitive, so they have somewhat less entropy than random data. English has a lot of redundancy, so it has a low entropy. e From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Sun, 25 Oct 92 23:32:00 PPE To: cypherpunks@toad.com Subject: Alpha Particles and One Time Pads Message-ID: <9210260530.AA00679@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Fellow Cypherpunks, Here's a posting I just sent to sci.crypt, dealing with using alpha particle sources as noise sources for generating one-time pads. Ordinarily I wouldn't bother you folks with this, especially since you're all reading sci.crypt (aren't you? Only the FidoNetters have a good excuse not to.). But this thread ties together two aspects of my life, cryptography and alpha particle errors in chips. --Tim Newsgroups: sci.crypt Path: netcom.com!tcmay From: tcmay@netcom.com (Timothy C. May) Subject: Re: Hardware random number generators compatible with PCs? Message-ID: <1992Oct26.051612.29869@netcom.com> Organization: Netcom - Online Communication Services (408 241-9760 guest) X-Newsreader: Tin 1.1 PL5 References: <1992Oct25.224554.1853@fasttech.com> Date: Mon, 26 Oct 1992 05:16:12 GMT Bohdan Tashchuk (zeke@fasttech.com) wrote: : The recent post on building a random number generator using a zener diode got : me to thinking once again about commercial alternatives. : : I haven't seen any commercial alternatives discussed here recently. And since : the market is so specialized, they may well exist but I'm simply not aware of : them. : : The ideal product would have the following features: : : * cost less than $100 : * use a radioactive Alpha ray emitter as the source It's a small world! In my earlier incarnation as a physicist for Intel, I discovered the alpha particle "soft error" effect in memory chips. By 1976 chips, especially dynamic RAMs, were storing less than half a million electrons as the difference between a "1" and a "0". A several MeV alpha could generate more than a million electron-hole pairs, thus flipping some bits. (Obviously the effect of alphas on particle detectors was known, and smoke detectors were in wide use, but nobody prior to 1977 knew that memory bits could be flipped by alphas, coming from uranium and thorium in the package materials. It's a long story, so I won't say any more about it here.) : * connect to an IBM PC serial or parallel port : * be "dongle" sized, ie be able to plug directly onto the port, and : not have a cable from an external box to the port : * be powered directly from the port : * generate at least 1000 "highly random" bits per second This should be feasible by placing a small (sub-microcurie) amount of Americium-241 on a small DRAM chip that is known to be alpha-sensitive (and not all of them are, due to processing tricks). Errors would occur at random intervals, depending on which bits got hit. Getting 1000 errors a second would be tough, though, as such high intensities would also tend to eventually destroy the chip (through longterm damage to the silicon, threshold voltage shifts, etc.). If you really want to pursue this seriously, I can help with the calculations, etc. : Details: : : Certainly in high volume these things can be made cheaply. Smoke detectors : often sell for under $10, and have a radioactive source, an IC, a case, etc. Yes, but smoke detectors use ionization in a chamber (the smoke from a fire makes ionization easier). That is, no real ICs. But ICs, and even RAM chips, are cheap, so your $10 figure is almost certainly in the ballpark. A bigger concern is safety, or the _perceived_ safety. Smoke detectors have, I understand, moved away from alpha particle-based detectors to photoelectric detectors (smoke obscures beam of light). Don't underestimate the public's fear of radioactivity, even at low levels. : Using a well-designed circuit based on Alpha decay should mean that the : randomness is pretty darn good. But not necessarily any better than noise from a Zener. With the higher bit rate from diode noise, more statistical tricks can be done. The relatively low bit rate from alpha decay gives less flexibility. On the other hand, alpha hits are undeniably quite random, with essentially no way to skew the odds (unlike with diode noise). : Everyone these days has either a serial or parallel port available, either : directly or thru a switch box. : : The tiny "dongle" size is a convenience. If it is small and powered directly : from the port, there are no cables to get in the way. There is enough power : available from the signal lines on these ports to power simple devices. E.g. : most mice don't require an external power supply. : : For most applications 1000 bits per second should be adequate. For example, : it would be quite adequate for session keys. For generating pseudo : one-time-pads, an overnight run should generate plenty of values. Continuously : generating values for a month would produce about 300 MB, which should be : enough to exchange new CD-ROM key disks once a month. One time pads are complicated to use. Only very high security applications that can also afford them use them. For example, some diplomatic traffic. I can't conceive of a case where 300 MB a month could be used. And _theft_ (or copying) of the CD-ROM one time pads has got to be a much bigger issue that whether alpha particle noise sources are better than diode noise sources! By about 10 orders of magnitude I would say. Black bag jobs on the sites holding the keys will be the likeliest attack, not trying to analyze how random the noise is (even a fairly crummy noise source will not yield enough information to a cryptanalyst trying to break a one-time pad). Having said all this, I'm glad you gave some thought to alphas. For a time in the late 1970s this was the chip industry's number one headache...it was definitely the most exciting time of my life. --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP 2.0 and MailSafe keys by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Mon, 26 Oct 92 01:54:38 PPE To: tcmay@netcom.com Subject: Re: Registering Keys with Big Brother Message-ID: <199210260853.AA20086@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Tim's summary of Denning raises some interesting points, and no doubt this will end up in the courts in due time. Some angles of attack which might be pursued include 2nd amendment (original grounds: protection against tyrrany) and 1st amendment. Re the latter, a lawyer I spoke with some years ago, proposed the idea that freedom of speech in some cases depends on the ability for the speaker to determine who will and who will not receive what is said. Then of course there is always good oldfashioned civil disobedience. If enough people conscientiously violate the regulation, it will become unenforceable and all the more likely to be overturned. -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: efrem@spitha.informix.com (Efrem Lipkin) Date: Mon, 26 Oct 92 03:52:20 PPE To: cypherpunks@toad.com Subject: Re: Registering Keys with Big Brother Message-ID: <9210261016.AA15135@spitha.informix.com> MIME-Version: 1.0 Content-Type: text/plain It seems that registration would defeat the advantage of a public key system, but it would not prevent private encrypted messages from being hidden from casual traffic analysis or even notice by public key wrapping. This would make registration rather useless against a conspiracy and thus hard to justify in the face of commercial and constitutional opposition. --efrem From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: marc@kg6kf.ampr.org (Marc de Groot - KG6KF) Date: Mon, 26 Oct 92 03:44:55 PPE To: cypherpunks@toad.com Subject: Re: Alpha Particles and One Time Pads Message-ID: <9210261024.AA11069@kg6kf.ampr.org> MIME-Version: 1.0 Content-Type: text/plain Tim May sez: Here's a posting I just sent to sci.crypt, dealing with using alpha particle sources as noise sources for generating one-time pads. Tim, Why not use a back-biased germanium diode, or other noisy semiconductor junction? Seriously, the NRC has allowed the smoke detector people to spread those little radioactive chunks of Americium for too long. John Walker of AutoDesk actually built an IBM-PC card that generated random numbers from a radioactive source. All the best, ^M From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Mon, 26 Oct 92 08:55:04 PPE To: cypherpunks@toad.com Subject: entropy In-Reply-To: <9210260429.AA29646@soda.berkeley.edu> Message-ID: <9210261554.AA11701@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Re: entropy Eric Hollander writes: >I seem to remember that English text is about 1.5 bits per character. I can >find a reference if you're interested. There are lots of entropies available to measure. There is "true" entropy, the lower bound for all other entropy measures. This is the compressibility limit. The entropy I was referring to was simply the single character entropy. That is, the probabilities p_i in the entropy expression are the probabilities that a given single character appear in the text. This will be higher than the true entropy. Shannon's estimate for H_1 was 4.03 bits/character. This assumes a 27 character alphabet. The entropy for ASCII-represented English will be higher because of punctuation and capitals. The true entropy of English is much lower than this, of course. But for an simple measure to automatically distinguish between plaintext and ciphertext, it should suffice. Re: uuencoding. In my analysis before I assume that the uuencoding would be of random data. If it is not from random data, then the entropy will be lower. Thanks for the clarification. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Mon, 26 Oct 92 09:38:01 PPE To: cypherpunks@toad.com Subject: Registering Keys with Big Brother In-Reply-To: <199210260853.AA20086@well.sf.ca.us> Message-ID: <9210261637.AA12485@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Re: Some angles of attack George: >2nd amendment (original grounds: protection against tyrrany) I've thought for a year or so now that if the State Department was going to class cryptography as munitions, then they have _de jure_ acknowledged that civilian use of cryptography is protected under the Second Amendment. Cryptography is not a weapon and should not be restricted for public safety reasons. >1st amendment. Re the latter, a lawyer I spoke with some years ago, >proposed the idea that freedom of speech in some cases depends on the >ability for the speaker to determine who will and who will not >receive what is said. This criterion may be valid, but I don't think it's needed. As I understand it, the restrictions on speech that do exist restrict 1) certain contents, not speech as such, and 2) speech which is public, not private. Encrypted text, by the fact that it is encrypted, is intended to be removed from the public domain. And restricting the transmission of encrypted text based on some assumed content is prior restraint. I'm not sure that any of these arguments really touch a key registration proposal, unfortunately. Guns may be sold, but also registered. It is not the speech that is restricted, but the privacy from the Justice Dept. which is restricted. What I suspect may be more effective is to argue, based on the Tenth (or Ninth? I get them confused) Amendment, that the Federal Government has not been granted specific power to require the registration of key material under any of its other powers. >Then of course there is always good oldfashioned civil disobedience. But the percentage of users of cryptography for communications is a small percentage of the total population as of yet. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Mon, 26 Oct 92 09:40:33 PPE To: cypherpunks@toad.com Subject: Registering Keys with Big Brother In-Reply-To: <9210261016.AA15135@spitha.informix.com> Message-ID: <9210261640.AA12615@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain >It seems that registration would defeat the advantage >of a public key system, but it would not prevent private >encrypted messages from being hidden from casual traffic >analysis or even notice by public key wrapping. Sounds like a recipe for selective enforcement, doesn't it? Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Mon, 26 Oct 92 09:53:38 PPE To: cypherpunks@toad.com Subject: entropy In-Reply-To: <921024155350_74076.1041_DHJ67-1@CompuServe.COM> Message-ID: <9210261653.AA13072@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Hal: >Ascii encoding used by PGP reduces this to 6 bits per character >(e.g. a character set with 64 printable characters) neglecting >line separators and message beginnings and endings. So there >should be a little less than 6 bits per character for encrypted, >Ascii-encoded messages. Hal is, of course, right. I was getting myself confused between entropy lost in the encoding and the entropy of the encoding. The channel uses up two bits of entropy per character in the encoding. What's left is six bits. As punishment for getting this so egregiously wrong, I'm going to post some C code for measuring entropy so that you all can play with it. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Mon, 26 Oct 92 11:22:35 PPE To: cypherpunks@toad.com Subject: (fwd) A Trial Balloon to Ban Encryption? Message-ID: <9210261819.AA07688@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Fellow Cypherpunks, I have rewritten my posting on Denning's proposal and posted it to sci.crypt, for wider discussion. I'm surprised the sci.crypt folks had not already the significance. You might want to consider debating the issue there, rather than on this list, as your words will then be heard by more folks and could mobilize an effort against proposal like this one of Denning's. Cryptically your, --Tim Newsgroups: sci.crypt Path: netcom.com!tcmay From: tcmay@netcom.com (Timothy C. May) Subject: A Trial Balloon to Ban Encryption? Message-ID: <1992Oct26.180813.7002@netcom.com> Organization: Netcom - Online Communication Services (408 241-9760 guest) X-Newsreader: Tin 1.1 PL5 Date: Mon, 26 Oct 1992 18:08:13 GMT Is there a trial balloon being floated to effectively ban encryption? Noted and influential influential crypto advisor Dorothy Denning has apparently floated the idea of _public key registration_ in a paper or talk at the 15th Computer Security Conference in Baltimore, held recently. Discussion of this is in comp.risks ("RISKS"), so far, but certainly belongs in this group. I posted a summary of this position to a private mailing list devoted to crypto issues and got a huge response of concerned folks. I don't understand why this is not a hot topic on sci.crypt, so I'll post something right now. Here's my understanding of her proposal: * Anyone using public key cryptography would be required to register the private key with the appropriate authorities, for example, the Justice Department. * To head off the obvious concerns about the government routinely reading e-mail, financial dealings, etc., this registered key would be stored at an independent agency after first being encrypted with the _public key_ of Justice. (That is, the independent key storage agency would have an unusable key, so _they_ couldn't use it themselves.) * To obtain a usable form of the private key, Justice would have to get a valid court order, go to the independent storage agency, present the order, pick up the key, open it with their own _private key_, and proceed to open mail, read communications, etc. This is ostensibly the procedure now used for wiretaps. But the effect on encryption would be chilling: -would greatly complicate the rapid changing of keys -would probably be a way to get "unlicensed" crypto programs off the market (e.g., don't think about using PGP 2.0, as the key registration authorities would either insist on another algorithm, or would send the "registration application" to, for example, RSA Data Security for legal action) -would undoubtedly require a "fee" (like a driver's license) -would interfere with the use of digital pseudonyms, anonymous nets (a la Chaum's "DC Net" proposal, which some of us are exploring now), and digital money -would establish the precedent that private communications are not legal, that copies of all private communications must be placed in escrow with the government Registering keys is no different than, for example, requiring a permit for every public utterance or for registering typewriters, modems, computers, fax machines, and copiers. Or banning the use of sealed envelopes for mail. In Phil Zimmerman's great words, it would be like requiring all mail to be sent on postcards. My suspicion, which Prof. Denning will presumably comment on if she's reading this, is that the government folks have come to understand the profound implications of modern crypto and are looking for approaches to head off the coming sea changes. Granted, there are serious national security threats in using modern crypto methods, but there are in any of the new technologies, such as those listed above. Besides, does anyone think all keys will be registered? Hiding bits is a relatively easy thing to do. This key registration proposal is more odious than the "backdoors in telecom equipment" proposal discussed here recently. Can we remain silent as our liberties are taken away? I think it was John Gilmore who said: "If encryption is outlawed, only outlaws will have encryption." -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP 2.0 and MailSafe keys by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Hal <74076.1041@CompuServe.COM> Date: Mon, 26 Oct 92 09:23:21 PPE To: CYPHERPUNKS Subject: Registering Keys... Message-ID: <921026155917_74076.1041_DHJ88-1@CompuServe.COM> MIME-Version: 1.0 Content-Type: text/plain This proposal to register keys was also mentioned in the July, 1992 Communications of the ACM, in an article by Ron Rivest, one of the creators of the RSA algorithm. He was mostly criticizing the proposed government Digital Signature Standard, stating that he thought that the NSA was purposely trying to get "weak" cryptography installed as the standard. Then he goes on to say, "Are there technical alternatives that would satisfy all parties? Perhaps. It is certainly the case that the formulation of the problem to be solved has never been made explicit for the cryptographic community to work on. I suspect that a solution based on 'escrowed secret keys' might be workable, wherein each user is legally required to depost his or her secret key with a trusted third party, such as the user's bank. Cryptographic hardware and software would only operate with public keys that were certified to having their corres- ponding secret keys appropriately escrowed. A federal agency could then obtain the secret key, or its use, with an appropriate warrant. Once their secret keys were escrowed, multinational corporations could even operate across borders with a high degree of authentication and privacy (except perhaps from court-ordered wiretaps). Cryptographic hardware and software manufactured in the U.S. would not operate abroad without public keys suitably certified as having their secret counterparts escrowed in the U.S. In an extension of this approach, users can escrow their secret keys with several trusted third parties in a 'secret-sharing' manner, so that no single third party can com- promise the user's key. While this approach may have its own difficulties, it does illustrate that weak cryptography is not the only technical approach available. There may be much better techniques for achieving a compromise between a number of conflicting national concerns." At the time that I read this, I thought it was largely a rhetorical device, making the point that if the government wants to infringe on people's privacy, it should come out in the open and do so, rather than skulking about. (Like saying, "if the government _really_ wants to stop sexual immorality it would have to put a TV camera in every bedroom".) And of course (I thought) this kind of proposal would never be taken seriously. I'm shocked that Denning is now advocating it openly. This proposal makes it illegal for people to communicate so secretly that the government can't find out what they are saying. It could apply to postal mail as well as email - it would be illegal to send a message via post which the government couldn't interpret. If this is really the government's purpose, then it should also require that all private conversations be recorded, and the resulting tapes be "escrowed" similarly in case the government needed to find out what was said, for which it would have to get a court order. As Tim suggested, this is probably a "trial balloon" being floated to see what the reaction is. Let's see that it gets shot down. Hal 74076.1041@compuserve.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Peter Shipley Date: Mon, 26 Oct 92 12:13:42 PPE To: marc@kg6kf.ampr.org (Marc de Groot - KG6KF) Subject: Re: Alpha Particles and One Time Pads In-Reply-To: <9210261024.AA11069@kg6kf.ampr.org> Message-ID: <9210261911.AA12805@edev0.TFS> MIME-Version: 1.0 Content-Type: text/plain >Tim May sez: > Here's a posting I just sent to sci.crypt, dealing with using alpha > particle sources as noise sources for generating one-time pads. > >Tim, >Why not use a back-biased germanium diode, or other noisy semiconductor >junction? Seriously, the NRC has allowed the smoke detector people to >spread those little radioactive chunks of Americium for too long. > >John Walker of AutoDesk actually built an IBM-PC card that generated >random numbers from a radioactive source. Q: how hard/cheap will it to build a shielded rs232 plud with a noisy diode in it to provide a random number source? I have written on a possible random number source for Sun SparcStations (I and II). I have a program programs the audio chip to take input from mic port 2 (which is not used in a SparcStation) then I turn up the gain in the pre-amps and read the data of the from the DtoA. I do not know how random it is yet (if anyone wants to run some tests for me I will be happy to email them the program) -Pete From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Tue, 27 Oct 92 07:10:21 PPE To: cypherpunks@toad.com Subject: re: Re: Registering Keys with Big Brother Message-ID: <3329.2AECDB78@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain U> From: efrem@spitha.informix.com (Efrem Lipkin) U> It seems that registration would defeat the advantage U> of a public key system, but it would not prevent private U> encrypted messages from being hidden from casual traffic U> analysis or even notice by public key wrapping. (Hi Efrem!) Yes but. The ole "chilling effect". Everyone talks about ENCRYPTION and SECURITY, what I want is PRIVACY. You can have privacy today, but if you have to sneak around, if privacy is not the background assumption, it gravely limits your ability to live and act freely. Yes, you will always be able to find co-conspirators, but it would be a weak version of the world in which we could presume privacy to begin with. --- ReadMail * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Mon, 26 Oct 92 10:08:45 PPE To: 74076.1041@compuserve.com Subject: Registering Keys... In-Reply-To: <921026155917_74076.1041_DHJ88-1@CompuServe.COM> Message-ID: <9210261643.AA16936@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: Hal <74076.1041@compuserve.com> >This proposal makes it illegal for people to communicate so secretly >that the government can't find out what they are saying. It could >apply to postal mail as well as email - it would be illegal to send >a message via post which the government couldn't interpret. If this >is really the government's purpose, then it should also require that all >private conversations be recorded, and the resulting tapes be "escrowed" >similarly in case the government needed to find out what was said, >for which it would have to get a court order. >As Tim suggested, this is probably a "trial balloon" being floated to >see what the reaction is. Let's see that it gets shot down. I find it repugnant that we've gone all the way over to the notion that people must actively cooperate with their own enslavement. We'd better start getting organized flames against this idea mobilized. Denning is on the net -- anyone care to start flaming on sci.crypt? Its likely the place that will get the most response in the general community. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Peter Shipley Date: Mon, 26 Oct 92 12:47:45 PPE To: shipley%edev0.Tfs.COM@gateway.Tfs.COM Subject: Re: Alpha Particles and One Time Pads In-Reply-To: <9210260530.AA00679@netcom2.netcom.com> Message-ID: <9210261947.AA13100@edev0.TFS> MIME-Version: 1.0 Content-Type: text/plain why doesn't someone set up a random number source on a internet host avalible on a tcp/udp socket? thus if I want some numbers all I have to do is: telnet random_host rand_port > ./random_data_file the use a pseudo-random generater to select from my random number stream for a unique random number set. -Pete From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Mon, 26 Oct 92 12:58:58 PPE To: cypherpunks@toad.com Subject: entropy, with code Message-ID: <9210261958.AA28999@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain The entropy-calculating code is at the end of this message. I took the opportunity to calculate some sample entropies: entropy.c 5.283772 the source code entropy.asc 6.052222 entropy.c, encrypted and armored entropy.as2 6.012493 entropy.asc, with the wrappers removed entropy.pgp 7.830532 entropy.c, encrypted alone entropy.obj 6.112890 entropy.exe 6.947111 randseed.bin 4.584963 from pgp, 24 bytes long pubring.pgp 7.754017 my public key ring The entropy of the source code is in the high end of the range for English, which is not surprising given the amount of symbols in ordinary C code. The entropy increases with the object and the executable, each of which has less overt structure to it. The entropy of the encrypted and ascii armored source code is within 1% of 6 bits, just as predicted. And with the wrappers removed, it's even closer! The binary version of the encrypted message has the highest entropy of all these tests. In randseed.bin, the entropy is much less than 8. But the length of the file is 24 bytes and log_2 24 = 4.584963, indicating that there are no duplicate bytes in the file. Hence the warning: entropy calculations with small samples _will_ be misleading. Note that the entropy subroutine can be used to calculate the frequencies of any distribution. This will allow all you code-writing cypherpunks to measure bit entropies, digram entropies, etc. Eric ---------------------------------------------------------------- /* entropy.c -- Calculate monogram entropies of standard input. */ #include #include /* This next define is to counteract the foolish C 7.00 runtime mapping * of \x1A to EOF */ #define STUPID_NEWLINE_TRANSLATE 1 #ifdef STUPID_NEWLINE_TRANSLATE #include #include #endif /*--------------------------------------*/ #define NUMBER_OF_BYTES 256 long byte_freq[ NUMBER_OF_BYTES ] ; void main() { int c, verbose = 0 ; unsigned int j ; double entropy( long *, int ) ; #if STUPID_NEWLINE_TRANSLATE _setmode( _fileno( stdin ), _O_BINARY ) ; #endif for ( j = 0 ; j < NUMBER_OF_BYTES ; ++j ) { byte_freq[ j ] = 0 ; } while ( EOF != ( c = getchar() ) ) { ++ byte_freq[ (unsigned int) c ] ; } if ( verbose ) { for ( j = 0 ; j < NUMBER_OF_BYTES ; ++j ) { printf( "%3d=%-3d ", j, byte_freq[ j ] ) ; if ( j % 8 == 7 ) printf( "\n" ) ; } } printf( "%lf\n", entropy( byte_freq, NUMBER_OF_BYTES ) ) ; } /*--------------------------------------*/ /* Calculates the entropy of the distribution given in list v of n elements. * The list v gives counts. v is summed, and frequencies are assigned * as v[i]/sum(v). * * Uses the following definitions and identities: * A = \Sum_{i=0}^{n-1} v_i * p_i = v_i / A * H = \Sum_{i} - p_i \log p_i * = log A - 1/A \Sum_{i} v_i \log v_i * lim_{x \rightarrow 0} x \log x = 0 */ double entropy( long *v, int n ) { double h ; long sum ; int j ; /* first sum the array */ sum = 0 ; for ( j = 0 ; j < n ; ++j ) { sum += v[ j ] ; } /* next calculate the entropy function */ h = 0 ; for ( j = 0 ; j < n ; ++ j ) { /* If the frequency is zero, the entropy contribution is zero */ if ( v[ j ] == 0 ) continue ; h -= v[ j ] * log( v[ j ] ) ; } h /= sum ; h += log( sum ) ; /* Now adjust the base of the logarithm to base 2 */ h /= log( 2 ) ; return h ; } From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Mon, 26 Oct 92 14:09:43 PPE To: shipley@tfs.com Subject: Alpha Particles and One Time Pads In-Reply-To: <9210261947.AA13100@edev0.TFS> Message-ID: <9210262036.AA18923@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: Peter Shipley >why doesn't someone set up a random number source on a internet host >avalible on a tcp/udp socket? thus if I want some numbers all I have to >do is: > telnet random_host rand_port > ./random_data_file >the use a pseudo-random generater to select from my random number stream >for a unique random number set. Consider that most people who want to use their random numbers for cryptographic purposes don't want everyone in the free world able to read them as they pass through the internet... In anycase, there is a CALmos device out there that is fairly easy to use and produces about 20kbits of good random data per second -- not fast enough for many purposes, but far better than nothing. I suspect there are other devices on the market, but I haven't researched it carefully. I can get information on this particular device out to anyone who is willing to design it into a simple to build RS232 interfaceable box to generate random bits. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Arthur Abraham Date: Mon, 26 Oct 92 22:54:33 PPE To: hughes@soda.berkeley.edu Subject: Re: Registering Keys with Big Brother Message-ID: <199210270553.AA26809@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Seems to me that there would be a certain amount of trouble with people registering one private key but communicating with another they had forgotten to register. Bad situation for my large sibling 'cause he wouldn't realize this until after the court order etc. A good solution would be BIG fines for mis-encryption and sampling of messages to make sure they were properly formed -- for our own protection, of course. And if they happened to radomly sample something they didn't like... for instance finding my obviously excessive paranoia.... -a2. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: gnu@cygnus.com Date: Tue, 27 Oct 92 00:24:43 PPE To: Arthur Abraham Subject: Re: Registering Keys with Big Brother In-Reply-To: <199210270553.AA26809@well.sf.ca.us> Message-ID: <9210270724.AA29964@cygnus.com> MIME-Version: 1.0 Content-Type: text/plain Arthur Abrahams incisively notes: > Seems to me that there would be a certain amount of trouble with people > registering one private key but communicating with another they had > forgotten to register. Bad situation for my large sibling 'cause he > wouldn't realize this until after the court order etc. A good solution > would be BIG fines for mis-encryption and sampling of messages... There is no need for sampling of messages. You don't understand the theory of power. Simply make the penalty for encryption without registry, larger than the penalty for any other crime. Then no crime can be hidden behind it. It's like getting Al Capone for income tax evasion; if you investigate someone and they are enforcing privacy on their communications, you can put them in jail for life for that, and can stop worrying about the original suspected offense. John From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Tue, 27 Oct 92 06:25:26 PPE To: cypherpunks@toad.com Subject: re: Registering Keys... Message-ID: <3336.2AED0EE9@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain U> From: 74076.1041@CompuServe.COM (Hal) U> This proposal to register keys was also mentioned in the U> July, 1992 Communications of the ACM, in an article by Ron U> Rivest, one of the creators of the RSA algorithm. He was U> solution based on 'escrowed secret keys' might be U> workable, wherein each user is legally required to depost U> his or her secret key with a trusted third party, such as U> the user's bank. Actually this sounds signifigantly different from what Denning is allegedly proposing. This method is analogous to the way FFL (Federal Firearm License) holders record transactions of gun sales (I have an FFL). FFL holders are required to record, in detail, each transaction based upon gun serial number/description, and to/from addresses (buy/sell). The FFL holder maintains the records; the feds dont' get a copy. If a gun is used in a crime, the feds go to the manufacturer, and follow the audit trail of FFL records to follow that guns travels. This is *completely* different than a centralized gun database, where a hypothetical they can compile cross indices based upon oh say name or address or whatever. The third party escrow method puts the same sort of restraint upon searches. I'm not saying I particulary like the method, it's just that it's qualitatively different. The BATF cannot rummage through the audit trail of FFL records, they can only follow the forward/backward pointers per gun. Rivest seems to imply there could be many, independent key-escrow locations. A hypothetical we could form our own key escrow, and while we'd be subject to whatever the hypothetical they would require for access, we could probably do things ilke inform members of all key accesses/inquiries, etc. In short, it bothers me a lot less than Dennings. --- ReadMail * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: gnu Date: Tue, 27 Oct 92 01:31:25 PPE To: pmetzger@shearson.com Subject: Re: D-H telnet protocol * Cheap secure phones In-Reply-To: <9210221929.AA16268@newsu.shearson.com> Message-ID: <9210270831.AA29372@toad.com> MIME-Version: 1.0 Content-Type: text/plain > > (It doesn't protect against > >active re-routing of the call, e.g. by substituting another machine > >for the BBS, but we could work on that as Phase II.) > I would suggest that it be done during phase one. Spoofing attacks are > very important things to guard against, ... Fine, Perry. You do it. I want to get some "easy" protection out there now. Easy often turns out to be six months of work all by itself. > suggest that the protocol be designed so that it does not reveal the > entities forming the link to outsiders (unless one end should > intentionally advertise who it is... This is the intent. The D-H protocol will not reveal any identifying information, and the rest of what is transacted will be protected under the secret key produced by the D-H protocol. > I am very interested in seeing such a protocol standardized because I > have another use for it -- secure telephones. Given modern DSPs to do > and cheap V.32bis modems, excellent secure voice communications are > feasable. There's a "CELP" standard for voice encoding which you can get from the Feds. They used it as an upgrade in STU-III secure phones. It's Federal Standard 1016. It encodes voice at 4800 bits per second with better quality than any known algorithm under 16,000 bits per second (so says the paper on it). If you give it 16 kbits/sec, it is "toll quality". You can get a free copy of the standard, a "technical information bulletin 92-1" entitled "Details to Assist in Implementation of Fed Standard 1016 CELP", and four floppies full of C and Fortran software that implements it, plus test cases, by requesting it from: Office of the Manager National Communications System Attn: NT 701 S. Court House Road Arlington, VA 22204 +1 703 692 2124 Note that this C and Fortran code doesn't run in realtime on workstations; it requires a DSP. But as the "Implementation Details" paper says: "A high-quality, low power, small-sized voice processor can be constructed for under $200 parts cost in small quantities by adding to one of these [TMS320C31, DSP56001] DSP chips: ROM, 16k words of SRAM, and a Texas Instruments TLC32044 A/D and D/A with filters chip." From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Tue, 27 Oct 92 02:39:00 PPE To: shipley@tfs.COM Subject: Re: Alpha Particles and One Time Pads Message-ID: <199210270938.AA27715@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Re Pete's proposal for an on-net random source which could be accessible to users who would then use a psuedo-random process to select which bits to use in compiling cypher keys: What you'll get will be superencipherment, which is no more secure than the links in the chain. The random stream would be non-secure; and so we're left with the security of the psuedo-random selection process. To analogise somewhat, white noise put through a filter has the characteristics of the filter. Try it with FM static and a graphic equaliser. Now to play devil's advocate here, I wonder if a less-than-perfect physical random source would be acceptable, since the potential domain of decryptions would be large enough that unicity in cryptanalysis would in practice be unattainable. What do you think...? From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: gnu Date: Tue, 27 Oct 92 02:08:56 PPE To: tcmay@netcom.com (Timothy C. May), cypherpunks Subject: Re: A Trial Balloon to Ban Encryption? In-Reply-To: <9210261819.AA07688@netcom2.netcom.com> Message-ID: <9210270908.AA00325@toad.com> MIME-Version: 1.0 Content-Type: text/plain > I think it was John Gilmore who said: "If encryption is outlawed, only > outlaws will have encryption." Maybe. But I like John Perry Barlow's formulation better: "You can have my encryption algorithm when you pry my cold dead fingers from its private key." John From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: hkhenson@cup.portal.com Date: Tue, 27 Oct 92 09:21:45 PPE To: cypherpunks@toad.com Subject: Re: Registering Keys with Big Brother Message-ID: <9210270726.1.5339@cup.portal.com> MIME-Version: 1.0 Content-Type: text/plain One consequence of this proposal would be the capturing of *all* email traffic for (possible) subsequent decryption under a court order. After all, how could you complain? They couldn't read your messages of the last ten years unless they happened to get a court order. Knowing how easy it is to get a pliant judge to issue an order, this would be really chilling. Keith Henson (on the other hand, the media makers would love it.) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: hkhenson@cup.portal.com Date: Tue, 27 Oct 92 09:22:00 PPE To: cypherpunks@toad.com Subject: Re: Registering Keys with Big Brother Message-ID: <9210270747.1.5339@cup.portal.com> MIME-Version: 1.0 Content-Type: text/plain Eric mentioned that this topic sounds like a recipe for selective enforcement. If all traffic were captured for possible subsequent analysis, they could get you for a noise burst on a communication line. Couldn't decrypt that even with your key. Keith From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Tue, 27 Oct 92 09:08:54 PPE To: gnu@toad.com Subject: D-H telnet protocol * Cheap secure phones In-Reply-To: <9210270831.AA29372@toad.com> Message-ID: <9210271539.AA05477@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: gnu@toad.com >> > (It doesn't protect against >> >active re-routing of the call, e.g. by substituting another machine >> >for the BBS, but we could work on that as Phase II.) >> I would suggest that it be done during phase one. Spoofing attacks are >> very important things to guard against, ... >Fine, Perry. You do it. I want to get some "easy" protection out >there now. Easy often turns out to be six months of work all by itself. Why should "hard" be that much more difficult? Looks like an extra few days worth of work if you pull all the public key code from PGP. Admittedly, this would be a big project if one couldn't steal existinc dode, but remember, PGP is copyleft. This whole project is a humungous patent violation anyway, so there is no good reason for not stealing code from PGP. Phil's code is bloody good. Anyway, the "easy" protection is probably the "hardest" part. Getting the encrypted link and drivers running properly is the big deal -- thats the code that will take all the time. Its likely marginal cost to design the protocol "right" from the beginning to make it easy to plug in verification later, and being able to use existing public key code to implement it likely removes most of the sting. All you have to do in order to "fix" things is have both sides public key encrypt their D-H exchanges, and suddenly, you have verification of identity. >> suggest that the protocol be designed so that it does not reveal the >> entities forming the link to outsiders (unless one end should >> intentionally advertise who it is... >This is the intent. The D-H protocol will not reveal any identifying >information, and the rest of what is transacted will be protected under >the secret key produced by the D-H protocol. Ah, but if you want to add in a verification layer, you have to be careful to make sure that you don't reveal too much information in doing the verification. >> I am very interested in seeing such a protocol standardized because I >> have another use for it -- secure telephones. Given modern DSPs to do >> and cheap V.32bis modems, excellent secure voice communications are >> feasable. >There's a "CELP" standard for voice encoding which you can get from >the Feds. Well aware of it; I've got sample source code for CELP and all the rest. However, having a standardized bunch of software for encrypting the link will mean that I have that much less to worry about. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Tue, 27 Oct 92 11:57:12 PPE To: cypherpunks@toad.com Subject: list status Message-ID: <9210271856.AA03357@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain As of today, the list stands at 121 members, at least one of which is a mail gateway. Breakdown of the list by top-level domain: U.S. domains: 42 com 42 edu 1 gov 1 mil 10 org 6 us All other domains: 1 at 3 au 1 ca 1 de 2 il 1 nl 2 no 1 nz 1 pt 1 se 4 uk 1 za Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: clarka@netcom.com (Andrew Clark) Date: Tue, 27 Oct 92 12:37:03 PPE To: cypherpunks@toad.com Subject: Please remove me from the mailing list / thanks Message-ID: <9210271930.AA19861@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain clarka@netcom.com Andrew Clark My ignorance is my own fault. "We have virtual reality today: George Bush lives in it." | Bad cop! "Macs are to computing what television is to journalism." | No donut! Secondary account at aclark@UCSD.EDU -- prefer mail at netcom site. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Tue, 27 Oct 92 13:26:24 PPE To: tenney@netcom.com Subject: Hackers Conference--Crypto Session Message-ID: <9210272023.AA26749@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Glenn Tenney, chairman of the Hackers Conference, has asked me to help put together the crypto session at the Conference next week (6-8 November, Lake Tahoe). I of course agreed....our correspondence is attached below. Sorry if I left off your name in my comments to Glenn ...it seems sometimes that nearly everyone I know has some interest in crypology, privacy, cyberspace, AND is going to Hackers! For those not going to Hackers this year, I'd still like your inputs, and I'll write up some kind of update after it's over, so you'll get some feedback on your ideas. This growing interest in cryptology and the protection of privacy--fanned by the availability of PGP 2.0, the books and articles on hackers and crackdowns by the Feds, the activities of the EFF and CPSR, and by our very own "Cypherpunks" crypto group--should make for an extremely interesting time at Hackers this year. Just about every year at Hackers there's a de facto theme. One year it was hypertext (and Xanadu got started when John Walker of Autodesk met Ted Nelson, Mark Miller, Roger Gregory, and others at Hackers in 1987), another year it was multimedia. Last year it was effectively the EFF, and so on. My hunch is that this year the de facto theme _could_ turn out to be crypto tools and digital protection of privacy. In addition to our session, there will be discussions of wireless communication, the work of the EFF, and a Sunday discussion of these critical issues. These will all fit nicely with our own session. Our session is in "prime time," mid-Saturday afternoon, tentatively (you all know how schedules change!), and is one of the "no competitors" tracks, so attendance should be very high. Accordingly, some premium should be placed on organization, to maximize the information flow. Too many people for the "circle discussion" that worked so well at last year's nanotechnology session (run by Ted Kaehler), so we need to figure out a good format. So give me your inputs! (Also, I think we should get togther informally Friday to bounce ideas around, the better to make the session on Saturday richer and more exciting. I'll let you know in the next several days what we decide, and where we'll meet.) * What topics need to be discussed the most? * What format? Panel discussion? A series of mini-lectures on the various topics? Free-for-all discussion? (Remember that we'll probably be in a big room, with perhaps as many as 100-150 attendees.) * Some ideas for topics (which I'll add to as people make suggestions): - A very brief review of modern cryptology (very brief because we need to move on quickly to the juicy stuff), including snapshot summaries of encryption, RSA (but no number theory!), anonymous mail, digital cash, etc. (Too many crypto panels spend the entire time bringing people up to speed on what prime numbers are, on how one-time pads are used, and so on. I favor giving people a good glimpse of the "exciting" stuff--anonymous mail, digital pseudonyms, information markets, dining cryptographers protocols, etc.--and then letting them go back and fill in the background. Give 'em a glimpse of the Promised Land.) - The uses of digital remailers to protect privacy, and progress on building them (a brief summary) - Possible summary of the "Crypto Anarchy Game" we've been experimenting with here in our Cypherpunks group (Note: we could describe it briefly and then invite folks to play it later that evening, perhaps around midnight) - PGP 2.0...what it is, how to get it, and how to use it - Proposed legislation for trapdoors in telephone equipment, and the possibility that crypto keys may be placed under strict controls (a la my recent post on Dorothy Denning's latest trial balloon) - What we can do about these trends, what we as hackers can do to protect our privacy. Things like: deploying encrypted e-mail as quickly as possible, using digital pseuodonyms, deploying "mixes," arguing for basic constitutional protections, etc. Ideally, people will get so worked up and excited that the rest of the Conference will be buzzing about these issues! Here's Glenn's message to me and my acceptance: > > Considering your keen interest in cryptography, I was > > wondering if you could have your arm twisted to help > > pull together the crypto session for the conference? > > > > It should be fairly easy... Let's see, Eric Hughes will > > be there, as will a couple of guys from BellCore (Sternetta > > and ... ??? ). > > > > If so, plesae let me know and I'll pass on some more names. > > > > Thanks much. > > Glenn Tenney > > Of course I'll help. Anything needed, including what you suggest. > > I'm in regular contact with Eric Hughes, John Gilmore, Fen LaBalme, > Hugh Daniel, Keith Henson, and others. I also know Stu Haber, from > Bellcore...if he could speak briefly about digital timestamping of > documents (and Internet mail applicaitions) that would be timely. > > So I'll so whatever I can. > > BTW, I'll forward my latest posting from sci.crypt about proposals to > require all crypto keys to be registered with the government! That, > alone, is worth of a "hacker politics" discussion at Hackers. > > --Tim (408-688-5409) .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP 2.0 and MailSafe keys by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Tue, 27 Oct 92 13:24:00 PPE To: hughes@soda.berkeley.edu Subject: list status In-Reply-To: <9210271856.AA03357@soda.berkeley.edu> Message-ID: <9210271954.AA07709@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: Eric Hughes >Breakdown of the list by top-level domain: >U.S. domains: > 42 com > 42 edu > 1 gov > 1 mil > 10 org > 6 us Hmm... Wonder who Mr. .gov and Mr. .mil are... (1/2 :-) Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: gnu@cygnus.com Date: Tue, 27 Oct 92 19:17:46 PPE To: cypherpunks@toad.com Subject: Re: D-H telnet protocol In-Reply-To: <9210271539.AA05477@newsu.shearson.com> Message-ID: <9210280200.AA24003@cygnus.com> MIME-Version: 1.0 Content-Type: text/plain > Why should "hard" be that much more difficult? Looks like an extra few > days worth of work if you pull all the public key code from PGP. The project as I plan it, would require no administration on the part of users. Install and forget. If you add authentication, then end-users have keys to deal with, on an ongoing basis. As I said before, you're free to take what I come up with and add authentication. But stop berating me in public for doing something to further the use of cryptography. > This whole project is a humungous > patent violation anyway, so there is no good reason for not stealing > code from PGP. You have made two bad assumptions here. I do not intend to violate any patents, nor do I intend to steal code from PGP. I'll be glad to talk in private about what is happening, but it is not ready for public discussion yet. > All you have to do in order to "fix" things is have both sides public > key encrypt their D-H exchanges, and suddenly, you have verification > of identity. This is not true. I have a preprint of a paper by Whit Diffie that explains how to weave D-H and RSA together so that you can't accept the authentication but be spoofed on the key exchange, or vice verse. It starts with a simple protocol as described above. Known attacks are explained and the protocol is modified to deal with them. The result is now in use in commercial products (secure phones). It's not as simple as it looks. John Gilmore From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nobody@soda.berkeley.edu Date: Tue, 27 Oct 92 19:18:01 PPE To: cypherpunks@toad.com Subject: One-time pads and DC Nets Message-ID: <9210280211.AA19676@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Regarding the previous discussion about one-time pads, there is another use for disks full of random numbers. They can be used to implement Chaum's DC-nets. For the degenerate case of just two people communicating, the DC-net is similar to using a one-time pad. However, what you are hiding is not _what_ you are sending, but _who_ is sending it. DC-nets ("DC" stands for "Dining Cryptographers", the example Chaum used to introduce the idea) are designed to hide message sources among some group of people. The people have to be fairly well connected, with near-real-time communications capability. It won't really work for people exchanging email. For the simple two-person case, suppose as in the case of the one-time pad that each person has an identical CD-ROM filled with random bits. What they do is, at some predetermined rate, each person just transmits the bits off his pad. Both people are sending the same bits. When one wants to send a message, he starts toggling certain of his bits. To send a "1" he sends the opposite of the next bit from the one-time pad; to send a zero he sends the correct version of the next bit from the one-time pad. Assuming they don't start transmitting at the same time, what an outside observer will see is that, where before they were both producing exactly the same bits, now they are producing a certain number of opposite bits. Interpreting each opposite bit as a 1, and each case of same bits as a 0, produces a recognizable message. But, the outside observer can't tell which person is sending that message. All he sees is two totally random streams of bits, which disagree at certain spots. Without access to the one-time pads, there is no way for him to tell who is sending. (Of course, the two people involved know who is sending, since one of them is and one of them isn't.) Generalizing to larger numbers of people, you need to have a separate one-time pad shared with each other person in the group. In other words, for a group of N people there has to be a total of N(N-1)/2 one-time pads; each person has N-1 of them. That is, for each pair of people in the group, there is a unique and secret one-time pad which they share. (This is for maximal security - you can get by with fewer pads if you trust each other some.) Now, they all send all the time. What they send is the "XOR" of the next bits of all their N-1 one-time pads. It turns out that if you then "XOR" everybody's output bits, you'll get nothing but zeros as a result. When someone wants to send, he sends the opposite of what he normally would for a "1", and he sends just what he normally would for a "0". Collisions can be handled like ethernet - back off and retransmit. (Chaum had another way involving reserving future blocks of transmit time.) With N people sharing N-1 one-time pads per person, nobody can tell who is transmitting. All anyone knows is whether he himself is transmitting or not; all an outside observer knows is that someone in the group is transmitting. DC-Nets eat up one-time pads even worse than using them for message secrecy does. But, with CD's, you can put a lot of data on a pad. And the system is fairly robust against pads being stolen. If one person's one-time pads are all secretly copied by a spy, then he can tell if that person is sending. But he learns absolutely nothing about which other people are sending. I wonder if it would be possible to experiment with a DC-Net system in the Internet environment. I recently acquired an account on a system with Internet connectivity (I know because I can telnet and ftp from it). I've done considerable programming with Unix socket communication in systems connected by ethernet, and I think the Internet provides a very similar programming interface. It shouldn't be that hard to create a very simple "chat" program in which message sources are strictly anonymous (assuming the existance of the required one-time pad random-number files - for testing, they could be created by random number generators at each end, started with identical seeds). I'll try some experiments along these lines over the next few days. Hal 74076.1041@compuserve.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Tue, 27 Oct 92 17:23:08 PPE To: cypherpunks@toad.com Subject: Threat to our privacy Message-ID: <9210272346.AA11735@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain For Cypherpunks: A copy of mail I just sent to... libernet@dartmouth.edu, extropians@gnu.ai.mit.edu, prz@sage.cgd.ucar.edu, mike@eff.org, mkapor@eff.org [This is being sent out to a wide audiance. If you receive this, its because My friends, its rare of me to try to encourage panic. Occassionally, however, by panicing early we can avert a disaster later on. Risks, an internet mailing list, reported about a week ago on a proposal by Dr. Dorothy Denning, one of the most prominent people in the field of cryptography, that copies of all private encryption keys associated with public key cryptographic systems be held, effectively by the government, to permit them to read people's encrypted messages to each other. Naturally, such invasions of privacy will only be permitted "when a warrant is produced". It has been suggested that this idea might be taken up by several government agencies for "review". Many have noted that the dawning of cheap and effective cryptographic systems could spell the end of the ability of governments to invade people's privacy. Unfortunately, it appears that the government and its cronies have also realized this, and intend to take preemptive action. Our notion of civil rights has decayed so far that it is now considered a citizen's duty to not merely be quiet while he is enslaved but to actively cooperate with his own enslavement. Not merely must we put up with the indignity of the government being granted the right to read our papers and communications to each other, not merely has the FBI attempted to get legislation passed to make phone companies give them easier access to tap phone lines under color of "maintaining the current capability in the presense of new technology", but now it is suggested that we ordinary citizens must personally cooperate to make it easier for them to read our communications. We will be branded criminals if we fail to cooperate, presuming that ideas like this are enacted. It is crucial that the fiends proposing this be convinced that resistance will be too high to implement their plan. It is crucial that before they can even propose legislation that the threat here be brought to the attention of the news media. If the currently proposed FBI legislation were passed, a dictatorial government would have all the tools it would need to tap all the phones in the country -- the only thing restraining that behavior would be a system of warrants that could disappear with a mere change in attitude. If Denning's more serious and sinister idea were proposed for future enactment as legislation (this has not yet been proposed), it would become impossible for individuals to take any action to protect their own communications privacy from a dictatorial regime, even ignoring the question of abuses that could occur right now. I'm convinced that the only thing that prevented the FBI bill from passing this year was the fact that media attention was brought to bear. Its important that this new proposal be exposed to similar sunshine. Far be it for me to suggest restraint of free speech, but I would like to see people think of making such suggestions as having the social acceptability of calling a black person "nigger". Here, for reference, is a copy of an article Dr. Denning just posted to sci.crypt on usenet. I encourage people, rather than discussing this matter on libernet or extropians, to discuss this on sci.crypt where the topic is just breaking. Perry Metzger ---------------------------------------------------------------------- Article 6275 of sci.crypt: Path: shearson.com!uunet!uunet!think.com!sdd.hp.com!zaphod.mps.ohio-state.edu!darwin.sura.net!guvax.acc.georgetown.edu!denning From: denning@guvax.acc.georgetown.edu Newsgroups: sci.crypt Subject: Re: A Trial Balloon on Registered Keys Message-ID: <1992Oct27.143737.1574@guvax.acc.georgetown.edu> Date: 27 Oct 92 14:37:37 -0500 Distribution: world Organization: Georgetown University Lines: 94 The posting about the proposal I made at the NCSC for key registration is essentially correct. Let me add to it the following: 1. The government is not taking any action to curb crypto and is unlikely to take any such action in the near future. No proposal has been made and no government agency that I am aware of has plans to make such a proposal. The closest we've had to a proposal was a "Sense of Congress" resolution in Senate Bill 266 over a year ago. This would not have mandated anything, but said it was the sense of Congress that service providers should provide accesss to the plaintext of encrypted communications under a court order. It got a lot of opposition and was withdrawn. Thus, don't panic folks -- this was just me making a suggestion. I didn't realize I had that much clout to cause such a stir and call to arms! I expect that the next step will be government sponsored discussions about crypto policy, probably sponsored by NIST, at the recommendation of the Computer System Security Advisory Board headed by Willis Ware. That will provide a forum to work through these issues. 2. The reason I made the proposal is because I am concerned that we may be facing a major crisis in law enforcement. I expect many of you will say "that's wonderful" but I don't see it that way. Electronic surveillance has been an essential tool in preventing serious crimes such as terrorist attacks and destabilizing organized crime. The economic benefits alone are estimated to be in the billions. This issue is not about snooping on innocent citizens but about doing what we can do prevent major crimes that could seriously disrupt other liberties. The problem is likely to get even worse if criminals know they use the telecommunications systems without any chance of getting caught. 3. My proposal was to register your private key with a trustee, different from the government. The key would be encrypted under some other public key so the trustee couldn't decrypt it. I have suggested it be the key of the DOJ, but it could be another independent trustee. I believe this would provide acceptably good protection since someone would need to get a court order and then the cooperation of 3 agencies to get at your communications: the telecommunications provider (to get the bit stream), the first trustee (to get the encrypted key), and the second to decrypt it. Experience with the telecom providers has been that they are very fussy about court orders -- you have to get the semicolons right! You can get even more security by using Silvio Micali's "fair public-key cryptosystem" approach. Called "fair" because it is designed to strike a balance between the needs of the Government and those of the citizens. With his approach, you would break your key up into 5 parts and give it to different trustees. All 5 parts are needed to reassemble it, but it is possible to veryify the parts individually and as a whole without putting them together -- ingenious! He presented this at CRYPTO '92. 4. Someone suggested that law enforcement routinely taps without court order. This is an ungrounded claim for which I have never seen any evidence. Regardless, their ability to do this is disappearing with the new digital based technologies. They need the help of the service providers, who in turn ask for court orders. Court orders are not all that easy to get as law enforcers have to document why other approaches have failed etc. 5. Many people have noted that you could not enforce key registration. They may be right, but I am not throwing in the towel yet. Let's take phones, which is what law enforcers are most interested in. Products are emerging that you can attach to your phone and that will do DES encryption. Criminals and everyone else are most likely to use commercial products -- easiest to get and cheapest. The products could be designed so key registration would essentially be part of the sales process. There can be social benefit to government regulation even when regulation is not 100% successful. None of our laws prevent the acts they outlaw. But this does not mean we should get rid of all laws. 6. Some people have said we should not give up our privacy to the government. But the constitution does not give us absolute privacy. We are protected from unreasonable searches and seizures, but not reasonable ones in response to "probable cause" of crime. In all areas of our lives, the government can invade our privacy if they have good reason to believe we are engaged in major criminal activity. They can break into our homes, our safes, and so on. Do we really want a society where electronic communications cannot ever be broken when there is good reason to believe some major threat against society is being planned? Thank you for your comments and for encouraging those on the other news groups to move over to sci.crypt. I'll try to keep up with this newsgroup and respond to other comments if appropriate, but I honestly can't track them all. Dorothy Denning denning@cs.georgetown.edu (posting from guvax) ---------------------------------------------------------------------- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Tue, 27 Oct 92 20:06:05 PPE To: cypherpunks@toad.com Subject: Messages in the Least Significant Bits Message-ID: <9210280303.AA21744@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Cypherpunks, Here's a message I just posted to another mailing list. It has rather strict policies against cross-posting, so I've edited out the headers and the initial chunk of text I quoted. That should make me kosher. (This topic also came up in some e-mail with George Gleason.) Forwarded message: From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Anonymous Date: Tue Sep 07 12:36:54 1999 Subject: No Subject Message-ID: MIME-Version: 1.0 Content-Type: text/plain xxxx is exactly right on this. Several years ago I posted to sci.crypt my "novel" idea for packing bits into the essentially inaudible "least significant bits" (LSBs) of digital recordings, such as DATs and CDs. Ditto for the LSBs in an 8-bit image or 24-bit color image. I've since seen this idea reinvented _several_ times on sci.crypt and elsewhere...and I'm willing to bet I wasn't the first, either (so I don't claim any credit). A 2-hour DAT contains about 10 Gbits (2 hours x 3600 sec/hr x 2 channels x 16 bits/sample x 44K samples/sec), or about 1.2 Gbytes. A CD contains about half this, i.e., about 700 Mbytes. The LSB of a DAT is 1/16th of the 1.2 Gbytes, or 80 Mbytes. This is a _lot_ of storage! A home-recorded DAT--and I use a Sony D-3 DAT Walkman to make tapes--has so much noise down at the LSB level--noise from the A/D and D/A converters, noise from the microphones (if any), etc.--that the bits are essentially random at this level. (This is a subtle, but important, point: a factory recorded DAT or CD will have predetermined bits at all levels, i.e., the authorities could in principle spot any modifications. But home-recorded, or dubbed, DATs will of course not be subject to this kind of analysis.) Some care might be taken to ensure that the statistical properties of the signal bits resemble what would be expected with "noise" bits, but this will be a minor hurdle. Adobe Photoshop can be used to easily place message bits in the "noise" that dominates things down at the LSB level. The resulting GIF can then be posted to UseNet or e-mailed. Ditto for sound samples, using the ideas I just described (but typically requiring sound sampling boards, etc.). I've done some experiments along these lines. This doesn't mean our problems are solved, of course. Exchanging tapes is cumbersome and vulnerable to stings. But it does help to point out the utter futility of trying to stop the flow of bits. --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP 2.0 and MailSafe keys by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Tue, 27 Oct 92 19:45:14 PPE To: cypherpunks@toad.com Subject: re: Hackers Conference--Crypto Session Message-ID: <3344.2AEDFD5B@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain U> From: tcmay@netcom.com (Timothy C. May) U> asked me to help put together the crypto session at the U> Conference next week (6-8 November, Lake Tahoe). I of I consider it my job in the email world yto point out that the real problems are not technical, but social, and a discussion of privacy/crypto without underlying social stuff (how we interact, legal issues like liability, etc) will devolve into technophilia. Yes I'm volunteering. I'll write something up before Hackers. --- ReadMail * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Tue, 27 Oct 92 23:23:28 PPE To: cypherpunks@toad.com Subject: One-time pads and DC Nets Message-ID: <9210280620.AA04910@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain "Nobody" writes about the dining cryptographers protocol. We talked about it at length at our first face-to-face meeting, but the subject has barely come up on this list. People should read the Chaum articles in the handout, and the excellent tutorial by Jurgen Bos, also in the handout. It is truly exciting stuff, much more so than the usual "classical cryptography" that we mostly talk about here on this list. Part of my great concern about the public key registration proposal is that it will, if enforced, kill off many of these approaches that rely on dynamically changing keys and digital pseudonyms. If there's interest out there in the DC Net approach that "Nobody" so nicely summarized, I'll forward some articles I wrote a while back for another list. --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP 2.0 and MailSafe keys by arrangement. -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP 2.0 and MailSafe keys by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Tue, 27 Oct 92 22:34:58 PPE To: gnu@cygnus.com Subject: D-H telnet protocol In-Reply-To: <9210280200.AA24003@cygnus.com> Message-ID: <9210280519.AA17075@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: gnu@cygnus.com >As I said before, you're free to take what I come up with and add >authentication. But stop berating me in public for doing something >to further the use of cryptography. I'm not berating. I'm just suggesting. I understand your reasoning about not wanting users to need to do any administration, and I also understand your desire to do something good for the crypto community. I will not argue that its a bad thing. The only provisio I make is that it is SO easy to spoof exponential key exchange that I'd argue that providing authentication is crucial if people aren't going to be lulled into a false sense of security. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Wed, 28 Oct 92 18:24:57 PPE To: cypherpunks@toad.com Subject: (fwd) Registering "Assault Keys" Message-ID: <9210290008.AA29345@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Cypherpunks, Things have gotten truly exciting. The posting I made alerting sci.crypt readers to the plans of the Crypto Establishment has generated something close to a hundred responses! And lots of private mail for me (moral support, questions, etc.). Dorothy Denning, in what writer correctly called a "spirited defense" of her proposal, acknowledged the truth of my posting and then went on to embellish her plan. I urge you all to read her well-written comments, if only to see how the Establishment views crypto technology. Several members of this list have also written cogent comments. My latest article is included below, for those of you who may not have Net access. Newsgroups: sci.crypt,comp.org.eff.talk,alt.privacy,talk.politics.guns Path: netcom.com!tcmay From: tcmay@netcom.com (Timothy C. May) Subject: Registering "Assault Keys" Message-ID: <1992Oct28.235027.28039@netcom.com> Organization: Netcom - Online Communication Services (408 241-9760 guest) X-Newsreader: Tin 1.1 PL5 Date: Wed, 28 Oct 1992 23:50:27 GMT Registering "Assault Keys" -- How the Proposal to Register Encryption Keys Has Ominous Parallels to Gun Control The recent proposal that encryption keys be registered with the government has some natural and terrifying implications. (For those to whom this proposal is new, strange, or disturbing, please see the debate raging mainly in the newsgroup "sci.crypt".) Once the principle is established that private communications, letters, faxes, modem transmissions, etc. must be in a form readable--under court order, as Dorothy Denning's proposal goes--by the government, and that "public key encryption" keys must be registered with the authorities, then we can expect the following: * _Classes_ of encryption keys, with some especially strong (in a cryptograhic sense) keys being declared "assault keys," just as certain classes of semiautomatic rifles have been branded "assault weapons" and subjected to media villification and even confiscation by the authorities. In analogy with firearms, there may be "Class 1" dealers in "dangerous" keys. * There may even be _bans_ on the registration (and hence use) of certain classes of algorithms and key lengths. For example, "civilians" may be allowed to use DES, but not RSA. Or the key length may be restricted in various ways. * Strict controls over the types of algorithms allowed. After all, what use will a key be if the government can't run the algorithm? This, by the way, will be another way to control the spread of encryption technology: if only licensed, inspected, and approved algorithms are acceptable to the key registration authorities, innovation and experimentation will suffer. This may make RSA Data Security, Inc., very happy, as it may get the "franchise," while users of bootleg/contraband/experimental algorithms like PGP 2.0 ("Pretty Good Privacy") face severe sanctions. * Spot checks will have to be done to ensure compliance. This may be done in various ways, such as by randomly checking bitstreams and demanding the sender open the message. (Note: Many have posted that this would not be possible. Untrue. The Rehnquist Supreme Court ruled a couple of years ago that the police could enter a bus and ask the passengers to "voluntarily" accept a search of their baggage. Failure to volunteer, so reasoned the court, constituted probable cause for a search! "Catch-22" meets "1984.") * The penalties for noncompliance, or for hiding encrypted messages inside other messages, will likely be severe, else widespread civil disobedience and claims of "ignorance" will result. (Personally, I _expect_ widespread noncompliance. Many people will even flaunt their noncompliance, encrypting truly innocuous messages that few courts, they will hope, will convict them for. Here in California, the noncompliance rate for registration of those evil "assault weapons" is estimated to be as high as 80%.) (My best guess is that the "RICO" (Racketeer-Influenced and Corrupt Organizations Act) and civil forfeiture approaches will be used to simply seize the equipment of anyonone caught sending messages without the suitable seals of approval. Such seizures, used with suspected gun sellers, suspected X-rated video sellers, suspected drug dealers. and so on, have had a profoundly chilling effect.) * A registration system, even if well-intentioned and secured against casual government snooping (and some of the multi-party escrow systems may help do this), will still _greatly complicate_ the use of encryption and will forestall certain very exciting applications of cryptology. Many of the new proposals, for things like anonymous credentials to protect privacy, for digital cash, and for cryptographic voting systems, essentially require the _dynamic_ generation of keys! That is, keys are generated frequently as part of the protocols...there is not single static "public key" that one generates once and then takes down to the crypto equivalent of the DMV for registration. * As with guns, true criminals will of course ignore these laws. Computer networks are already being used for messages that evade wiretaps (as one example, a Mafia guy in New Jersey, on the run, used a well-known computer service to communicate untraceably with his wife), that are used for laundering information and money, and so on. Taking encryption away from citizens will do nothing. I urge readers to get involved in this debate. "If encryption is outlawed, only outlaws--and the NSA--will have encryption." -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP 2.0 and MailSafe keys by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Wed, 28 Oct 92 19:42:40 PPE To: cypherpunks@toad.com Subject: National Security Agency Message-ID: <9210290239.AA08764@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Cypherpunks of the world, encrypt! Enclosed below is a posting I made to debunk Denning's claim that the proposed key registration is needed to thwart criminals. P.S. I still need more comments on how the Hackers session on crypto should go. I've gotten some good private e-mail, but little debate here on the list itself. --Tim Newsgroups: sci.crypt,comp.org.eff.talk,alt.conspiracy Path: netcom.com!tcmay From: tcmay@netcom.com (Timothy C. May) Subject: Re: A Trial Balloon on Registered Keys Message-ID: <1992Oct29.022842.8177@netcom.com> Organization: Netcom - Online Communication Services (408 241-9760 guest) X-Newsreader: Tin 1.1 PL5 References: <1992Oct28.214920.15601@tessi.com> Date: Thu, 29 Oct 1992 02:28:42 GMT Some comments about the National Security Agency (NSA) and why it wants to restrict wide use of encryption. George Mitchell (george@tessi.com) wrote: : Now it's my turn to go out on a limb. I believe that all the parti- : cipants in this discussion would agree that: When the Government : can show, through legitimately obtained evidence, that a particular : encrypted communication relates to a crime, then they can, after : the fact, subpoena the plaintext of that communication. What : most of us object to is having to yield the keys before the fact. Agreed. The current procedure for subpoenaing documents works fairly well. But Prof. Denning's comments clearly indicate the concern is with catching terrorists, kidnappers, subversives, and other such types _in the planning stage_. That is, wiretapping and surveillance. And I'll got out on a limb, too. My suspicion, and that of many others, is that the case of the FBI catching terrorists before the act in the U.S. (and there's a well-known case of a Japanese Red Army terrorist caught in the Midwest several years ago) reveals the sources the FBI uses. The NSA is the likely source. Only the NSA listening in on millions of telephone conversations (not banned by any law...the laws you hear about on wiretapping and surveillance mostly deal with the FBI, law enforcement, and, supposedly, the CIA. The NSA is almost completely exempt from such laws.). If you haven't yet read James Bamford's "The Puzzle Palace," run out and get a copy and read it. You'll see why former DIRNSA General Odom called Bamford "an unindicted felon." (Why in the eyes of the National Security Establishment, that is.) SIGINT OPERATION MINARET, begun in 1969 when Nixon declared the "War on Drugs," brought the NSA together with the FBI, CIA, BNDD (Bureau of Narcotics and Dangerous Drugs, precursor to DEA) to launch a series of new surveillance programs. In May 1970 the NSA extended routine surveillance to _pay phones_ in suspect areas (sound familiar, with the Digital Telephony Bill?). The release of the Pentagon Papers in 1971 revealed the extent of FBI and NSA elsur (electronic surveillance) on U.S. citizens. OPERATION SHAMROCK goes back even further. Beginning in 1945, the FBI and NSA (its precursors, actually, such as Army Signal Corps, etc.) cooperated to monitor dissidents, radicals, authors, etc. It was not until October 1973 that about-to-be-fired Attorney General Elliot Richardson (now fighting for INSLAW in a very similar case, which Prof. Denning ought to read about) ordered the FBI and the CIA's "Security Service" (aptly named SS) to stop requesting NSA surveillance material. In 1977 the Justice Department recommended against prosecution of the FBI and NSA employees engaged in Shamrock and Minaret. Few Americans understand how pervasive is the NSA's listening system. COINTELPRO, Huston Plan, RCA Global (provided copied of all telegrams for 40 years!), FINCEN, and so many other keywords! Huge antennas in West Virginia, in Idaho, and elsewhere (mostly located near major satellite downlinks). Read Bamford's book. Then be afraid....be _very_ afraid. Understand that there are virtually no laws governing the NSA's surveillance of fax machines, modems, the Internet (including all of these postings, obviously), voice phones, telex and TWX, and on and on. Because of the "national security" role, wide lattitude is given. No doubt some criminal plans are uncovered. The NSA detected, it has been admitted, the planned bombing of the Berlin discotheque that led to the '86 raid on Libya. (However, the bombing still occurred...draw your own conclusions.) But is it worth the price? Now there is talk of using the NSA's formidable listening abilities for economic espionage against our economic opponents! Is it any wonder the NSA is scared sh..less over the spread of secure and untappable communications systems? Be afraid, be _very_ afraid. -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP 2.0 and MailSafe keys by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Peter Shipley Date: Thu, 29 Oct 92 01:33:13 PPE To: cypherpunks@toad.com Subject: speaking of data on music CD's Message-ID: <9210290832.AA21734@edev0.TFS> MIME-Version: 1.0 Content-Type: text/plain speaking of messages that can be passwd on musical CD's, I thought this might be of some amusement -Pete ------- Forwarded Message Return-Path: cambler@nike.calpoly.edu Received: by ts2.TFS.COM (5.51/1.00 (TRP - mailsrv)) id AA27917; Tue, 27 Oct 92 03:00:31 PST Received: from zeus.calpoly.edu by tfs.COM (5.61/1.00 (TRP - gateway)) id AA04680; Tue, 27 Oct 92 03:00:21 -0800 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA167170; Tue, 27 Oct 92 03:00:19 -0800 Date: Tue, 27 Oct 92 03:00:19 -0800 From: cambler@nike.calpoly.edu (Christopher J. Ambler, Phish) Message-Id: <9210271100.AA167170@nike.calpoly.edu> To: shipley Subject: Re: laser Here, check this out: Okay, here's the scoop. At the end of the new Information Society CD, there's a 3 minute track (track 12) that's called "300BPS N81" ... Well, I was curious, so I hooked the thing up to a phone line here, tied my modem's carrier detect high, and played with the gain. After 4 or 5 tries, THIS IS WHAT I GOT. - --- begin ath1 OK ato CONNECT 300 SO WE'RE SUPPOSED TO PLAY IN CURITIBA IN 18 HOURS, BUT OUR BUS IS BEING HELD HOSTAGE BY THE LOCAL PROMOTERS. THEY'VE FORMED SOME UNHOLY ALLIANCE WITH THE BRAZILIAN COUNTERPART OF ASCAP; THE PRS. APPARANTLY THE PRS HAS THE LEGAL POWER TO ARREST PEOPLE, AND THEY WANT A PIECE OF THE NATIONAL TOUR PROMOTER'S MONEY. THE LOCAL SECURITY FORCE, "GANG MEXICANA", HAS BEEN BOUGHT OUT FOR 1800 CRUZADOS AND A CARTON OF MARLBOROS EACH. THE ONLY FACTION STILL OPERATING IN OUR DEFENSE IN "BIG JOHN", OUR PERSONAL SECURITY MAN, AND HE'S HIDING IN HIS ROOM BECAUSE A LOCAL GANG IS OUT FOR HIS BLOOD BECAUSE OF A 1982 KNIFING INCIDENT IN WHICH HE WAS INVOLVED. OUR 345-POUND ROAD MANAGER, RICK ONLY HAD THIS TO SAY: "YOU WANTED THE LIFE OF A ROCK STAR!". PAUL, JIM AND I REALIZED THAT THIS WAS ONE SITUATION WE WERE GOING TO HAVE TO GET OUT OF OURSELVES. WE CONVENED A HASTY CONFERENCE IN THE NOVOTEL LOBBY. PAUL SUGGESTED CONTACT- ING OUR NATIONAL TOUR PROMOTER IN SAO PAULO, BUT WE REMEMBERED THAT HE WAS IN RECIFE WITH FAITH NO MORE, WHO HAD JUST ARRIVED FOR THEIR BRAZILIAN TOUR. WE THOUGHT ABOUT CONTACTING OUR BRAZILIAN RECORD COMPANY IN RIO, BUT THEY WEREN'T HOME. OUR EVER-DILIGENT AMERICAN MANAGER WAS ARRANGING HELP OF NUMEROUS FORMS, BUT HE WAS IN NEW YORK, AND JUST TOO FAR AWAY TO GET ANYTHING MOVING IN TIME. AND THERE WERE 6000 KIDS IN CURITIBA WHO JUST WOULDN'T UNDERSTAND. WE KNEW IT WAS TIME FOR ACTION. PAUL WENT UP TO THE PRS GUYS AND INVITED THEM INTO THE BAR TO DISCUSS IT LIKE CIVILIZED MEN OVER A FEW BRAZILIAN DRINKS, OFFERING EACH OF THEM A CIGAR ON HIS WAY. THE AMUSED PRS HEAVIES SEEMED TO LIKE THE IDEA OF A FEW FREE DRINKS, EVEN IF THEY KNEW THEY WOULD NEVER GIVE US OUR BUS BACK. WHEN PAUL WINKED AT JIM AND I ON HIS WAY IN, WE WENT INTO ACTION. I STOLE OFF TO MY ROOM TO PREPARE WHILE JIM WENT INTO ACTION. CREEPING CAREFULLY THROUGH A SERVICE DUCT, HE MANAGED TO GAIN A VANTAGE POINT SOME THREE METERS ABOVE THE BUS, AND DROPPED CAREFULLY ONTO THE ROOF. AFTER USING HIS ALL-PURPOSE SWISS ARMY KNIFE (AFFECTIONATELY KNOWN AS THE "SKIT KNIFE") TO JIMMY OPEN THE ROOF HATCH, HE WENT THROUGH THE DARKENED INSIDE OF THE BUS AND REMOVED THE INSIDE ENGINE SERVICE PANEL. USING SOME SPARE ELECTRONIC PARTS HE FOUND WHILE ON AN ISLAND IN THE AMAZON, HE WIRED THE ENTIRE BUS FOR REMOTE CONTROL, NOT UNLIKE A REMOTE CONTROL TOY CAR. AT THIS POINT, HE ASKED HIMSELF "NOW HOW SHALL I GET OUT OF HERE?!?" PAUL WAS HAVING DIFFICULTIES OF HIS OWN. "COULDN'T YOU SEE YOUR WAY CLEAR TO LETTING US FULFILL OUR CONTRACTUAL OBLIGATIONS IN CURITIBA? THINK OF THE KIDS!" THROUGH OUR TRANSLATOR, FABIO, THE PRS MAN, ALDO, SAID; "NO. YOU AMERICANS THINK YOU OWN THE WORLD. HAH! WE'LL BURN DOWN OUR RAIN FOREST IF WE DAMN WELL PLEASE. WE NEED ROOM FOR COWS!! WE WANT A MACDONALD'S ON EVERY... OH, SORRY, YES ANYWAY, NO. WE NEED 40% OF YOUR CONCERT RECEIPTS TO GIVE TO DAVID BOWIE." HE SAID, WINKING TO THE LOCAL PROMOTER, PHILLIPE. AS PAUL CONTINUED THIS ELABORATE DISTRACTION, JIM EFFECTED AN ESCAPE FROM THE HEAVILY GUARDED BUS BY CRAWLING DOWN INTO THE CARGO BAY, CUTTING A HOLE IN THE FLOOR WITH THE SWISS ARMY KNIFE'S ARC-WELDER, SLIPPING INTO THE MANHOLE COVER SITUATED UNDER THE BUS, AND WALKING UP INTO THE HOTEL'S BASEMENT FROM THERE. JIM CALLED UP TO ME IN MY ROOM AND GAVE THE SIGNAL. WE WERE NOW TO MEET AT THE BACK ENTRANCE, WITH OUR TECH GUYS. BUT FIRST, PAUL WOULD NEED SOME HELP GETTING AWAY FROM HIS UNWELCOME GUESTS, AS THINGS WERE GETTING UGLY. "HE SAYS HE HAS LOST HIS PATIENCE, AND THAT HE CAN THINK OF OTHER WAYS OF EXACTING PAYMENT FROM YOU KURT AND JIM PHYSICALLY." OUR TREMBLING INTERPRETER SAID. THE MOMENT HAD COME. JIM BEGAN OPERATING THE BUS FROM HIS BACK ENTRANCE VANTAGE POINT. AS THE REMOTE-CONTROLLED BUS LURCHED TOWARDS THE PARKING LOT EXIT, THE SUPERSTITIOUS SECURITY YOUTHS FLED IN TERROR. PAUL WAS PULLING ANXIOUSLY ON HIS COLLAR AS THE PRS MAN BEGAN DESCRIBING HIS COLLECTION OF WORLD WAR II NAZI CERIMONIAL KNIVES WHEN A SUDDEN CRASH SPLIT THE TABLEAU. JIM HAD PURCHASED ME THE GIFT OF A COMPLETE BLACK NINJA STEALTH ASSASSIN OUTFIT IN ARACAJU. I HAD BEEN GEARING UP AND CRAWLING THROUGH THE AIR CONDITIONING DUCTS ALL THIS TIME. AS I CRASHED THROUGH THE CHEAP IMITAION- STYROFOAM HUNG CEILING TILES, SKATES FIRST, I FLASHED NINJA STARS ALL ABOUT ME. IN THE ENSUING PANIC, PAUL ESCAPED TO THE PRE-ARRANGED BUS PICK-UP POINT. UNFORTUNATLEY, MY SKATES WERE A POOR CHOICE OF FOOT GEAR FOR ESCAPING OVER THE BROKEN GLASS. OF THE TABLE I HAD LANDED ON. WERE IT NOT FOR THE CONFUSION AND THE NINJA-STAR-INFLICTED WOUNDS DELIVERED TO THE BAD GUYS, I WOULD HAVE BEEN SET UPON WHILE FOUNDERING ON THE GLASS-STREWN CARPET. AS IT HAPPENED, HOWEVER, I LEAPT THROUGH THE OPEN DOOR OF THE CAREENING BUS AS IT DEPARTED THE CITY OF MARINGA FOREVER. IF ONLY WE HAD MANAGED TO GET OUR EQUIPMENT IN THE BUS, TOO . . . EVERY WORD OF THIS STORY IS TRUE. - KURT HARLAND} NO CARRIER ------- End of Forwarded Message From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tom.jennings@f111.n125.z1.FIDONET.ORG (tom jennings) Date: Thu, 29 Oct 92 14:26:42 PPE To: cypherpunks@toad.com Subject: drugs for sale Message-ID: <3373.2AF03157@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain A cross posting from FidoNet PUBLIC_KEYS. It would be nice if some other cypherpunks could join the PUBLIC_KEYS echo. ;Date 29 Oct 92 11:28:07 From: Jesse David Hollington@1:125/33 To: Arol Ambler@1:125/111 Subject: Test >----------------------- Do not change this line -----------------------------< AA> Anyway, anyone who is concerned can always use some method that hides the AA> fact that any secret content is even being communicated. (Variations on AA> read every fifth word to see the real message, or other standard AA> methods). It's funny you should bring that up. One of the major proponents of encryption here in Region 12 posted the following in the Regional Sysop Echo some time ago... ============================================================================= Having said that, I also wonder whether this insistence upon having everything in plain text isn't fostered by some sysops as a means of receiving information that they otherwise wouldn't be privy to. If one is truly paranoid ( *not* that I would fall into that category in anyone's wildest dreams...ahem), one should worry about why some netmail is read so assiduosly by passthrough systems in the first place. Fortunately, even mail that I send direct to nodes is quoted back and often passes through a whole variety of systems for their inspection and review. Since almost all of my netmail is incredibly innocent there might always be the possibility that some of it will come back to hover like a bad dream in some creative complaint. In broader legal terms, every other communication system avoids eavesdropping on mail. P.S. To understand how powerless you are to prevent encrypted text, read the leftmost letter of each sentence in the last three paragraghs downwards...ahem. =========================================================================== He raises a valid point. Sysops who are so paranoid about encrypted mail being sent through their systems should realize that they are really powerless to prevent it if somebody is determined enough to send a coded message to somebody else. I've sought legal opinions in Canadian law (I don't know how it is in the U.S.) and I've discovered that the less I know about mail passing through my system, the safer I am. If I keep every message on my system, and read them all, then I can be held liable if somebody routes something illegal through my system and it slips by me. If I kill all passthrough mail, and read nothing except what is addressed to me, I am operating under common carrier status, and can't be held liable any more than Federal Express or UPS could. As a result, it's actually better to *encourage* people to send encrypted mail through your system. The belief that if people are sending encrypted mail they're doing something wrong is a fallacy... then again, I'm preaching to the converted here. Cheers, Jesse. --- Maximus 2.01wb * Origin: On a Clear Disk You Can Seek Forever (1:225/1) -- tom jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!tom.jennings INTERNET: tom.jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: mark@coombs.anu.edu.au (Mark) Date: Wed, 28 Oct 92 18:09:15 PPE To: cypherpunks@toad.com Subject: How far would this extend... Message-ID: <9210290109.AA29045@coombs.anu.edu.au> MIME-Version: 1.0 Content-Type: text/plain With regard to the FBI bill, the definition of electronic communication provider is rather vague IMHO. It seems to cover a BBS, any unix site (or equiv) etc. (I deleted the article so I cant quote it) Anyway if the above is true will this mean all machines that electronic communication traverses have to have a 'backdoor' so the gov can sit in their offices and run through the mail spool as root? :) Or log into any BBS and do the same? There hasnt been any talk of it as such, probably because they can do it fairly easily anyhow, but it just seems like another loophole in their (the FBI's) favour. _Sometimes_ I'm glad Im an aussie. Mark From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: edgar@spectrx.Saigon.COM (Edgar W. Swank) Date: Fri, 30 Oct 92 12:02:40 PPE To: cypherpunks@toad.com Subject: Subscribe Message-ID: MIME-Version: 1.0 Content-Type: text/plain I got this address off Extropians. Sorry if there's a separate "request" address I should be using, but I don't know what it is. Please add me to your mailing list. Please use one of these addresses: Internet: edgar@spectrx.saigon.com UUCP: szebra!spectrx!edgar The address in the network header may not work. I'm familiar with how PGP 2.0 works, including some bugs. I'm trying to start a low-cost public key registry, which can verify public keys independent of the network. Here is my signed 512-bit public key: -----Type bits/keyID Date User ID -----pub 512/4F0C47 1992/09/26 Edgar W. Swank -----sig! 67F70B 1992/10/14 Philip R. Zimmermann -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.02 mQBNAirEvxwAAAECAMUkLHrx6JH45BMd4bxZDNQO3HrLmhZSvsHJzLH9+90BTbuX 3Kvo0pSLCh98m2Abu/LtoHDggJOKxRGee+5PDEcABRG0KUVkZ2FyIFcuIFN3YW5r IDxlZGdhckBzcGVjdHJ4LnNhaWdvbi5jb20+iQCVAgUQKtu1h+J13g7/Z/cLAQFg nAQAjRlKmmSvDMZUWKM2BQFmpqHBiaCg7OLKEFng9pZGx2qzYHCZOL+a9A0exN9P RAtV6bEm9+F8VoOEpVyF346XJwwE1e/13IETHFi7Jd9fbjsw8voQFqz69X2p8xoE LxYtqSlwfOQ3S7JOyyx4/p04fG/JZuRJicVaUIRlDKHJPJ0= =tsbS -----END PGP PUBLIC KEY BLOCK----- -- edgar@spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tomj@f111.n125.z1.FIDONET.ORG (tomj) Date: Fri, 30 Oct 92 02:00:19 PPE To: cypherpunks@toad.com Subject: PUBLIC_KEYS pre-Backbone topology Message-ID: <3383.2AF0F94F@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain Here's a nerd message from PUBLIC_KEYS echo conference showing activity and growth. This conference has been around about three weeks. GLOSSARY: node host conference newsgroup echo newsgroup message article 1:222/333 FidoNet address (ie. host site address) backbone a somewhat formal high-throughput systems that carry a large proportion of echos. Only very popular echos are carried on the backbone; low traffic ones the member sites deliver their own mail (we don't ahve corp. sugardaddies like most internet/uucp sites, I pay Pac Bell each month...) The hideous unreadable gunk is a sort of 'traceroute' of generated message traffic during some period of time, and tends to show the topology. Echomail is a completely distributed, redundant database. Moderation is not physically possible (there is a thing called groupmail that is, but we're not using it). It shows who connects to whom. There is at least one human reader/poster at each node (the sysop); my guess would be about 1.5 average for this subject. Why did I mail this to cypherpunks list? To show the amount of interest in PGP, and demystify FidoNet somewhat. here's the current report from msgs posted here: PATHS: Maintain and report PATHS a message takes within an echo Copyright (C) 1991, Graham J Stair. All rights reserved. Release 1b for DOS (16th June 1991, 15:59) {-? for help} Message directory : \msg\pkey\ Checked on : Sat Oct 24 18:13:40 1992 Number of nodes : 53 Number of messages : 778 Earliest message : Sat Oct 03 20:04:12 1992 Latest message : Sat Oct 24 17:06:42 1992 Messages per week : 260.9 1:374/14 (180 of 774) |-}1:374/26 (44 of 53) | |-}1:322/603 (5 of 5) | |-}1:374/12 (1 of 1) | |-}322/6 (4 of 4) |-}1:216/21 (32 of 53) | |-}216/80 (0 of 21) | |-}273/219 (0 of 3) | | |-}1:273/219.4 (1 of 1) | | |-}1:273/937 (1 of 1) | | |-}1:273/219.1 (1 of 1) | |-}1:143/269 (18 of 18) |-}1:374/98 (3 of 6) | |-}1:374/46 (3 of 3) |-}1:100/520 (11 of 11) |-}1:285/27 (26 of 44) | |-}30102/20 (18 of 18) |-}1:170/109 (18 of 18) |-}1:105/36 (20 of 39) | |-}1:105/68 (6 of 6) | |-}1:105/290 (13 of 13) |-}135/71 (0 of 19) | |-}1:135/907 (19 of 19) |-}1:396/1 (5 of 8) | |-}203/23 (0 of 2) | | |-}125/125 (0 of 20) | | |-}125/20 (0 of 11) | | | |-}1:125/209 (8 of 8) | | | |-}1:125/54 (3 of 3) | | |-}1:125/33 (1 of 9) | | |-}1:308/60 (8 of 8) | |-}109/25 (0 of 1) | |-}1:2601/100 (1 of 1) |-}1:234/1 (40 of 40) |-}1:377/14 (56 of 78) | |-}1:377/3 (19 of 19) | |-}377/15 (0 of 2) | | |-}1:377/15.1 (2 of 2) | |-}1:377/33 (1 of 1) |-}163/438 (3 of 9) | |-}1:163/518 (3 of 3) | |-}1:243/3 (3 of 3) |-}1:125/180 (54 of 112) | |-}1:125/111 (38 of 38) | |-}1:125/185 (2 of 2) |-}1:2200/101 (2 of 2) |-}1:135/340 (52 of 52) |-}1:312/2 (16 of 16) |-}1:106/7550 (33 of 33) |-}2:253/513 (2 of 2) |-}1:261/1136 (1 of 1) |-}374/92 (0 of 1) |-}374/13 (0 of 1) Notes: If a node does not appear in this report, it could mean... a) It did not have a message entered from it. b) It did not have a message pass through it to get to the top node. c) Its mail processor doesn't update the ^APATH: kludge with its address. If any feeds change, the report will be unreliable. [converted from high ASCII lines to low ASCII characters by CONV004.ZIP] -30- if we show up in FIDONET.NA tomorrow, everyone stand-by to switch over to Backbone feeds. this ALWAYS take a couple weeks to settle down. cut your direct links as soon as you get confirmation of link from your Backbone source. if you don't get confirmation first, you will probably miss traffic as the Backbone doesn't do rescans. we will get a few dupes. this is inevitable with a private to Backbone changeover and no one should get excited about it. just be sure to pull your direct plug as soon as traffic flows from your Backbone source or you get confirmation of feed, whichever comes first. thanks. TTFN. Chris --- DB 1.50/001027 * Origin: Rights On! - Privacy #1 Right! - Titusville_FL_USA (1:374/14) SEEN-BY: 106/1555 109/25 124/1 125/20 28 33 111 125 180 185 1212 170/610 203/1 SEEN-BY: 203/23 205/10 209/209 374/14 396/1 ;;; -- tomj - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!tomj INTERNET: tomj@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Fri, 30 Oct 92 15:53:14 PPE To: cypherpunks@toad.com Subject: Copies of Crypt Handout and RSA FAQ Message-ID: <9210302035.AA20939@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Some people on this list picked up on my mention of the 60-page handout distributed at our first meeting (9-19-92) and have asked about getting copies. I've distributed all the copies I made before, but may be willing to make more. The problem is cost and time: each copy costs me about $2.00 and there are more than 100 people on this list. Any ideas? I also have a fresh copy of RSA's 52-page FAQ (which is also available by ftp, but many folks have had problems printing it). The same calculation applies. Whatever the solution, I will only make one "copy run," as I don't want to be a document distribution service on a continuing basis. Until a solution appears, PLEASE DO NOT SEND ME REQUESTS, MONEY, ETC. BTW, this applies to PGP 2.0 diskettes as well. I just mailed a diskette to someone who'd been unable to get the ftp'ed version. (And my diskette came from someone on this list, too...thanks!) I didn't ask for postage or diskette fees, but I clearly can't do this with dozens of folks. And yet it seems we ought to find a way to do this. One idea is to put our ideas into practice by having some kind of "escrow service" which holds deposited money (small amounts, given the items discussed here) and which can be used to buy small items, with payments handled electronically (ultimately settled with actual checks, of course). This could get out of hand, of course, so it's just an idea. Any comments? P.S. And don't forget to make your suggestions on the Crypto session at Hackers. I'll be issuing a status report soon. --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP 2.0 and MailSafe keys by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Fri, 30 Oct 92 15:23:43 PPE To: cypherpunks@toad.com Subject: Why I Don't Use PGP Message-ID: <9210302106.AA22149@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Why I Don't Use PGP -- The Top 10 Reasons (from the David Lettercrypt Show) (...drum roll...) 10. Because I use a Mac and the Mac version is not out yet. 9. Because the Mac version may NEVER be out. 8. Because my old IBM PC won't read the 3.5" diskettes my Mac puts out. 7. Because downloading encrypted files with ZMODEM, writing them to DOS format (with Apple File Exchange), hauling out my Toshiba 1000SE laptop and firing it up, loading the 3.5" diskette, and then running PGP takes 5 minutes per message. 6. Because after doing all of the above, I usually get "This is not a PGP file," due to some obscure mistranslation somewhere along the way. 5. Because I barely have the time to read and respond to my ordinary e-mail, let alone decrypt mail, respond (on my DOS machine), and then reverse the above procedure. 4. Because I'm not yet convinced it is needed. It will be someday, but not for right now. (Getting PGP volume up is a great idea...it's the actual decryption that's a pain. Maybe we ought to send dummy messages.) 3. Because ideally our mailers should handle this in a push-button way (I know about the security flaws in having a nonlocal host machine, such as my NETCOM host, do the PGP procedure...I am hoping that someone will write something that transparently "reaches down" into my machine and triggers the computation locally on my machine--and I need a Mac version, of course. Probably an off-line Newsreader for the Mac, like Nuntius, is needed.) 2. Because I don't give out my PGP key (generated on my Toshiba) to all of those who have e-mailed me about it (especially in the wake of my postings about the Denning proposal). The last thing I want is more e-mail from people I've never met, sending me their encrypted secrets of the universe. (...and the Number One reason I don't use PGP?.....) 1. Because computers were supposed to make my life easier, and they haven't. Well, that's enough reasons. I guess I'm just lazy, or have higher priorities than to spend 5 frustrating minutes per mail message. Ironically, I'm not alone. I have heard that even Phil Zimmerman lets his PGP-encrypted messages pile up in his incoming mail, due to the hassles. As Eric Hughes has noted, it is precisely this pain that will cause improvements to be made. -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP 2.0 and MailSafe keys by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Andrew Purshottam Date: Fri, 30 Oct 92 17:50:53 PPE To: cypherpunks@toad.com Subject: Re: remove from mailing list In-Reply-To: <9210242237.aa22143@src4src.linet.org> Message-ID: <9210302349.AA01575@meefun.YP.acad> MIME-Version: 1.0 Content-Type: text/plain Are you Jethroes still using berkeley mail? Get a real mail user agent, like MH, and you can write a pattern that collects all the mail sent to a given address into a mail folder, effectively making your own digest. Andy From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Fri, 30 Oct 92 20:46:23 PPE To: cypherpunks@toad.com Subject: re: Why I Don't Use PGP Message-ID: <3394.2AF2012B@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain U> From: tcmay@netcom.com (Timothy C. May) U> 10. Because I use a Mac and the Mac version is not out yet. I'll ask in the FidoNet PUBLIC_KEYS echo about Smackintoshes. U> 9. Because the Mac version may NEVER be out. ... prolly cuz noone can figger out how to make a lot of money from it! U> 4. Because I'm not yet convinced it is needed. Ayup. My feelings exackly. This is starting to sound just like my gun arguments... I don't need one on the street, but someday I may, no? U> 3. Because ideally our mailers should handle this in a U> push-button way Some do already... --- ReadMail * Origin: tomj@fidosw.fidonet.org / World Power Systems (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Sat, 31 Oct 92 03:45:42 PPE To: tcmay@netcom.com Subject: Re: Why I Don't Use PGP Message-ID: <199210311044.AA08180@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Re. Ten Reasons Why I Don't Use PGP: This is exactly why we need a decent user interface. The ideal would be a public-domain wordprocessor, which could be fairly simple, with a menu option for encrypt/decrypt, signature, and so on. I've been working on something like this for my OTP, and would be glad to participate in a project to do it for PGP and other systems. -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Hal <74076.1041@CompuServe.COM> Date: Sat, 31 Oct 92 09:42:14 PPE To: CYPHERPUNKS Subject: Why I Don't Use PGP... Message-ID: <921031163437_74076.1041_DHJ36-1@CompuServe.COM> MIME-Version: 1.0 Content-Type: text/plain The best way to integrate PGP into other software is a tough question. There are so many different ways in which people read and send mail. A lot of people receive their mail on some other machine, often a multi-user machine. So, the first question is, should the mail be crypted there, or should it be crypted on your personal machine. The second choice is preferable from the security point of view, but that means that you need to download at least your PGP mail in order to decrypt it, and it means you have to compose your mail on your home machine before encrypting, uploading, and sending. (Phil Zimmermann had an idea for multi-user systems in which the RSA portion of the decryption, which involves your secret key, would be done on your personal machine, then the decrypted session key would be uploaded to the multi-user machine and the IDEA decryption done on the message itself. This way you only have to upload and download a couple hundred bytes regardless of the length of the message. This would require PGP to be integrated into a terminal program.) If you _do_ download your mail before reading it, you could get in the habit of downloading _all_ of your mail into a big file, then running a word processor or some more specialized program to read the messages, one at a time, and compose replies. Then, when you were done, you could upload and send the replies. If you worked in this mode, which probably few people do, you could integrate PGP by running it on the downloaded mail file before running your WP to read it. I have a Perl script which runs PGP on a file, finding the PGP messages in it, decrypting them, and replacing them _in_the_file_ with their decrypted versions. (Normally PGP outputs its decrypted contents to another file, which is a little inconvenient.) This can make PGP pretty transparent for decryption if you actually read your mail in this way. Another possibility is to use a WP or mail reading program which has a "filter" mode, one which lets you pass incoming or outgoing mail through some program, and replace the mail with the results of that program. I don't know which programs can do this. A lot of Unix programs can, like VI and EMACS, but I don't know about PC's or other home machines. PGP has a filter mode which is designed to be used with WP's which can do this. There have been a couple of messages on alt.security.pgp which have advice on using PGP with various Unix mail reading programs. Mark Riordan's soon-to-be-released RIPEM program (an alternative, incompatible, RSA public-key program) has some ideas in its manual on how to use its filter mode with Unix mail, which mostly apply to PGP as well. One other point: regarding a Mac port: There have been at least a couple of messages on alt.security.pgp over the past couple of months from people who have successfully compiled the PGP sources under Think C on the Mac. However, as a Unix/PC program, it ends up using a character window for I/O, which you type into just like you would on a PC. This is unacceptable for Macs, so nobody has released one of these. Still, compared to what Tim has to do, it would be an improvement. I think people should release their executables which work like this as an interim crutch version until the real Mac version is available. Hal 74076.1041@compuserve.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Sat, 31 Oct 92 13:31:32 PPE To: cypherpunks@toad.com Subject: re: Why I Don't Use PGP... Message-ID: <3400.2AF2EC7B@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain U> From: 74076.1041@CompuServe.COM (Hal) U> The best way to integrate PGP into other software is a U> tough U> question. There are so many different ways in which U> people read and send mail. U> don't know which programs can do this. A lot of Unix U> programs can, like VI and EMACS, but I don't know about U> PC's or other home machines. PGP has a filter mode which Not to brag, but my offline-reader (DOS version of a 'read news' program), as well as at least one other I know of, does a pretty good job of this. It handles the decrypted plaintext reasonably securely too. It does the decryption locally. (You have to manage your own keyrings externally, though of course keys embedded in messages are handled OK.) Solutions are out there. --- ReadMail * Origin: tomj@fidosw.fidonet.org / World Power Systems (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Sat, 31 Oct 92 13:45:38 PPE To: cypherpunks@toad.com Subject: re: Why I Don't Use PGP... In-Reply-To: <3400.2AF2EC7B@fidogate.FIDONET.ORG> Message-ID: <9210312042.AA02821@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Tom Jennings writes: > Not to brag, but my offline-reader (DOS version of a 'read news' > program), as well as at least one other I know of, does a pretty good > job of this. It handles the decrypted plaintext reasonably securely > too. It does the decryption locally. (You have to manage your own > keyrings externally, though of course keys embedded in messages are > handled OK.) > > Solutions are out there. I'm impressed. Maybe in 2-3 months this'll all shake out a bit, with a Mac version (rumored to be in beta), more "push-button" PGP systems, etc. By the way, Tom has generously agreed to talk about PGP, mailers, FidoNet, etc., at our Crypto session at Hackers. (I'll be sending out a more complete status report soon.) --Tim (Also, I have changed the last line of my .sig to reflect my current unwillingness to mail my PGP key to all of those who are asking for it. Hopefully this will soon change.) -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: awaiting Macintosh version. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Sat, 31 Oct 92 14:04:32 PPE To: cypherpunks@toad.com Subject: Re: Why I Don't Use PGP... In-Reply-To: <921031163437_74076.1041_DHJ36-1@CompuServe.COM> Message-ID: <9210312101.AA03883@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Hal Finney, Tom Jennings, Eric Hughes, and others are working on solutions to the "ease of use" problems I cited in my posting. Hal F. writes: > The best way to integrate PGP into other software is a tough > question. There are so many different ways in which people read > and send mail. > If you _do_ download your mail before reading it, you could get in > the habit of downloading _all_ of your mail into a big file, then > running a word processor or some more specialized program to > read the messages, one at a time, and compose replies. Then, when > you were done, you could upload and send the replies. > > If you worked in this mode, which probably few people do, you could > integrate PGP by running it on the downloaded mail file before running This is a major drag, destroying the feedback loop of reading mail and responding to it immediately. And, as Hal alludes to, it requires extra stuff, like PERL scripts, which complicate matters. > on the Mac. However, as a Unix/PC program, it ends up using a character > window for I/O, which you type into just like you would on a PC. > This is unacceptable for Macs, so nobody has released one of these. > Still, compared to what Tim has to do, it would be an improvement. I > think people should release their executables which work like this as > an interim crutch version until the real Mac version is available. Here's hoping. Several people claim to be working on a real Mac port. (I thought the idea someone had of doing it inside a HyperCard stack was a good one..HyperCard supports a CLI and so could run PGP, and HyperCard newsreaders exist, so in perhaps the two could be united.) Zimmerman's PGP has spurred people to think about the many practical issues of P-K crypto...authentication systems, keyrings, user interfaces, and so on. This alone is a major step forward. --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: awaiting Macintosh version. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Oren Mitz Date: Sat, 31 Oct 92 13:51:56 PPE To: cypherpunks@toad.com Subject: Please remove me from the mailing list! Message-ID: <9211010151.AA18004@coma.huji.ac.il> MIME-Version: 1.0 Content-Type: text/plain Sorry, can't handle the numer of messages every day . Thankx and out. bye bye from O> Message-ID: <9211011932.AA07699@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: Jim McGrath >The other day someone mentioned that PGP uses a patented algorithm. If this >is the case, then what is the difference between using it and the also >patented RSA. From the little reading that I have done, it sounds like RSA is >a better protocol from the point of view of authentication etc. etc. PGP does use RSA. Obviously the "little reading" that you have done has been little indeed. >So, the question is, apart from the fact that PGP exists, and an RSA >implementation is not yet available, (to the best of my limited knowledge) >is there any reason why we shouldn't use it? There are dozens of RSA implementations available including PGP -- PGP is, however, the only widely available one with its code in the public domain. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Jim McGrath Date: Sat, 31 Oct 92 19:24:20 PPE To: cypherpunks@toad.com Subject: PGP vs RSA Message-ID: MIME-Version: 1.0 Content-Type: text/plain The other day someone mentioned that PGP uses a patented algorithm. If this is the case, then what is the difference between using it and the also patented RSA. From the little reading that I have done, it sounds like RSA is a better protocol from the point of view of authentication etc. etc. So, the question is, apart from the fact that PGP exists, and an RSA implementation is not yet available, (to the best of my limited knowledge) is there any reason why we shouldn't use it? Jim McGrath I'd rather have a bottle in front of me than a frontal lobotomy. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Sun, 1 Nov 92 19:50:18 PPE To: cypherpunks@toad.com Subject: Public image... Message-ID: <3410.2AF4969F@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain Another crosspollination from PUBLIC_KEYS. Just something to think about. It refers to Keith Henson's article I ran in FidoNews (apparently the file was corrupted, but that's another story.) This is in no way to imply that the story is bad, nor that I didn't like it (I did), nor that this is even a common opinion. I actually received a few thanks for running it. It's just something to consider. And implies that Keith's article/story is doing it's job! A message from Tom Jennings to all was released into the bitstream 20 Oct 92 12:51. TJ> re: PUBLIC RELATIONS, hell, substance too -- TJ> If what we're doing here is ensuring PRIVACY, let's call it PRIVACY. TJ> Calling it encryption simply drops us into the same category as TJ> crackers and criminals. TJ> This isn't apologia; it's infowar. The "anti abortion" people calling TJ> themselves "pro life" is a good example (regardless of what you think TJ> of the subject, please, I don't want to know, not even in netmail!) TJ> Naming is powerful, especially when names have content. "PRIVACY" is TJ> age-old, and crosses all boundaries, and is inherently anti-statist. TJ> ENCRYPTION is cloak'n'dagger, late night movies, WWII, espionage, etc. Speaking of which, the story by Keith Henson in this week's FidoNews probably set us back ten years. Now data encryption's indelibly linked with saboteurs, criminals and terrorists. :-( Well, maybe not _everyone_ reads FidoNews... :-) Cheers, Rich -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Mon, 2 Nov 92 03:48:32 PPE To: cypherpunks@toad.com Subject: Privacy etc. Message-ID: <199211021047.AA04396@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Definitely agreed with Tom's take on calling it "privacy" instead of "encryption." Connotations are entirely positive, tie in with modesty and domestic comfort and other nice things. Privacy and it's opposite: The following quote comes from the novel _We_ by Eugene Zamiatin, who wrote it in the USSR in the 20s only to see it banned and himself exiled to Paris. _We_ was also a primary source of inspiration for Orwell's _1984_, and is definitely worth reading. "Normally we live surrounded by transparent walls which seem to be knitted of sparkling air; we live beneath the eyes of everyone, always bathed in light. We have nothing to conceal from one another; besides, this mode of living makes the difficult and exalted task of the Guardians much easier. Without it many bad things might happen." Transparent walls with nothing to conceal. And of course, people who live in glass skyscrapers don't throw stones... -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: SIVAI%FRSAC11.BITNET@pucc.Princeton.EDU Date: Mon, 2 Nov 92 04:40:39 PPE To: cypherpunks@toad.com Subject: request Message-ID: <9211021140.AA19067@toad.com> MIME-Version: 1.0 Content-Type: text/plain Hello , I wish i knew the internet address , if any , to which one should ask so to subscribe to the 'sci.cryp' usenet's bb . I'd like to know either what cypherpunk stands for ? I'm interested in mathematical processing of datum ( well datas or datum....a key issue no doubt ) . Anyway i thank you in advance . Regards Louis Safer From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Tue, 3 Nov 92 11:16:54 PPE To: cypherpunks@toad.com Subject: Update on Crypto Session at Hackers Message-ID: <9211031813.AA14130@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Here's the semi-final information on the Crypto Session at Hackers this coming weekend: (Note: These inputs and volunteered talks came in over the past several days. There may be some changes of course. I'd like to see us get together---anybody who is reading this message---on FRIDAY NIGHT, in the refreshment room at MIDNIGHT, so we can plan, make any schedule changes, etc. This is of course up to you folks. I'll post a message somewhere prominent reminding you and listing time and location, if different from above.) * Time: Saturday afternoon, probably 3:00--4:30 (check the schedule!) (in an earlier update I mistakenly said we had only an hour) * Format: 7-10 minute talks by 4-5 people, followed by open discussion, questions, debate, etc. * Schedule: - Opening comments, groundrules, settling down, etc. (5-10 min), Tim May (I'll point people to a glossary posted on the wall and ask them not to interrupt the speakers with questions about the basics of crypto, such as whether DES has a trapdoor, etc.) - PGP, Fidonet, and Mail....Tom Jennings - Diffie-Hellman key exchange for rlogin, etc....John Gilmore - Anonymous remailers and DC-Nets....Eric Hughes - Digital time-stamping....either Stu Haber or W. Scott Stornetta - Open discussion, debate, etc. (45 minutes) I'll be the moderator, to keep folks to their time allotment. * If you have "poster" material, please bring it * We can also suggest that the discussion be continued later that evening, in one of the ad hoc sessions around midnight. Maybe some new topics can be be planned for a late night session. * Eric Hughes has suggested we stamp our badges with my red "CRYPTO" stamp, so that we can know ourselves (sort of a crypto oxymoron, eh?). See me and I'll stamp you, if you wish. Thanks for all of your excellent suggestions. I think this could be one of the best sessions at Hackers. --Tim May, 408-688-5409 -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: awaiting Macintosh version. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: norm@xanadu.com (Norm Hardy) Date: Tue, 3 Nov 92 12:37:42 PPE To: cypherpunks@toad.com Subject: another service Message-ID: <9211031859.AA01697@xanadu.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain I think that there is an even easier time stamping service than that described by Eric Hollander. It too requires a trusted service with a trusted clock. It has just two key pairs, A and B. The protocol is that you send it a message, perhaps with payment under public-A. It returns the message joined with the time provided by its clock under key private-B. The returned message provides evidence in the future that you held the original message at the time indicated in the returned message. This protocol requires no data base of keys. It was once the practice (perhaps still) to mail oneself (US mail) a certified envelope with information that one might want to prove that he had had at some earlier date. One would then keep but not open the delivered envelope. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Paul E Baclace Date: Tue, 3 Nov 92 13:16:52 PPE To: tcmay@netcom.com Subject: Re: Update on Crypto Session at Hackers Message-ID: <199211032014.AA11739@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Sounds good--too short, of course, so it is going to be challenging to prevent digressions. The "Crypto" stamp sounds like a good way for people to follow up on details/questions after the session. Paul From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Matt_Kelly Date: Wed, 4 Nov 92 01:44:48 PPE To: cypherpunks@toad.com Subject: Please remove me from the list Message-ID: <01GQQN03LOTC00041P@ANTIOC.ANTIOCH.EDU> MIME-Version: 1.0 Content-Type: text/plain Please remove me from the cypherpunks distribution list. This is the second time I've asked. thanks, MattKelly@antioc.antioch.edu From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: shipley@@tfs.COM Date: Thu, 5 Nov 92 00:56:03 PPE To: cypherpunks@toad.com Subject: random numbers Message-ID: <9211050754.AA03719@merde.tfs.com> MIME-Version: 1.0 Content-Type: text/plain Here is some code to run on a SparcStaion (I or II) to generate random numbers based on noise from the audio chip. I have not tested the true randomness of the out but cause I don't know how. Thus if anyone can please do and send me the results. I suppose some minor tweeking can be made for the mid range gain for a better spread. unfortunatly there is no way to turn off the u-law audio compression the chip uses to outputs data if you plot the out put you will see the problem the compression caused. #! /bin/sh # here be a shar file echo x - Audio/Makefile cat >Audio/Makefile <<'!E!O!F!' LD= $(CC) CC= cc LDFLAGS=-g CFLAGS=-g -I/usr/demo/SOUND -I/usr/local/include LIBS= -L/usr/demo/SOUND/ -laudio audio_rand: audio_rand.o $(LD) $(LDFLAGS) audio_rand.o $(LIBS) -o $@ test: audio_rand audio_rand | head -10000 > \#fff echo "plot '#fff'" | gnuplot !E!O!F! #! /bin/sh echo x - Audio/audio_rand.c cat >Audio/audio_rand.c <<'!E!O!F!' static char *_author = "Peter Shipley\n"; #define AUDIO_CHIP #include #include #include #include #include #include static char *_who_did_it = "Peter M Shipley (1992) [v0.1]\n"; /* X: 0-15 R: 16-31 GX: 32-33 GR: 33-34 */ #define MMR2_BITS 45 #define GX_GAIN 32 main() { struct audio_ioctl ai; extern void bzero(); int fd; int j, i; if( (fd = open("/dev/audio", O_RDONLY)) < 0) { perror("open:"); exit(1); } bzero(ai, sizeof(struct audio_ioctl) ); ai.control = AUDIO_MAP_ALL; if ( ioctl( fd, AUDIOGETREG, &ai ) < 0 ) { perror( "AUDIOGETREG ALL:" ); exit(1); } /* set audio input to a unconnected pin (audio input B) */ ai.data[MMR2_BITS] = ( ai.data[MMR2_BITS] & ~AUDIO_MMR2_BITS_AINB); /* set gain of the GX reg to the max */ ai.data[GX_GAIN] = 0x7F; ai.data[GX_GAIN+1] = 0x0; for(i=0;;) { char buf[BUFSIZ]; read(fd, buf, BUFSIZ); for(j=0; jAudio/reg.c <<'!E!O!F!' static char *_author = "Peter Shipley\n"; #define AUDIO_CHIP #include #include #include #include #include static char * print_byte(); static struct _map { char *label; char size; } map[] = { "X filter", 16, "R filter", 16, "GX Gain", 2, "GR Gain", 2, "GER Gain", 2, "Sidetone", 2, "Frequency Tone gen", 2, "Amplitude Tone gen", 2, "MMR1", 1, "MMR2", 1 }; #define NMAPS (sizeof(map) / sizeof(struct _map) ) struct audio_ioctl ai; main() { extern void bzero(); int fd; int oldmmr2; int newmmr2; if( (fd = open("/dev/audio", O_RDWR)) < 0) { perror("open:"); exit(1); } dump(fd); /* bzero(ai, sizeof(struct audio_ioctl) ); ai.control = AUDIO_MAP_GX; if ( ioctl( fd, AUDIOGETREG, &ai ) < 0 ) { perror( "AUDIOGETREG MMR2:" ); exit(1); } ai.data[0] = ai.data[1] = 0; if ( ioctl( fd, AUDIOSETREG, &ai ) < 0 ) { perror( "AUDIOSETREG MMR2:" ); exit(1); } */ sleep(5); dump(fd); } dump(f) int f; { int i,k; bzero(ai, sizeof(struct audio_ioctl) ); ai.control = AUDIO_MAP_ALL; if ( ioctl( f, AUDIOGETREG, &ai ) < 0 ) { perror( "AUDIOGETREG MMR2:" ); exit(1); } k=0; for(i = 0 ; i < NMAPS ; i++) { int j; (void) printf("%s:\n", map[i].label); for(j=1; j <= map[i].size; j++,k++) { (void) printf("%10s", print_byte(ai.data[k])); if ( (j % 7) == 0) (void) fputc('\n', stdout); } (void) fputc('\n', stdout); } (void) fputc('\n', stdout); } static char * print_byte(c) char c; { static char bt[9]; bt[0] = ( (c & 0x01) ? '1' : '0'); bt[1] = ( (c & 0x02) ? '1' : '0'); bt[2] = ( (c & 0x03) ? '1' : '0'); bt[3] = ( (c & 0x04) ? '1' : '0'); bt[4] = ( (c & 0x05) ? '1' : '0'); bt[5] = ( (c & 0x06) ? '1' : '0'); bt[6] = ( (c & 0x07) ? '1' : '0'); bt[7] = ( (c & 0x08) ? '1' : '0'); bt[8] = NULL; return bt; } !E!O!F! From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: efrem@informix.com (Efrem Lipkin) Date: Thu, 5 Nov 92 04:30:16 PPE To: cypherpunks@toad.com Subject: a cryptographic deal with the devil Message-ID: <9211051116.AA27015@godzilla.informix.com> MIME-Version: 1.0 Content-Type: text/plain It is widely believed that the Police, the FBI, and other government agencies tap many more phones than they admit in public. This is not counting the NSA's monitoring of all the international traffic they can stuff into a computer. Now the FBI wants telephone switch manufactures to supply them with desktop phone tapping technology. Real-time delivery of all conversations straight to the agent's desk. This is scary, but it might an opportunity. Given that congress is likely to eventually allow the FBI this tech toy, would you go along with a deal that all taps would really require a court order and that the exact time and location of all taps would eventually be made public? No cheating possible. I believe such an compromise may be possible via cyptographic technology, I've not worked out the details, but here is a sketch of the idea. The legislation authorizing the tapping facilities would require that each tap be activated by a key supplied by a court. Each tap would require a new key. The switching gear would not only enforce the key mechanism, but transmit a record of the tap to some agency outside the court system. Both the courts and this agency would be required to periodically make public all old taps. Part of this information would include tamper-proof sequence codes and signatures to guarantee that all taps were in fact reported. The law would effectively be enforced by the switch hardware. We would not only know how many phones were tapped, but whose phones were tapped. This last would pose a privacy problem, The law could just require tappees being eventually informed of the invasion of their lives, rather than public disclosure. Problems: * We consent to the process, it legitimates phone taps. * The hardware would be in place for massive monitoring of communications if the government could get the public to accept dropping the limitations of the scheme. [It might be possible to limit the abuse by having the switches communicate and not accept anymore than a 1,000 taps a year.] * The lobbying for this would be difficult. Additional opportunity: * By proposing and lobbying for this type of scheme, it could be made obvious that the cops and mega cops want to maintain much closer surveillance than they are willing to admit. However, you'd have to be prepared for them to accept the compromise. They may figure on making all their illegal taps via other means. --efrem From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Peter Shipley Date: Thu, 5 Nov 92 18:25:03 PPE To: cypherpunks@toad.com Subject: random numbers (resend) Message-ID: <9211060124.AA11182@edev0.TFS> MIME-Version: 1.0 Content-Type: text/plain [my first send bounced so I am resending] Here is some code to run on a SparcStaion (I or II) to generate random numbers based on noise from the audio chip. I have not tested the true randomness of the out but cause I don't know how. Thus if anyone can please do and send me the results. I suppose some minor tweeking can be made for the mid range gain for a better spread. unfortunatly there is no way to turn off the u-law audio compression the chip uses to outputs data if you plot the out put you will see the problem the compression caused. #! /bin/sh # here be a shar file echo x - Audio/Makefile cat >Audio/Makefile <<'!E!O!F!' LD= $(CC) CC= cc LDFLAGS=-g CFLAGS=-g -I/usr/demo/SOUND -I/usr/local/include LIBS= -L/usr/demo/SOUND/ -laudio audio_rand: audio_rand.o $(LD) $(LDFLAGS) audio_rand.o $(LIBS) -o $@ test: audio_rand audio_rand | head -10000 > \#fff echo "plot '#fff'" | gnuplot !E!O!F! #! /bin/sh echo x - Audio/audio_rand.c cat >Audio/audio_rand.c <<'!E!O!F!' static char *_author = "Peter Shipley\n"; #define AUDIO_CHIP #include #include #include #include #include #include static char *_who_did_it = "Peter M Shipley (1992) [v0.1]\n"; /* X: 0-15 R: 16-31 GX: 32-33 GR: 33-34 */ #define MMR2_BITS 45 #define GX_GAIN 32 main() { struct audio_ioctl ai; extern void bzero(); int fd; int j, i; if( (fd = open("/dev/audio", O_RDONLY)) < 0) { perror("open:"); exit(1); } bzero(ai, sizeof(struct audio_ioctl) ); ai.control = AUDIO_MAP_ALL; if ( ioctl( fd, AUDIOGETREG, &ai ) < 0 ) { perror( "AUDIOGETREG ALL:" ); exit(1); } /* set audio input to a unconnected pin (audio input B) */ ai.data[MMR2_BITS] = ( ai.data[MMR2_BITS] & ~AUDIO_MMR2_BITS_AINB); /* set gain of the GX reg to the max */ ai.data[GX_GAIN] = 0x7F; ai.data[GX_GAIN+1] = 0x0; for(i=0;;) { char buf[BUFSIZ]; read(fd, buf, BUFSIZ); for(j=0; jAudio/reg.c <<'!E!O!F!' static char *_author = "Peter Shipley\n"; #define AUDIO_CHIP #include #include #include #include #include static char * print_byte(); static struct _map { char *label; char size; } map[] = { "X filter", 16, "R filter", 16, "GX Gain", 2, "GR Gain", 2, "GER Gain", 2, "Sidetone", 2, "Frequency Tone gen", 2, "Amplitude Tone gen", 2, "MMR1", 1, "MMR2", 1 }; #define NMAPS (sizeof(map) / sizeof(struct _map) ) struct audio_ioctl ai; main() { extern void bzero(); int fd; int oldmmr2; int newmmr2; if( (fd = open("/dev/audio", O_RDWR)) < 0) { perror("open:"); exit(1); } dump(fd); /* bzero(ai, sizeof(struct audio_ioctl) ); ai.control = AUDIO_MAP_GX; if ( ioctl( fd, AUDIOGETREG, &ai ) < 0 ) { perror( "AUDIOGETREG MMR2:" ); exit(1); } ai.data[0] = ai.data[1] = 0; if ( ioctl( fd, AUDIOSETREG, &ai ) < 0 ) { perror( "AUDIOSETREG MMR2:" ); exit(1); } */ sleep(5); dump(fd); } dump(f) int f; { int i,k; bzero(ai, sizeof(struct audio_ioctl) ); ai.control = AUDIO_MAP_ALL; if ( ioctl( f, AUDIOGETREG, &ai ) < 0 ) { perror( "AUDIOGETREG MMR2:" ); exit(1); } k=0; for(i = 0 ; i < NMAPS ; i++) { int j; (void) printf("%s:\n", map[i].label); for(j=1; j <= map[i].size; j++,k++) { (void) printf("%10s", print_byte(ai.data[k])); if ( (j % 7) == 0) (void) fputc('\n', stdout); } (void) fputc('\n', stdout); } (void) fputc('\n', stdout); } static char * print_byte(c) char c; { static char bt[9]; bt[0] = ( (c & 0x01) ? '1' : '0'); bt[1] = ( (c & 0x02) ? '1' : '0'); bt[2] = ( (c & 0x03) ? '1' : '0'); bt[3] = ( (c & 0x04) ? '1' : '0'); bt[4] = ( (c & 0x05) ? '1' : '0'); bt[5] = ( (c & 0x06) ? '1' : '0'); bt[6] = ( (c & 0x07) ? '1' : '0'); bt[7] = ( (c & 0x08) ? '1' : '0'); bt[8] = NULL; return bt; } !E!O!F! From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Fri, 6 Nov 92 04:16:03 PPE To: efrem@informix.com Subject: Re: a cryptographic deal with the devil Message-ID: <199211061115.AA02435@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Re. the digital wiretapping "compromise." As a telecom professional I absolutely resent and will resist any attempts to mandate backdoors into my PBXs. No compromise on that. Period. We've all heard the arguements many times: vast surveillance power, diminution of privacy, potential major security problems... I'd like to suggest something of a compromise which doesn't have these risks. Common carriers (local and long distance telcos) are currently required to provide access to line terminals when presented with a court order for a wiretap. This access could reasonably be extended to requiring the telco to connect a demultiplexer in the case of digital transmission, or some kind of appropriate signal splitter in the case of fiber optics. The agency requesting the tap would of course pay the bill for materials and labor. Now this gets law enforcement their demultiplexed signal path so they can tap only the intended target line, but it preserves the existing structure which prevents law enforcement "hacking," since no backdoors would be involved. For PBXs (this is my department), a slightly distasteful but acceptable compromise would be to have interconnect companies (the folks who install your PBX or key system) register with the local operating telcos, providing the interconnect company's name and contact information on the telco record for each subscriber. So for instance, General Widgets has XYZ Telecom install a new PBX; XYZ Telecom is required to inform the local operating company that they have just acquired General Widgets as a client. Now if a law enforcement agency gets a court order for a tap, they go to the local telco and ask who the interconnect company is for that subscriber. (We're talking here about a scenario in which one or a small number of extensions in a phone system are believed to be used for criminal purposes, so law enforcement has to tap those extensions only and not everyone who is on that phone system.) Now law enforcement visits the interconnect company and presents them with the court order, which requires the interconnect company to provide access to the line terminals of the suspect extension(s), and/or provide a demultiplexer etc. if needed (at law enforcement's expense of course)... and of course, under penalty of contempt of court, refrain from disclosing the situation to the client. Now this gets law enforcement their legitimately needed access to suspect extensions on PBXs, prevents interconnect companies from blowing the whistle to their clients, and still preserves privacy protections since there is no backdoor into the system. Now here is why I think the FBI wants backdoors: Recall that under the "war on drugs" etc., a ruling was handed down (I can't recall which branch of govt originated this) which says that a wiretap may be conducted for up to 72 hours for "investigational purposes" without a court order; and the material recorded may then be used to go and get a court order for a continuing wiretap. This places authority in the hands of law enforcement agencies to conduct taps any time they suspect someone of something, and then go see the judge after the fact. Now without backdoors, law enforcement has to depend on the goodwill of telcos to get access, and is kind of stuck when it comes to PBXs and key systems. I'm willing to bet there is a pretty substantial amount of "investigational" tapping going on, and that the FBI is interested in vastly expanding it. The compromises I'm proposing don't address this investigational tapping, and that's just fine, since that ought to be challenged in court or defeated one way or another. -gg@well From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: gnu Date: Fri, 6 Nov 92 05:03:26 PPE To: cypherpunks@toad.com, gnu Subject: 1993 RSA Data Security Conference Message-ID: <9211061203.AA20359@toad.com> MIME-Version: 1.0 Content-Type: text/plain RSA is putting on a conference on public key cryptography on the SF peninsula on January 14th (conference) and 15th (tutorials and exposition). Last year's conference was smaller (one day) and quite interesting. Many of the best cryptographers in the world attended. It's worth prying yourself out of your usual haunts for. The conference is free. Registration is "extremely limited, and is first come, first served". Phone +1 415 595 8782 and ask for Conference Registration, to reserve your place (and a place for anyone else at your company who's interested). I'll see you there! John Gilmore From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: mcmahonm@wybbs.mi.org (Mike McMahon) Date: Sat, 7 Nov 92 19:08:31 PPE To: cypherpunks@toad.com Subject: No Subject Message-ID: <9211072044.AA14863@wybbs.mi.org> MIME-Version: 1.0 Content-Type: text/plain Please add my address to the mailing list. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: crunch@netcom.com (John Draper) Date: Mon, 9 Nov 92 13:39:59 PST To: cypherpunks@toad.com Subject: Analysis of cost to produce random serail generator. Message-ID: <9211092136.AA25999@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain At Hackers 8.0, we had a discussion about the feasability of someone building a random data generator. I volunteered to look into this with the hopes of making a cheap and inexpensive device that has 2 DB-9 connectors (Serial through box) to be used to generate random serial data at a particular baud rate. Today, I called Newbridge Micro, they faxed me the data sheets, and gave me the number for a local rep in San Jose. (408) 258-3600, but I was appalled at the price. They wanted $52.50 each in 100 quantity. So it is clear that if I use this chip, which really is a hybred, I cannot charge $50 each. So we have to decide what to do, or how much more it will cost. After examining the data sheet, the chip is probed by a pulse, and a bit comes out with an equal probability of a "1" or a "0". Sorta like a coin toss. I think that the perifery cost of the other electronics, such as shift registers, or UART which would be necessary to clock the bits into an 8 bit register, etc, would cost about $6 - $8 in cost, then I will have to fab the boards. I have friend at Douglas Electronics who can give me a good price. It would cost $150 setup charge for the PC boards and $2 per board. 1 ea RBG1210 $52.50 1 ea PC board $2.00 various chips $8.00 Setup $1.50 (1/100th setup charge) Total parts $63.50 (100 quantity) Cost (4 X parts) $254.00 So, it is clear that the cost is rather high, and not everyone can afford this. But if you think that people will want to buy it at that price, I can go ahead and do it, but the cost to me would be about $250 to build just one of them, and I have someone who can loan me the money to make a prototype. This also includes design time and use of an electronics lab to test and get it running. I wouldn't be able to borrow $6350 to build 100 of them, and I think I can talk the rep into letting me purchase them in smaller quantity, so I can build them on demand. I'm just not so sure that people will want to pay $254 for one of these. So please lets discuss this, among our group to determine if this price is reasonable. Although, it IS possible to use a cesium noise source (Don't know the cost of that) and perhaps I can cut that price down by about a half or a third, but the design time would be much increased, and perhaps there would be twice as much electronics, and perhaps the posibility that the randomness won't be as good. John D. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pozar@kumr.lns.com (Tim Pozar) Date: Mon, 9 Nov 92 15:09:09 PST To: crunch@netcom.com (John Draper) Subject: Re: Analysis of cost to produce random serail generator. In-Reply-To: <9211092136.AA25999@netcom2.netcom.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain John Draper wrote: > [...] > So, it is clear that the cost is rather high, > [...] > Although, it IS possible to use a cesium noise source > [...] > John D. Geez... What happened to the idea of using a reversed-biased diode? That into a cheapy A/D and into a UART, should do the trick... Tim -- Internet: pozar@kumr.lns.com FidoNet: Tim Pozar @ 1:125/555 UUCP: ...!uunet!kumr.lns.com!pozar Snail: Tim Pozar / KKSF / 77 Maiden Lane / San Francisco CA 94108 / USA Voice: +1 415 788 2022 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Mon, 9 Nov 92 15:09:26 PST To: crunch@netcom.com Subject: Analysis of cost to produce random serail generator. In-Reply-To: <9211092136.AA25999@netcom2.netcom.com> Message-ID: <9211092238.AA05660@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: crunch@netcom.com (John Draper) >Although, it IS possible to use a cesium noise source (Don't know >the cost of that) and perhaps I can cut that price down by about >a half or a third, but the design time would be much increased, >and perhaps there would be twice as much electronics, and perhaps >the posibility that the randomness won't be as good. Remember also that a radioactive source thats decaying fast enough to put out 20,000 bits a second the way the RBG1210 can isn't something you want to stand near. >Total parts $63.50 (100 quantity) > >Cost (4 X parts) $254.00 I don't get this -- why is cost four times parts? Is that including profit? Also, shouldn't it just be possible to buy a couple of components and do as well as the Newbridge Micro unit? It would seem that we should be able to build something a lot cheaper than $52 if all we need is a noise source that will make a line go high or low on a clock input... Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: efrem@spitha.informix.com (Efrem Lipkin) Date: Mon, 9 Nov 92 21:57:15 PST To: cypherpunks@toad.com Subject: Re: a cryptographic deal with the devil Message-ID: <9211100543.AA00737@spitha.informix.com> MIME-Version: 1.0 Content-Type: text/plain >Re. the digital wiretapping "compromise." As a telecom professional I >absolutely resent and will resist any attempts to mandate backdoors into my >PBXs. No compromise on that. Period. We've all heard the arguements many >times: vast surveillance power, diminution of privacy, potential major >security problems... I think you missed the point of my proposal. It is to create a situation in which all taps must be court ordered and eventually disclosed. The police have no business making "investigational" taps, they are not entrepreneurs in search of new business opportunities. My prefered solution is no taps. In my experience taps are more common for political reasons than police reasons. I think anyone who believes anything the FBI says without proof must have not been reading the paper for the last several decades. If the political process will not ban wire (fiber) tapping then it seems sensible to try and force all easedropping into the public record. I see no reason to care where the police put their equipment so long as there is no way they can create taps without going to court and creating a public record. I do not see the difference between building the tap in or making it an extra cost option, unless it can be made a very expensive option. If tap control cannot be reliably accomplished via technology, cryptographic or otherwise, then we might as well just fight against all tapping and for universal encryption even if it is a lost cause. I think it is clear that no organization and especially no government or corporation can be trusted to police itself either at the frontdoor or the backdoor. --efrem From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Wed, 11 Nov 92 00:58:51 PST To: cypherpunks@toad.com Subject: Hackers Conference Report Message-ID: <9211110855.AA18408@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Fellow Cypherpunks, Here's a trip report I just sent to another mailing list I'm active on, the "Extropians" list. That's why I "introduce" Tom Jennings, John Gilmore, and Eric Hughes...clearly they need no introduction to readers of _this_ list (although a lot of new folks have signed up recently, I hear). By the way, I just picked up the latest "Mondo 2000." Our own Jude Milhon's article, "The Cypherpunk Movement," is on pp. 36-37 (Issue #8). The address "cypherpunks@toad.com" is mentioned, so we may get even more new folks. Also some good stuff on MindVOX, phreaking, etc. --Tim HACKERS CONFERENCE REPORT I just returned from Hackers 8.0, held 6-8 November in Lake Tahoe, California. Approximately 170 attendees this year. Some Highlights: * Our crypto session went extremely well. The talks were on PGP and FidoNet, Diffie-Hellman key exchange for rlogin, digital time-stamping, and anonymous remailers. More comments later. * Mike Godwin of the Electronic Frontier Foundation (EFF) spoke on the developing conflict between personal privacy and law enforcement, including comments on the "key registration" trial balloon I posted about earlier. (Godwin told me he believes the Denning proposal is deadly serious, that the Department of Justice has put a high priority on limiting the use of cryptography.) * Hacking was well represented. Besides our crypto panel, sessions on cellular phone phreaking and illegal mods to telecom equipment drew large crowds (a "how to" talk on reprogramming the 8051 micro in the Oki 900 cellphone was especially useful). * Eric Drexler gave a talk on nanotechnology (surprise!), with an emphasis on needed work in the next couple of years. Drexler argued that proto-assemblers could be built in as short as 16 years, though there was some skepticism expressed. He also presented a calculation that the "cost" of delaying nanotech is $25 billion a _day_. (I suggested we all skip dinner that night and instead put in another hour in the labs!) * Marvin Minsky answered questions, saying he rarely prepares in advance. AI, robotics, gene expression in embryos, and software were all covered. * Allan Huang of AT&T gave an energetic 90 minute talk on optical computing, going from optical deconvolvers to "computer origami" to optical switches to Sagnac fibers that can store light pulses 6 femtoseconds long! Definitely the most stimulating talk. * Demos in the machine room were better than ever. The "Reality Engine" from Silicon Graphics displayed photorealistic simulations. Lots of Suns, NeXTs, and Macs. Films of SIGGRAPH papers, chaos and fractals, and artificial life were shown at night. Rudy Rucker's session on cellular automata went well. MORE ON CRYPTO Since cryptology and the activities of the "cypherpunks" mailing list are of central concern to me, I'll concentrate on those topics. Our panel was in "prime time," mid-Saturday afternoon, with about 100 in attendance, including a couple of journalists (notably John Markoff of the "New York Times"...if anybody sees an article on this by him, please send me a note about it, OK?). The audience had been prepped for crypto by the comments Friday night by Mike Godwin of the EFF and by a 3 hour rump session on "Digital Cash" from 1 a.m. to 4 a.m on Saturday (remember "hacker hours"). Tom Jennings, one of the chief forces behind FidoNet, an "anarchic" net made up of PCs talking to other PCs, spoke on efforts to spread PGP (Pretty Good Privacy) to as many FidoNet users as possible. It looks like its happening and this will be another avenue to ensure that the "crypto genie" gets safely out of the bottle. John Gilmore, an early UNIX/Sun pioneer and current principal at Cygnus Support, amongst other things, spoke on increasing security against Internet eavesdroppers by using the Diffie-Hellman key exchange protocol for rlogin (for example). This is something we can do fairly soon. Stu Haber and Scott Stornetta of Bellcore (formerly part of Bell Labs) reported on their digital time-stamping system. Some document to be "notarized" is hashed to produce a fairly short number which is hard to forge (i.e., it is very hard to find another document which hashes to the same value). This hash value is then published in, say, a widely read newspaper. If a dispute arises about the time a document was written, the published has value is persuasive. Bellcore actually operates such a service (check the legal notices in the Sunday "New York Times"). Eric Hughes, a mathematician who worked briefly for David Chaum's "DigiCash" outfit, described anonymous remailers implemented in Perl and now running. He also mentioned Hal Finney's version which embeds PGP in the remailer, allowing more security. This generated a lot of excitement, as the ideas of "crypto anarchy" became apparent to all. (John Little, owner and operator of the "Portal Communications Company," a Bay Area-based Internet access service, got excited and offered to run the remailers on his system! The genie is further out of the bottle. Now if we can only get GEnie to do the same!) The spirit of contributing to the larger cause of using crypto to _directly_ protect privacy was exhilarating. More people spoke of actual code they plan to write (as with Russell Whittaker's offer a few weeks ago to help with ProComm mods). There was a real sense that Things Had Changed. With PGP 2.0 arriving a few months ago (and still spreading), with the onset of the "Cypherpunks" group (which got a somehat cryptic write-up by Jude Milhon in the just-published Issue #8 of "Mondo 2000"...but since she coined the term "cypherpunks" to describe us, her article can afford to be cryptic, no?), and with the "Hacker Crackdown" all around us (Sun Devil, Legion of Doom, S.266 attempt to ban encryption, FBI's "Digital Telephony Bill," and the latest "trial balloon" to register keys), the time is right. In the next several months I expect the media, via more articles in magazines like "Mondo 2000" and by articles on crypto policy, to focus in on this issue. Even the "Village Voice" is interested in crypto issues (theme: crypto privacy vs. Big Brother). These are exciting times. If I'm ever busted for sedition, money laundering conspiracy, violation of the Munitions Act, RICO Act violations, or just plain old political incorrectness, carry on the fight. The stakes are high. --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: awaiting Macintosh version. -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: awaiting Macintosh version. -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: awaiting Macintosh version. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Wed, 11 Nov 92 08:24:36 PST To: crunch@netcom.com Subject: Random number generators Message-ID: <9211111624.AA08843@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain There seems to be some confusion over this random number device. Perry Metzger forwarded me some information about Newbridge Microsystems and the part number of a chip that made random numbers. At the crypto BOF at hackers I mentioned that there was a need for a hardware random number generator and that I knew of some chip to do it. John Draper, who was there, expressed a desire to work on such a device. I forwarded him the information about the chip. What I didn't know was the cost or design of this chip. It appears to use a radioactive source to make random numbers. This may account for the cost. In any case, it is likely that most applications don't need this kind of chip. What is needed, though, is _some_ kind of chip. John Draper is eager to manufacture such a device, once we have a design. Would those people willing to help on this design please get in touch with him directly and start a conversation about it. The conversation could reasonably be discussed on the list, if enough are interested. FYI, random numbers are used generally to create single-use session keys in a wide variety of crypto protocols, including Diffie-Hellman key exchange. Hardware random number sources will be a standard component of all computers in the near future. As far as the design of the device itself goes, the numbers that come out of it don't have to be fully random. Non-randomness can be corrected in software. Two characteristics of the output, though will help such correction. First, the number of ones and zeros should be the same. Not only is this useful for correction, but it is easy to do in hardware. Second, effort should be made to make sure that the generator does not pick up cyclic noise from its environment. This means attention to coupling, shielding, and packaging. No extra expense, likely, but definitely to be thought about some. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Wed, 11 Nov 92 08:33:18 PST To: cypherpunks@toad.com Subject: Mac PGP version Message-ID: <9211111630.AA09056@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain I found the address for the Mac version of PGP. anon-ftp to mac.archive.umich.edu directory /mac/util/encryption Would someone try this out and report back to the list how it works? Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: estensla@mipos2.intel.com (Erik Stensland) Date: Wed, 11 Nov 92 09:12:11 PST To: cypherpunks@toad.com Subject: Remove my name please Message-ID: <9211111710.AA08221@mipos2> MIME-Version: 1.0 Content-Type: text/plain Please have my name removed from the mailing list! Thanks From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Wed, 11 Nov 92 09:25:31 PST To: cypherpunks@toad.com Subject: Re: Random number generators In-Reply-To: <9211111657.AA13574@newsu.shearson.com> Message-ID: <9211111722.AA06575@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Eric Hughes comments and then Perry Metzger responds: > >Perry Metzger forwarded me some information about Newbridge > >Microsystems and the part number of a chip that made random numbers. > >At the crypto BOF at hackers I mentioned that there was a need for a > >hardware random number generator and that I knew of some chip to do > >it. John Draper, who was there, expressed a desire to work on such a > >device. I forwarded him the information about the chip. > > >What I didn't know was the cost or design of this chip. It appears to > >use a radioactive source to make random numbers. This may account for > >the cost. In any case, it is likely that most applications don't need > >this kind of chip. > > Just for the record... > As the data sheet makes clear, it most certainly DOES NOT use a > radioactive source. Its very hard to get 20kbits/sec of random numbers > reliably out of any radioactive source you are going to want to be > near, anyway. It operates off of thermal noise just like virtually > every other such device. > > It should be possible to build a similar device out of ordinary > discrete components without overwhelming difficulty. The only problem > would be to make sure that the output was reliably random, and not > overly dependant on things like temperature. > > Perry Perry is correct. Getting 10K or more bits per second from a radioactive soure usually means it is close enough/strong enough to "drift" the device to the point of radiation-induced permanent failure in a matter of weeks or months (if not much sooner, but this is all so dependent on exact calculations and lab experiments). Tony Patti, editor of a small crypto journal and frequent commentator on sci.crypt, is one of several folks who've designed thermal noise-based RNGs. He's selling them, as I recall. I would _strongly_ advise anyone who's contemplating building and selling such a gizmo to first see what the market has produced and whether or not it's selling, etc. A minor note: the bias between 0s and 1s (unequal distribution, for example) is easily handled by considering pairs of numbers, with a "0 1" being called a "0" and a "1 0" being called a "1." --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: awaiting Macintosh version. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Wed, 11 Nov 92 11:14:11 PST To: cypherpunks@toad.com Subject: (fwd) A Silver Bullet to Limit Crypto? Message-ID: <9211111910.AA19576@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Cypherpunks of the World, Here's a new analysis of the key registration proposal I just posted to a couple of groups. -Tim Newsgroups: sci.crypt,alt.privacy,comp.org.eff.talk From: tcmay@netcom.com (Timothy C. May) Subject: A Silver Bullet to Limit Crypto? Date: Wed, 11 Nov 1992 18:36:44 GMT Key Registration as a "Silver Bullet" to Limit Crypto Use Two weeks ago, and more than 500 related messages ago, I posted the "Trial Balloon to Ban Encryption?" message, alerting sci.crypt and other newsgroups to the Dorothy Denning "trial balloon." Prof. Denning has continued the balloon metaphor, calling her first proposal a "lead balloon" and her improved, law-enforcement-friendly version a "copper balloon." Others have called it a "uranium balloon," i.e., it's worse than the lead balloon. In reading the hundreds of comments about ways to bypass the Denning proposal, about the many clever schemes to avoid detection, I came to some realizations about the likely reason for key registration. Also, at the recent Hackers Conference in Lake Tahoe, lots of interesting points came up (crypto, PGP, anonymous remailers, digital cash, privacy, and the "Crypto Crackdown," to borrow Bruce Sterling's title of "The Hacker Crackdown," were hot topics). Mike Godwin of the EFF, who may be reading this in comp.org.eff.talk, spoke on such policies...he told us this kind of crackdown on crypto tools is a priority of several government agencies and that the issue will not go away with the new administration. But why scheme to register keys, by whatever means, if the system is so easily thwarted and bypassed? Neither Prof. Denning nor her colleagues, both in and out of the NSA and FBI, are dummies. The "silver balloon," or silver bullet, is this: * a formal key registration system will directly affect and limit use of the _most important_ part of public key systems: the ability to use public key directories (like phone books) rather than set up all communications on a one-to-one basis (as private key systems require, for key exchange, and as many of the key registration bypasses implicitly or explicitly require). * enforcement, at least for publicly announced P-K keys, can be by insisting that a special message ("This is J. Random User.") be signed with one's registered/deposited key and then verified with the public key to ensure the same private key-public key pair is used. (Yes, there are still bypasses and clevernesses to spoof these systems, but most "publicly visible" use of P-K methods, the main raison d'etre for public keys, will be affected and effectively controlled.) Keys can and will be registered under this proposal, but many people will simply not bother with the hassle and just won't use P-K methods (thus making the monitoring job easier). * bypassing the key registration laws by "going underground" is always possible, but for this purpose one can already use one-time pads, pack message bits into the least significant bits of digital recordings and images, and generally do all sorts of other devious things. The key point is that the wide use of public key methods is reduced, which may be the real motivation. * reducing the wide use of crypto technology by the masses allows the monitoring agencies a slightly easier job in monitoring those who _are_ using crypto. One can imagine exactly the same arguments for restricting or registering voice scramblers for phone use: by requiring registration, fees, etc., many users will simply not bother to use scrambling (and there may be related to spread the idea that anyone using scrambling--or crypto in general--is somehow suspect, must have something to hide, etc. * the key registration ideas discussed so far severely limit use of crypto protocols that _dynamically_ generate lots of public keys. Cryptographic voting, most forms of digital cash, anonymous remailers, and several other exciting uses all tend to generate a lot of keys "on the fly." Are all of these to be registered? How? For how much money per registration? And how long will it take? Weeks? Instead of concentrating on how these kinds of uses, mentioned by many people, effectively make the Denning/Rivest/Micali proposals unworkable, we should look instead at how these proposals may _in fact_ be aimed at limiting the explosive use of crypto for these new applications. A government afraid of digital cash, of anonymous remailing networks, of information markets in technologies, and of lots of other interesting uses, may see key registration as a way to contain this explosion. Even if the private keys kept at the "trusted key authority" were _never_ looked at by court order or otherwise, the key registration act itself would place severe limits on the use of modern cryptographic protocols for novel uses and for wide use by the public. In this sense, the key registration idea may be a silver bullet, or balloon, to head off these uses. A chilling effect (the "liquid nitrogen balloon"?). Any thoughts on this view? -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: awaiting Macintosh version. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Wed, 11 Nov 92 09:08:59 PST To: hughes@soda.berkeley.edu Subject: Random number generators In-Reply-To: <9211111624.AA08843@soda.berkeley.edu> Message-ID: <9211111657.AA13574@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: Eric Hughes >There seems to be some confusion over this random number device. >Perry Metzger forwarded me some information about Newbridge >Microsystems and the part number of a chip that made random numbers. >At the crypto BOF at hackers I mentioned that there was a need for a >hardware random number generator and that I knew of some chip to do >it. John Draper, who was there, expressed a desire to work on such a >device. I forwarded him the information about the chip. >What I didn't know was the cost or design of this chip. It appears to >use a radioactive source to make random numbers. This may account for >the cost. In any case, it is likely that most applications don't need >this kind of chip. Just for the record... As the data sheet makes clear, it most certainly DOES NOT use a radioactive source. Its very hard to get 20kbits/sec of random numbers reliably out of any radioactive source you are going to want to be near, anyway. It operates off of thermal noise just like virtually every other such device. It should be possible to build a similar device out of ordinary discrete components without overwhelming difficulty. The only problem would be to make sure that the output was reliably random, and not overly dependant on things like temperature. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: strat@intercon.com (Bob Stratton) Date: Wed, 11 Nov 92 09:01:48 PST To: cypherpunks@toad.com Subject: Mac PGP Message-ID: <9211111701.AA00740@intercon.com> MIME-Version: 1.0 Content-Type: text/plain I will try out the port that Eric Hughes just mentioned, and I also want to make it known that I'm willing to assist in any Macintosh efforts along these lines. (FYI - I use MPW for development). Bob Stratton Engineer, InterCon Systems Corp strat@intercon.com +1 703 709 5525 (W) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Wed, 11 Nov 92 13:01:03 PST To: cypherpunks@toad.com Subject: re: (fwd) A Silver Bullet to Limit Crypto? Message-ID: <3565.2B016F5A@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain U> From: tcmay@netcom.com (Timothy C. May) U> U> Here's a new analysis of the key registration proposal I U> just posted to a couple of groups. U> U> -Tim I've been crossposting selected messages, such as this one, to FidoNet's PUBLIC_KEY conference, just FYI... --- ReadMail * Origin: tomj@fidosw.fidonet.org / World Power Systems (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: fen@genmagic.com (Fen Labalme) Date: Wed, 11 Nov 92 16:20:49 PST To: Eric Hughes Subject: Re: Mac PGP version Message-ID: <9211112022.AA12952@> MIME-Version: 1.0 Content-Type: text/plain >I found the address for the Mac version of PGP. > >anon-ftp to mac.archive.umich.edu >directory /mac/util/encryption > >Would someone try this out and report back to the list how it works? I pulled it down and found it to be a "nice little app" with certain problems evident from the beginning. The major bug is **no source code**!! How can I trust an app to make my keys? Why don't I just ask the NSA for them? What I would have liked (and expected) was a set of diff (or changed) files from the PGP 2.0 distribution, and perhaps an extra top-level app-maker file to put the nice wisiwyg on top. This would show me an example, and let me build PGP into other apps that I might build. The next bug is no email address for Z. Fiedorowicz, so I can't complain to him directly. And the third apparent bug (now I haven't used this much yet) is that the help file offers help for the standard MPW-style command line operations, but the app is entirely menu-driven. I hope that ZF doesn't take this as purely negative. I am sure that he did a good implementation, and I thank him for doing the work and for providing a nice gui. But I would especially like to get the source code (preferably as minimal changes to the standard distribution so that it is clear that the same internals are used for each). Thanks, Fen -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQBNAisBeSgAAAECAKvzX/54a9kC5FPXfIN7vjep64zkqXwPzr8VXkiJXyklRTRI kyxcuNlS7ipDveilmSDYYP3W5JJMCC1HSIeCc4kABRG0HkZlbiBMYWJhbG1lIDxm ZW5AZ2VubWFnaWMuY29tPg== =bZWg -----END PGP PUBLIC KEY BLOCK----- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eli Brandt Date: Wed, 11 Nov 92 13:37:40 PST To: extropians@gnu.ai.mit.edu Subject: a name for cryptographic currency Message-ID: <9211112137.AA22079@cygnus.com> MIME-Version: 1.0 Content-Type: text/plain Nothing makes it big with a dodecasyllabic name. How about "cryp"? (Rhymes with "scrip"?) The idea is for science-fiction writers to ditch these central-intelligence "credits", and start naming currency "1gAu L5 Consortium cryp" and the like. Eli ebrandt@jarthur.claremont.edu From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: crunch@netcom.com (John Draper) Date: Wed, 11 Nov 92 13:56:07 PST To: cypherpunks@toad.com Subject: My responses regarding random generator. Message-ID: <9211112152.AA24329@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain In response to everyones comments: I am overwhelmed with all this response that came though during the times I was absent from the Nets. At this time, I am evaluating other approaches to this problem then using the Newbridge system's inflated pricey hybred circuit. It is clear that a simple reversed diode circuit may not be enough to produce truly random data bits unless care is taken to prevent periodic signals from being "injected" into the circuit. Although I don't have access to a "clean lab", I do have access to Techtronix scopes, and a general HW lab, but not sure if that is adequate to completly test out the circuit to determine that things are truly random. An easy test I often devise is to generate a pair of random bytes, and display them as X, Y pairs and plot them on the screen as pixels. First, I start with a clean screen, then plot the dots as they come in. As these dots are plotted on the screen, the dots should be evenly distributed over the screen without "bunching" or "patterns" developing. I know that this is not the best way to determine true randomness, but it is cheap and inexpensive to do. I also agree that we should all check out and determine if there are other random generators currently available, and we should compile a list of them to share with the group as proposed by Tim May. Although I haven't yet visited the crypt newsgroups, I suspect that I should post a query there to see if any such puppie exists. Then, there is the speed of generating these random numbers, and how we will want to deal with the possibility of inadequate speed. I suspect that serial transmission at 9500 baud might be easily obtained, but going much faster withoug "drift" might be problematic as Tim May pointed out. At this point, I would now like to get some other feedback from the group on what Zener noise source to use, and kick around some design ideas. It would be nice to be able to exchange schematic diagrams and pass them around. I have a Mac, but not everyone in this group uses them. So what mechasim can we imploy to send schematics around? My next visit to the Nets will be this weekend, so if anyone wants to contact me, they can try me at (510) 769-1268, and it will refer to the number where I'm staying at that time. I still have NO permenent home (after long period of unemployment), so getting on the Nets daily will be problematic for me. I usually hang out in South San Jose, at my friends VCR Repair lab (where this hardware equipment is located), but have no computer set up there until we can set up proper physical security. That number is (408) 377-2382. I am usually there early in the week, because I can make calls to find work from there on Mondays. As I converge into a workable design and if the lab results are encouraging, and acceptable to the group, I would like to build 2 or 3 prototypes and pass them around to volunteers for Beta testing before making them available to the group as a whole. I can get PC boards made via Douglas Electronics fairly inexpensivly, and plan on making them as orders come in, and initial setup costs would be about $350. I already have people set up to invest this much already. Perhaps it would be prudent to set up a group of other HW designers and meet physically somewhere to hammer out a design and make this a group effort. Do I have any volunteers? I think only one meeting would be necessary to determine a rough approach to take. John D. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: karn@qualcomm.com (Phil Karn) Date: Wed, 11 Nov 92 15:00:43 PST To: cypherpunks@toad.com Subject: PGP problems with large key rings? Message-ID: <9211112300.AA06194@servo> MIME-Version: 1.0 Content-Type: text/plain I'm encountering problems when I try to form a large key ring (on the order of 150 keys, each with several signatures). The file is large enough (60+ Kb) but it is apparently trashed; when I run "pgp -kv" on it I only see 4 keys. This is under UNIX, so I don't think memory exhaustion is the problem. I'm not sure I have the latest version of the UNIX port, so if somebody could steer me to the right repository I'd like to try that too. Phil From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Wed, 11 Nov 92 15:18:28 PST To: karn@qualcomm.com Subject: PGP problems with large key rings? In-Reply-To: <9211112300.AA06194@servo> Message-ID: <9211112318.AA18915@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain P.S. The maintenance release is in the works; it may fix the error you describe. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Wed, 11 Nov 92 18:47:46 PST To: cypherpunks@toad.com Subject: Mac PGP version In-Reply-To: <9211112022.AA12952@> Message-ID: <9211120247.AA00337@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Here's the author of the Mac port I referenced: Zbigniew Fiedorowicz This fixes the second of Fen's bugs. Contacting Zig will fix the first (no source). And, Fen, you attached a PGP key. Did you really ask the NSA to generate one for you? :-) Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tribble@xanadu.com (E. Dean Tribble) Date: Thu, 12 Nov 92 01:25:29 PST To: cypherpunks@toad.com Subject: (fwd) A Silver Bullet to Limit Crypto? In-Reply-To: <9211111910.AA19576@netcom.netcom.com> Message-ID: <9211120841.AA17711@xanadu.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain I think I agree with it completely. It is also very well written. Is there a well written summary and response such as this that could be more widely distributed electronically? dean From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hollander Date: Thu, 12 Nov 92 01:09:12 PST To: cypherpunks@toad.com Subject: mac pgp Message-ID: <9211120909.AA19359@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain I uploaded MacPGP to my powerbook, and used it to generate a key pair. The user interface is easier than the Unix user interface, so I have no problem with that, but I do have a big problem with speed. It expects me to type in my pass phrase at about 20 words per minute. It beeps me if I type it faster than that. This makes it too annoying to be used regularly. It should be able to accept full-speed typing on a powerbook 100. I know that a 100 is not a very fast machine, but still, this is just basic keyboard input. My powerbook is about as secure as you can get (it's with me close to 24 hours a day and probably emits very little radiation and it's not on any kind of net), so ideally it would be my main crypto machine, but I don't want to type my pass phrase at 20wpm, so for now I'll stick with the IBM RS/6000 I normally use PGP on, despite its much weaker security. The other speed problem is key generation. This is very slow. Maybe I am spoiled by the RS/6000, which is extremely fast, but I still feel like it should be faster. Also, it does not allow itself to be backrounded properly under system 7 during key generation. However, I must say that I am glad that Fiedorowicz and others are working on this port. It's a good start. e From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Thu, 12 Nov 92 02:38:59 PST To: efrem@spitha.informix.com Subject: Re: a cryptographic deal with the devil Message-ID: <199211121037.AA24895@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Efrem, re your item on tapping and public records. Okay I admit it, I did miss the point of your proposal that any tapping be made the subject of a public record. And basically I agree with you on that point. Now the problem I see is that these agencies will say, "except for taps currently in process," or "investigations which are still open," which is how the FBI gets around FOIA a lot of the time. And we all know that in political cases, the investigation can stay open for a hell of a long time, like until the targeted individuals die or something. Maybe the way to deal with the "open investigations" issue is to mandate disclosure of *something* anyway, in some form, on a regular basis, and certainly it would be nice to have the scheduled disclosures take place a month or so before elections...! I still do not want back doors of any kind in our network. Now speaking of back doors, wouldn't it be a simple matter for someone to hack out a system which would detect the signals coming into the back door, and then do something like turn on a message lamp on the telephones (I'm thinking PBX here, but also consider that deregulation of local switching will result in some amount of "neighborhood telcos" using PBXs to resell service...) Remote access means that some kind of signal has to be sent to the PBX to turn on the tap, either via normal trunks or some signalling channel. Re. John Draper's item about cost of complete RNGs as being 4x the parts cost: that is a standard figure I've seen in use many times. Covers labor and overhead expenses, including parts for prototypes which fail, and all that. COmpletely reasonable estimate. Though it would still be nice to find a less expensive way to do this. Now that I think of it, I believe that Billy Sq-you-know-who designed one of these for me many years ago for exactly this purpose, based on discrete components... and anyone here who knows Bill knows the quality of his designs... so if I can dig up that piece of paper, I'll see about bringing it along to one of our meetings (he drew out a complete schematic). -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: crunch@netcom.com (John Draper) Date: Thu, 12 Nov 92 03:03:12 PST To: cypherpunks@toad.com Subject: Mac PGP - Some comments Message-ID: <9211121059.AA11389@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain I seem to be having problems using the Mac version of PGP, in that when I type ANY character into it, I just get a "beep". Is there some other thing I have to do to get this thing to work? I also want to start building by public key ring so I can learn how to use this puppie, but I am concerned with possible legal problems in using this to communicate with my friends. According to the disclaimer, PGP is "contraband"? Will I get the "thought police" busting down my door for using it? Is anyone working on a Mac version that is more Mac'ish? Like putting in a nice Mac like GUI for key management. It would be nice if it had a pub (or private) "key list" in an editable scrollable list. The Mac version in "mac.archive.umich.edu" appears with just a "cheapie" console window that behaves like I described above. If I had source code, I could "wrap it" in a nice Object oriented GUI and maintain the file format for the keys. Thanx Eric for the Email address for Zbigniew Fiedorowicz. Has anyone contacted Zbigniew relating to the Mac port? It appears to have some problems, but time limitations has prevented me from fiddling with it tonight. I think I might actually have access to the Nets tommorrow, so I'll be "on-line". Cheers JD From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Thu, 12 Nov 92 03:07:32 PST To: tcmay@netcom.com Subject: Re: (fwd) A Silver Bullet to Limit Crypto? Message-ID: <199211121106.AA25693@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Regarding key registration proposals. Tim's critiques shed a most interesting light on this problem. They also point to parallels with voter registration: It has been well-known for some time that requiring people to register some time in advance of an election, causes a decline in participation. This decline is most evident among the disadvantaged sector of the population, for various reasons including inability to take time off from work. Were the disadvantaged to vote en masse, they would most likely weigh in on the side of substantial change, particularly change which would shift the balance of power in a more socially equitable direction. As the powers-that-be prefer to maintain the status quo, they are quite satisfied with the fact that the disadvantaged aren't voting in larger numbers. Hence Republican administrations have (in recent history) blocked efforts to simplify and ease voter registration, as for instance the "motor voter bill" which would automatically create a voter registration when someone gets a driver's licence or car registration. The United States is the world's only remaining Western democracy which requires advance voter registration. This practice had its roots in attempts to prevent newly naturalised US citizens from voting, again, the result of prejudice and desire to maintain the status quo. Now that the Dems are in power, we might consider tying the crypto key issue to the elimination of voter registration, on the basis that both voting and digital communication are forms of speech which should not be subjected to a chilling effect. Rapid promulgation of decent user-friendly PKSs looks pretty essential at this point. I'm thinking, how about approaching Apple to see if they'll include a PKS along with their Macs, as bundled software, sort of like Hypercard. Even if the PKS which is used, has some problem with is, as for instance the old trapdoor-knapsack system, **anything** is preferable to nothing at all when it comes to getting the public educated. Does anyone here know any of the main people at Apple...? What do you think they'd have to say about bundling privacy software along with Macs? -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Thu, 12 Nov 92 07:57:00 PST To: cypherpunks@toad.com Subject: (fwd) A Silver Bullet to Limit Crypto? In-Reply-To: <199211121106.AA25693@well.sf.ca.us> Message-ID: <9211121557.AA25427@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Re: tying voter and crypto registration issues togther. An excellent idea, if both succeed. But since voter registration is already a partisan issue, tying crypto registration to it make crypto a partisan issue. And once you've made it a partisan issue, you've lost, fundamentally. The way to succeed on any issue is to avoid polarization along party lines. One should not assume that there will be automatically a large opposition. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Thu, 12 Nov 92 07:59:57 PST To: cypherpunks@toad.com Subject: (fwd) A Silver Bullet to Limit Crypto? In-Reply-To: <199211121106.AA25693@well.sf.ca.us> Message-ID: <9211121600.AA25453@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Re: Apple include a PKS with their Macs Well, Apple does have a site license for RSA. Tim Oren, who's on the list, knows more about this than I. I ask him to respond. Maybe Apple could license the PGP code as a system utility? Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: simsong@next.cambridge.ma.us (Simson L. Garfinkel) Date: Thu, 12 Nov 92 07:24:57 PST To: George A. Gleason Subject: Re: (fwd) A Silver Bullet to Limit Crypto? Message-ID: <9211121334.AA08156@next.cambridge.ma.us> MIME-Version: 1.0 Content-Type: text/plain Hi. I'm new to this list. Some people may know me. > Date: Thu, 12 Nov 1992 03:06:19 -0800 > From: George A. Gleason > To: cypherpunks@toad.com, tcmay@netcom.com > Subject: Re: (fwd) A Silver Bullet to Limit Crypto? > > Now that the > Dems are in power, we might consider tying the crypto key issue to the > elimination of voter registration, on the basis that both voting and digital > communication are forms of speech which should not be subjected to a > chilling effect. > Good luck. As a practicing journalist, I can say that there is no way that I could make this argument in print. Everybody understand voter registration. There's support for the motor-voter bill. I can't even explain cryptography in the same amount of time that it takes to do an entire article on voter registration. There may be a theoretical connection between the two, but you'll never make that argument outside a university. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Thu, 12 Nov 92 09:45:09 PST To: cypherpunks@toad.com Subject: random generator In-Reply-To: <9211121612.AA03658@newsu.shearson.com> Message-ID: <9211121745.AA27478@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain >I'd like to point out that higher data rates are very very desirable. And higher data rates are more expensive. If you're making one time pads, you need high bit rates, but otherwise you don't. 10Kbps is overcapacity for personal use. Let's do an estimate. Suppose all you use your random numbers for is to create session keys for socket connections. Now lets say you need to open a socket about once a minute. Since you need, say, 500 bits for a DH key exchange, that's a bit rate of about 10 bits per second. One can cache bits coming in from the random number generator in a ring buffer. You can make this ring buffer arbitarily large, or even virtualize it to disk and make it appear as infinite in size. Then you could run your generator continuously and always have enough bits available for use. If you're using a generator for making session keys, then you just don't need that high a bandwidth. Now the $/bps for the Newbridge chip is much lower, but for personal use you throw away too many of its bits to make it worthwhile. This higher bandwidth chip would be useful in a server of some sort, where you are making session keys more than once per second. Proposal: Make this random number generator operate at 100 bps. If higher bit rates are the same price, fine. But a specific design criterion of 100 bps should be a practical and economical goal. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Thu, 12 Nov 92 08:38:19 PST To: crunch@netcom.com Subject: My responses regarding random generator. In-Reply-To: <9211112152.AA24329@netcom2.netcom.com> Message-ID: <9211121612.AA03658@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: crunch@netcom.com (John Draper) > Then, there is the speed of generating these random numbers, >and how we will want to deal with the possibility of inadequate >speed. I suspect that serial transmission at 9500 baud might >be easily obtained, but going much faster withoug "drift" might >be problematic as Tim May pointed out. I'd like to point out that higher data rates are very very desirable. One would like to be able to cut a pair of CD's for use as one time pads in a reasonable amount of time -- at 9600 baud its going to take a LONG time to do. You can always run multiple units in parallel, but its probably good to get the cost/bitrate ratio as low as possible. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Barry.Kapke@f33.n125.z1.FIDONET.ORG (Barry Kapke) Date: Thu, 12 Nov 92 12:39:29 PST To: cypherpunks@toad.com Subject: cypherpunk-request Message-ID: <3585.2B02B9C5@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain This is a request to be added to the mailing list. My addressing to cypherpunk-request@toad.com failed. Thanks. ::::::::::::::::::::::::::::::::::: Barry.Kapke@f33.n125.z1.FIDONET.ORG ::::::::::::::::::::::::::::::::::: -- Barry Kapke - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!33!Barry.Kapke INTERNET: Barry.Kapke@f33.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: omega@spica.bu.edu (The Omega) Date: Thu, 12 Nov 92 09:51:33 PST To: cypherpunks@toad.com Subject: No Subject Message-ID: <9211121751.AA01503@spica.bu.edu> MIME-Version: 1.0 Content-Type: text/plain ---- article one ---- Subject: Reports of "Raid" on 2600 Washington Meeting 11/09/92 From: newsbytes@clarinet.com Date: 9 Nov 92 20:51:16 GMT WASHINGTON, D.C., U.S.A., 1992 NOV 9 (NB) -- The publisher of a well-known hacker magazine claims a recent meeting attended by those interested in the issues his magazine raises was disrupted by threats of arrest by security and Arlington, Virginia police officers. Eric Corley, also known as "Emmanuel Goldstein," editor and publisher of "2600 Magazine: The Hacker Quarterly," told Newsbytes that the meeting was held November 6th at the Pentagon City Mall outside Washington, DC was disrupted and material was confiscated in the raid. 2600 Magazine promotes monthly meetings of hackers, press, and other interested parties throughout the country. The meetings are held in public locations on the first Friday evening of the month and the groups often contact each other by telephone during the meetings. Corley told Newsbytes that meetings were held that evening in New York, Washington, Philadelphia, Cambridge, St. Louis, Chicago, Los Angeles and San Francisco. Corley said, "While I am sure that meetings have been observed by law enforcement agencies, this is the only time that we have been harassed. It is definitely a freedom of speech issue." According to Craig Neidorf, who was present at the meeting and was distributing applications for membership in Computer Professionals For Social Responsibility (CPSR), "I saw the security officers focusing on us. Then they started to come toward us from a number of directions under what seemed to be the direction of a person with a walkie-talkie on a balcony. When they approached, I left the group and observed the security personnel encircling the group of about 30 gatherers. The group was mainly composed of high school and college students. The guards demanded to search the knapsacks and bags of the gatherers. They confiscated material, including CPSR applications, a copy of Mondo 2000 (a magazine), and other material." He adds that the guards also confiscated film "from a person trying to take pictures of the guards. When a hacker called "HackRat" attempted to copy down the names of the guards, they took his pencil and paper." Neidorf continued, "I left to go outside and rejoined the group when they were ejected from the mall. The guards continued challenging the group and told them that they would be arrested if they returned. When one of the people began to take pictures of the guards, the apparent supervisor became excited and threatening but did not confiscate the film." Neidorf also said, "I think that the raid was planned. They hit right about 6:00 and they identified our group as "hackers" and said that they knew that this group met every month." Neidorf's story was supported by a Washington "hacker" called "Inhuman," who told Newsbytes, "I arrived at the meeting late and saw the group being detained by the guards. I walked along with the group as they were being ushered out and when I asked a person who seemed to be in authority his name, he pointed at a badge with his name written in script on it. I couldn't make out the name and, when I mentioned that to the person, he said 'If you can't read it, too bad.' I did read his name, 'C. Thomas,' from another badge." Inhuman also told Newsbytes that he was told by a number of people that the guards said that they were "acting on behalf of the Secret Service." He added, "I was also told that there were two police officers from the Arlington County Police present but I did not see them." Another attendee, Doug Luce, reports, "I also got to the DC meeting very late; 7:45 or so. It seemed like a coordinated harassment episode, not geared toward busting anyone, but designed to get people riled up, and maybe not come back to the mall." Luce adds that he overheard a conversation between someone who had brought a keyboard to sell. The person, he said, was harassed by security forces, one of whom said, "You aren't selling anything in my mall without a vendors permit!" Possible Secret Service involvement was supported by a 19 year-old college student known as the "Lithium Bandit," who told Newsbytes, "I got to the mall about 6:15 and saw the group being detained by approximately 5 Arlington County police and 5 security guards. When I walked over to see what was going on, a security guard asked me for an ID and I refused to show it, saying that I was about to leave. The guard said that I couldn't leave and told me that I had to see a police officer. When I did, the officer demanded ID and, when I once again refused, he informed me that I could be detained for up to 10 hours for refusing to produce identification. I gave in and produced my school ID which the police gave to the security people who copied down my name and social security number." Lithium Bandit continued, "When I asked the police what was behind this action, I was told that they couldn't answer but that 'the Secret Service is involved and we are within our rights doing this." The boy says he and others later went to the Arlington police station to get more information and were told only that there was a report of the use of a stolen credit card and two officers were sent to investigate. "They later admitted that it was 5 [officers]. While I was detained, I heard no mention of a credit card and there was no one arrested." Marc Rotenberg, director of CPSR's Washington office, told Newsbytes, "I have really no details on the incident yet but I am very concerned about the reports. Confiscation of CPSR applications, if true, is outrageous. I will find out more facts on Monday." Newsbytes was told by the Pentagon City Mall office that any information concerning the action would have to come from the director of security, Al Johnson, who was not available until Monday. The Arlington Country Police referred Newsbytes to a "press briefing recording" which had not been updated since the morning before the incident. Corley told Newsbytes, "There have been no reports of misbehavior by any of these people. They were obviously singled out because they were hackers. It's as if they were being singled out as an ethnic group. I admire the way the group responded -- in a courteous fashion. But it is inexcusable that it happened. I will be at the next Washington meeting to insure that it doesn't happen again." The manager of one of New York state's largest malls provided background information to Newsbytes on the rights of malls to police those on mall property, saying, "The primary purpose of a mall is to sell. The interior of the mall is private property and is subject to the regulations of the mall. The only requirement is that the regulations be enforced in an even-handed manner. I do not allow political activities in my mall so I could not make an exception for Democrats. We do allow community groups to meet but they must request space at least two weeks before the meeting and must have proper insurance. Our regulations also say that groups of more than 4 may not congregate in the mall." The spokeswoman added that mall security can ask for identification from those who violate regulations and that they may be barred from the mall for a period of 6 months. She added, "Some people feel that mall atriums and food courts are public space. They are not and the industry is united on this. If the malls were to receive tax benefits for the common space and public service in snow removal and the like, it could possibly be a public area but malls are taxed on the entire space and are totally private property, subject to their own regulations. If a group of 20 or more congregated in my mall, they would be asked to leave." ---- article two ---- Subject: Secret Service Role Questioned in "2600 Washington Raid" 11/10/92 From: newsbytes@clarinet.com Date: 10 Nov 92 21:03:23 GMT WASHINGTON, D.C., U.S.A., 1992 NOV 10 (NB) -- In the aftermath of an action on Friday, November 6th by members of the Pentagon City Mall Police and police from Arlington County, VA in which those attending a 2600 meeting at the mall were ordered from the premises, conflicting stories continue to appear. Attendees at the meeting have contended to Newsbytes that members of the mall police told them that they were "acting on behalf of the Secret Service." They also maintain that the mall police confiscated material from knapsacks and took film from someone attempting to photograph the action and a list of the names of security officers that one attendee was attempting to compile. Al Johnson, chief of security for the mall, denied these allegations to Newsbytes, saying, "No one said that we were acting on behalf of the Secret Service. We were merely enforcing our regulations. While the group was not disruptive, it had pulled tables together and was having a meeting in our food court area. The food court is for people eating and is not for meetings. We therefore asked the people to leave." Johnson denied that security personnel took away any film or lists and further said: "We did not confiscate any material. The group refused to own up to who owned material on the tables and in the vicinity so we collected it as lost material. If it turns out that anything did belong to any of those people, they are welcome to come in and, after making proper identification, take the material." In a conversation early on November 9th, Robert Rasor, Secret Service agent-in-charge of computer crime investigations, told Newsbytes that having mall security forces represent the Secret Service is not something that was done and, that to his knowledge, the Secret Service had no involvement with any Pentagon City mall actions on the previous Friday. A Newsbytes call to the Arlington County police was returned by a Detective Nuneville who said that her instructions were to refer all questions concerning the matter to agent David Adams of the Secret Service. She told Newsbytes that Adams would be providing all information concerning the involvement of both the Arlington Police and the Secret Service in the incident. Adams told Newsbytes: "The mall police were not acting as agents for the Secret Service. Beyond that, I can not confirm or deny that there is an ongoing investigation." Adams also told Newsbytes that: "While I cannot speak for the Arlington police, I understand that their involvement was due to an incident unrelated to the investigation." Marc Rotenberg, director of the Washington office of Computer Professionals for Social Responsibility (CPSR), told Newsbytes that "CPSR has reason to believe that the detention of people at the Pentagon City Mall last Friday was undertaken at the behest of the Secret Service, which is a federal agency." "If that is the case, then there was an illegal search of people at the mall. There was no warrant and no indication of probable illegal activity. This raises constitutional issues. We have undertaken the filing of a Freedom of Information Act (FOIA) request to determine the scope, involvement and purpose of the Secret Service in this action," he said. 2600 meetings are held on the evening of the first Friday of each month in public places and malls in New York City, Washington, Philadelphia, Cambridge, St. Louis, Chicago, Los Angeles and San Francisco. They are promoted by "2600 Magazine: The Hacker Quarterly" and are attended by a variety of persons interested in telecommunications and so-called "hacker issues." The New York meeting, the oldest of its kind, is regularly attended by Eric Corley a/k/a Emmanuel Goldstein, editor and publisher of 2600, hackers, journalists, corporate communications professionals and other interested parties. It is known to have been the subject of surveillance at various times by law enforcement agencies conducting investigations into allegations of computer crime. Corley told Newsbytes: "While I'm sure that meetings have been observed by law enforcement agencies, this is the only time that we have been harassed. It's definitely a freedom of speech issue." Corley also that he plans to be at the December meeting in Washington "to insure that it doesn't happen again." From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: omega@spica.bu.edu (The Omega) Date: Thu, 12 Nov 92 10:50:30 PST To: cypherpunks@toad.com Subject: DC 2600 -- Secret Service Involvement? Message-ID: <9211121850.AA01807@spica.bu.edu> MIME-Version: 1.0 Content-Type: text/plain For more info, see the recent Computer Underground Digest. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nobody@alumni.cco.caltech.edu Date: Thu, 12 Nov 92 13:52:59 PST To: cypherpunks@toad.com Subject: No Subject Message-ID: <9211122154.AA13213@alumni.cco.caltech.edu> MIME-Version: 1.0 Content-Type: text/plain I have a new address where I am running a cryptographically protected, anonymous remailer based on Eric Hughes' perl scripts. It is: . To use the server, put "Request-Remailing-To: " into the header of the message, and send it to the above address. If your mailer won't let you put things into message headers, instead make the first line of your message body be just the two characters "::", and make the next line be "Request-Remailing-To: ", and make the next line be blank. The "::" tells the remailer to take the following lines, up to a blank one, and put them into the header. This particular remailer has PGP integrated into it so that you can encrypt your messages to the remailer. That way a snooper can't see the "Request-Remailing-To" information and can't tell who you are sending to. To use this feature, create a message and put "::" and "Request-Remailing-To:" lines at the beginning, followed by a blank line. Then encrypt this whole message, including these extra lines, using PGP with the remailer key below. (Remember to use the -a flag for ASCII output.) Now, you have to do one more thing. You have to put "Encrypted: PGP" into the message header when you send this message. Again, if you can't put stuff into message headers, you have to edit the PGP ASCII output file to add a line of "::", then a line saying "Encrypted: PGP", then a blank line. This can then be sent to the address above. It will decrypt the message, find the "Request-Remailing-To" line, and forward it for you. This machine is on the Internet so it should have nice, fast turnaround. Be aware that this is a multi-user machine so the encryption is not super secure. Don't bet your life on these messages not being broken. This is strictly experimental at this time. If anyone would like help getting PGP or one of these remailers operating on your local Unix machine, let me know and I will offer any advice that I can. I would really like to see more people than just Eric and myself running remailers. There is a more advanced capability made possible by the cryptographic remailer, which is an "anonymous return address." The idea is, I can post to a group like this, or a usenet group, using a pseudonym. I also include my anonymous return address, which is basically my regular return address, encrypted using the public key of a remailer. People can use this anonymous return address to send to me by forwarding it through the remailer, which decrypts the address, finds out who I am, and sends it to me. The people communicating to me don't even have to know who I am, or what my email address is. Two people could communicate using email, with both of their identities being protected from the other. This kind of capability can really be important in crypto-privacy. Hal 74076.1041@compuserve.com P.S. Here is the PGP key for this remailer: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.01 mQBNAisCtU0AAAEB/jNOYzN1B2YzOxlK/Zb6axoOaGlPq5I7DV9GH3hcGRN5N6Fi T4sRLhi53Sc5rUdYDa8mFQd4tqvFG6rHcT8LtDcABRG0KlJlbWFpbGluZyBTZXJ2 aWNlIDxoYWxAYWx1bW5pLmNhbHRlY2guZWR1Pg== =K00H -----END PGP PUBLIC KEY BLOCK----- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Bob Stratton Date: Thu, 12 Nov 92 11:28:41 PST To: cypherpunks@toad.com Subject: DC 2600 mtg Message-ID: <9211121425.AA32211@horton.intercon.com> MIME-Version: 1.0 Content-Type: text/plain Hi all... I was at the latter part of the Washington 2600 meeting, feel free to ask me questions if you want. By the way, today's article about the event was yet another example of the media promoting hysteria about technologically competent people. The whole article was of the "A hacker is someone who breaks into systems" model. It makes me sick, and I think that the crypto community (the part NOT employed by DoD) is next for this sort of misrepresentation. Cheers, Bob Stratton Engineer, InterCon Systems Corp. strat@intercon.com +1 703 709 5525 (W) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: gsassoun@shearson.com (Garo Sassouni) Date: Thu, 12 Nov 92 12:34:29 PST To: cypherpunks@toad.com Subject: Subscribe Message-ID: <9211122007.AA15091@tardis.shearson.com> MIME-Version: 1.0 Content-Type: text/plain I would like to subscribe to the cypherpunks group. Thanks in advance From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Thu, 12 Nov 92 14:28:48 PST To: cypherpunks@toad.com Subject: re: Re: (fwd) A Silver Bullet to Limit Crypto? Message-ID: <3587.2B02D6F4@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain U> From: gg@well.sf.ca.us (George A. Gleason) U> Rapid promulgation of decent user-friendly PKSs looks U> pretty essential at this point. I'm thinking, how about U> approaching Apple to see if they'll include a PKS along U> with their Macs, as bundled software, sort of like U> Hypercard. Even if the PKS which is used, has some U> problem with is, as for instance the old trapdoor-knapsack U> system, **anything** is preferable to nothing at all when U> it comes to getting the public educated. I agree 101% -- I'd rather have a "bad" system in place, with people asking for a good one (and roundly complaining about the short-sighted implementors :-) than to sit and wait until we can implement the "right" system. I'd much rather have email users want privacy and rag about their compromised system. Even a relatively poor one buts some substantial blocks into routine bulk monitoring of traffic... As frequently happens, the real problem is not technical. --- ReadMail * Origin: tomj@fidosw.fidonet.org / World Power Systems (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Hal <74076.1041@CompuServe.COM> Date: Thu, 12 Nov 92 13:18:01 PST Subject: No Subject Message-ID: <9211122117.AA29329@iha.compuserve.com> MIME-Version: 1.0 Content-Type: text/plain Bcc: Blind Recipients List:; Subject: Why hardware random numbers? Message-ID: <921112211037_74076.1041_DHJ46-1@CompuServe.COM> I don't understand the desire for hardware-based random number generators. It seems to me that a decent software RNG would be adequate for the main uses that I have heard of for RNG's (mostly session key generation). Seed the RNG initially with a nice random set of characters typed in by the user, plus timing information based on the rate of timing of those characters. Also use the local system clock, and possibly a hash of some sectors of the disk or some files on /tmp. Create a pool of random numbers in this way. As you use them, refill the pool, making the refilled bytes a function of the current system clock, and whatever message you are encrypting (or some other appropriate global state). Use a nice strong RNG based on DES, MD5, IDEA, or some other cypher or hash function. I don't think anyone could break the resulting random stream without a physical attack on your computer. Why pay $50 to $200 for a hardware device when you can get the same effect in software that already exist? Both PGP and RIPEM, I think, use the above techniques for their random numbers. Hal 74076.1041@compuserve.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Thu, 12 Nov 92 16:21:35 PST To: cypherpunks@toad.com Subject: The Crypto Singularity Message-ID: <9211130018.AA11046@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain We appear to be entering the long-awaited "Crypto Singularity." (Well, long-awaited by me at least!) A "singularity" in the sense of extremely rapid changes in outlook, technology, and culture. (The use comes from Vernor Vinge's science fictional "singularity" in new technologies, as described in "Marooned in Realtime," and appropriated for their own purposes by the nanotechnology enthusiasts.) Some evidence for this "Crypto Singularity": * the appearance of fully-encrypted remailers, using the Perl scripts of Eric Hughes and Hal Finney. With several more such remailing sites (and recall John Little's offer to place the s/w on Portal), a critical mass of remailers may exist. (A packet remailed through 10 remailers, each storing 10 such encrypted packets before remailing, has an intrinsic diffusivity of 10^10. Of course, there will be far fewer than 10 billion messages, but the point is clear that the origin of a message is effectively untraceable.) * the spread of PGP, onto Internet sites, FidoNet, and hacker boards, IRCs, and the like. (I expect the adoption of PGP by the phone hacker/phreaker community--the community so far the main target of formal charges, as in the Legion of Doom, Len Rose, and Sun Devil cases--is setting off alarms in the law enforcement community.) * the "Hacker Crackdown" spreading to "2600" (will Cyperpunks be next? Will the 150-200 of us get raided?) and mere _meetings_ of hacker folks. * the incredible excitement over these topics at the Hackers Conference, with the sense that these are no longer just abstract ideas. * the interest by several journalists in covering these matters (more on this if things develop). * articles in "Scientific American" just in the past months...David Chaum's work on digital cash, and quantum cryptography. * the firestorm of comments (over 500) about the proposal to register cryptographic keys. All of these point to an accelerating situation. Things may get very interesting and very sticky in the next several months, which is quite a bit faster than I'd expected. Justice and the FBI may not wait until the next Administration to get something started. Perhaps a high-publicity case involving drugs or child molestors will be used as a pretext to crack down. This crackdown may not need new laws...the existing conspiracy, RICI Act, and espionage laws may be enough to "set some examples." Our next Cypherpunks meeting (Saturday, 21 November) should look at some of these issues. "Time is of the essence." --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: awaiting Macintosh version. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: romkey@asylum.sf.ca.us (John Romkey) Date: Thu, 12 Nov 92 15:15:16 PST To: cypherpunks@TOAD.COM Subject: Re: (fwd) A Silver Bullet to Limit Crypto? In-Reply-To: <3587.2B02D6F4@fidogate.FIDONET.ORG> Message-ID: <9211122315.AA09487@asylum.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Date: Thu, 12 Nov 92 15:09:47 PDT From: Tom.Jennings@F111.N125.Z1.FIDONET.ORG (Tom Jennings) I'd much rather have email users want privacy and rag about their compromised system. Even a relatively poor one buts some substantial blocks into routine bulk monitoring of traffic... As long as they *know* it's compromised. Too many people out there think the Internet, for instance, is secure already. They don't realize how easily one can spy on their email, or find out if they're subscribed to a mailing list. - john romkey ELF Communications romkey@ELF.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: omega@spica.bu.edu (The Omega) Date: Thu, 12 Nov 92 15:33:56 PST To: cypherpunks@toad.com Subject: No Subject Message-ID: <9211122333.AA03023@spica.bu.edu> MIME-Version: 1.0 Content-Type: text/plain ---- article one ---- Subject: Reports of "Raid" on 2600 Washington Meeting 11/09/92 From: newsbytes@clarinet.com Date: 9 Nov 92 20:51:16 GMT WASHINGTON, D.C., U.S.A., 1992 NOV 9 (NB) -- The publisher of a well-known hacker magazine claims a recent meeting attended by those interested in the issues his magazine raises was disrupted by threats of arrest by security and Arlington, Virginia police officers. Eric Corley, also known as "Emmanuel Goldstein," editor and publisher of "2600 Magazine: The Hacker Quarterly," told Newsbytes that the meeting was held November 6th at the Pentagon City Mall outside Washington, DC was disrupted and material was confiscated in the raid. 2600 Magazine promotes monthly meetings of hackers, press, and other interested parties throughout the country. The meetings are held in public locations on the first Friday evening of the month and the groups often contact each other by telephone during the meetings. Corley told Newsbytes that meetings were held that evening in New York, Washington, Philadelphia, Cambridge, St. Louis, Chicago, Los Angeles and San Francisco. Corley said, "While I am sure that meetings have been observed by law enforcement agencies, this is the only time that we have been harassed. It is definitely a freedom of speech issue." According to Craig Neidorf, who was present at the meeting and was distributing applications for membership in Computer Professionals For Social Responsibility (CPSR), "I saw the security officers focusing on us. Then they started to come toward us from a number of directions under what seemed to be the direction of a person with a walkie-talkie on a balcony. When they approached, I left the group and observed the security personnel encircling the group of about 30 gatherers. The group was mainly composed of high school and college students. The guards demanded to search the knapsacks and bags of the gatherers. They confiscated material, including CPSR applications, a copy of Mondo 2000 (a magazine), and other material." He adds that the guards also confiscated film "from a person trying to take pictures of the guards. When a hacker called "HackRat" attempted to copy down the names of the guards, they took his pencil and paper." Neidorf continued, "I left to go outside and rejoined the group when they were ejected from the mall. The guards continued challenging the group and told them that they would be arrested if they returned. When one of the people began to take pictures of the guards, the apparent supervisor became excited and threatening but did not confiscate the film." Neidorf also said, "I think that the raid was planned. They hit right about 6:00 and they identified our group as "hackers" and said that they knew that this group met every month." Neidorf's story was supported by a Washington "hacker" called "Inhuman," who told Newsbytes, "I arrived at the meeting late and saw the group being detained by the guards. I walked along with the group as they were being ushered out and when I asked a person who seemed to be in authority his name, he pointed at a badge with his name written in script on it. I couldn't make out the name and, when I mentioned that to the person, he said 'If you can't read it, too bad.' I did read his name, 'C. Thomas,' from another badge." Inhuman also told Newsbytes that he was told by a number of people that the guards said that they were "acting on behalf of the Secret Service." He added, "I was also told that there were two police officers from the Arlington County Police present but I did not see them." Another attendee, Doug Luce, reports, "I also got to the DC meeting very late; 7:45 or so. It seemed like a coordinated harassment episode, not geared toward busting anyone, but designed to get people riled up, and maybe not come back to the mall." Luce adds that he overheard a conversation between someone who had brought a keyboard to sell. The person, he said, was harassed by security forces, one of whom said, "You aren't selling anything in my mall without a vendors permit!" Possible Secret Service involvement was supported by a 19 year-old college student known as the "Lithium Bandit," who told Newsbytes, "I got to the mall about 6:15 and saw the group being detained by approximately 5 Arlington County police and 5 security guards. When I walked over to see what was going on, a security guard asked me for an ID and I refused to show it, saying that I was about to leave. The guard said that I couldn't leave and told me that I had to see a police officer. When I did, the officer demanded ID and, when I once again refused, he informed me that I could be detained for up to 10 hours for refusing to produce identification. I gave in and produced my school ID which the police gave to the security people who copied down my name and social security number." Lithium Bandit continued, "When I asked the police what was behind this action, I was told that they couldn't answer but that 'the Secret Service is involved and we are within our rights doing this." The boy says he and others later went to the Arlington police station to get more information and were told only that there was a report of the use of a stolen credit card and two officers were sent to investigate. "They later admitted that it was 5 [officers]. While I was detained, I heard no mention of a credit card and there was no one arrested." Marc Rotenberg, director of CPSR's Washington office, told Newsbytes, "I have really no details on the incident yet but I am very concerned about the reports. Confiscation of CPSR applications, if true, is outrageous. I will find out more facts on Monday." Newsbytes was told by the Pentagon City Mall office that any information concerning the action would have to come from the director of security, Al Johnson, who was not available until Monday. The Arlington Country Police referred Newsbytes to a "press briefing recording" which had not been updated since the morning before the incident. Corley told Newsbytes, "There have been no reports of misbehavior by any of these people. They were obviously singled out because they were hackers. It's as if they were being singled out as an ethnic group. I admire the way the group responded -- in a courteous fashion. But it is inexcusable that it happened. I will be at the next Washington meeting to insure that it doesn't happen again." The manager of one of New York state's largest malls provided background information to Newsbytes on the rights of malls to police those on mall property, saying, "The primary purpose of a mall is to sell. The interior of the mall is private property and is subject to the regulations of the mall. The only requirement is that the regulations be enforced in an even-handed manner. I do not allow political activities in my mall so I could not make an exception for Democrats. We do allow community groups to meet but they must request space at least two weeks before the meeting and must have proper insurance. Our regulations also say that groups of more than 4 may not congregate in the mall." The spokeswoman added that mall security can ask for identification from those who violate regulations and that they may be barred from the mall for a period of 6 months. She added, "Some people feel that mall atriums and food courts are public space. They are not and the industry is united on this. If the malls were to receive tax benefits for the common space and public service in snow removal and the like, it could possibly be a public area but malls are taxed on the entire space and are totally private property, subject to their own regulations. If a group of 20 or more congregated in my mall, they would be asked to leave." ---- article two ---- Subject: Secret Service Role Questioned in "2600 Washington Raid" 11/10/92 From: newsbytes@clarinet.com Date: 10 Nov 92 21:03:23 GMT WASHINGTON, D.C., U.S.A., 1992 NOV 10 (NB) -- In the aftermath of an action on Friday, November 6th by members of the Pentagon City Mall Police and police from Arlington County, VA in which those attending a 2600 meeting at the mall were ordered from the premises, conflicting stories continue to appear. Attendees at the meeting have contended to Newsbytes that members of the mall police told them that they were "acting on behalf of the Secret Service." They also maintain that the mall police confiscated material from knapsacks and took film from someone attempting to photograph the action and a list of the names of security officers that one attendee was attempting to compile. Al Johnson, chief of security for the mall, denied these allegations to Newsbytes, saying, "No one said that we were acting on behalf of the Secret Service. We were merely enforcing our regulations. While the group was not disruptive, it had pulled tables together and was having a meeting in our food court area. The food court is for people eating and is not for meetings. We therefore asked the people to leave." Johnson denied that security personnel took away any film or lists and further said: "We did not confiscate any material. The group refused to own up to who owned material on the tables and in the vicinity so we collected it as lost material. If it turns out that anything did belong to any of those people, they are welcome to come in and, after making proper identification, take the material." In a conversation early on November 9th, Robert Rasor, Secret Service agent-in-charge of computer crime investigations, told Newsbytes that having mall security forces represent the Secret Service is not something that was done and, that to his knowledge, the Secret Service had no involvement with any Pentagon City mall actions on the previous Friday. A Newsbytes call to the Arlington County police was returned by a Detective Nuneville who said that her instructions were to refer all questions concerning the matter to agent David Adams of the Secret Service. She told Newsbytes that Adams would be providing all information concerning the involvement of both the Arlington Police and the Secret Service in the incident. Adams told Newsbytes: "The mall police were not acting as agents for the Secret Service. Beyond that, I can not confirm or deny that there is an ongoing investigation." Adams also told Newsbytes that: "While I cannot speak for the Arlington police, I understand that their involvement was due to an incident unrelated to the investigation." Marc Rotenberg, director of the Washington office of Computer Professionals for Social Responsibility (CPSR), told Newsbytes that "CPSR has reason to believe that the detention of people at the Pentagon City Mall last Friday was undertaken at the behest of the Secret Service, which is a federal agency." "If that is the case, then there was an illegal search of people at the mall. There was no warrant and no indication of probable illegal activity. This raises constitutional issues. We have undertaken the filing of a Freedom of Information Act (FOIA) request to determine the scope, involvement and purpose of the Secret Service in this action," he said. 2600 meetings are held on the evening of the first Friday of each month in public places and malls in New York City, Washington, Philadelphia, Cambridge, St. Louis, Chicago, Los Angeles and San Francisco. They are promoted by "2600 Magazine: The Hacker Quarterly" and are attended by a variety of persons interested in telecommunications and so-called "hacker issues." The New York meeting, the oldest of its kind, is regularly attended by Eric Corley a/k/a Emmanuel Goldstein, editor and publisher of 2600, hackers, journalists, corporate communications professionals and other interested parties. It is known to have been the subject of surveillance at various times by law enforcement agencies conducting investigations into allegations of computer crime. Corley told Newsbytes: "While I'm sure that meetings have been observed by law enforcement agencies, this is the only time that we have been harassed. It's definitely a freedom of speech issue." Corley also that he plans to be at the December meeting in Washington "to insure that it doesn't happen again." From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: omega@spica.bu.edu (The Omega) Date: Thu, 12 Nov 92 15:34:46 PST To: cypherpunks@toad.com Subject: IRC Bot Message-ID: <9211122334.AA03027@spica.bu.edu> MIME-Version: 1.0 Content-Type: text/plain On a related tangent, There's an interesting bot on IRC in the #hack room, called MACE0, whose purpose is: >> mACe0 exists primarily to accept requests for access to a secure mailing list but it performs other mundane functions as well. To apply for access to the mACe0 mailing list you need to do three things. First, get PGP up and running on your system so that you can generate RSA public keys. Second, get one of the questionaires listing below so u can fill it out. As with all classic elite k-rad systems, we have to know your capabilities and limits so that we can appropriately deny your access. If this bothers you, too bad; the old school k-rad d00dz have seen this type of bullshit before and know exactly what to do. Finally, use mACe0's public key to encrypt your Questionaire and DCC it to mACe0. mACe0 will also take article submissions and public keys via DCC; both of which should be encrypted with mACe0's public key. *Note, when submitting public keys: a) use pgp -kxa to extract them in ascii. b) use a fairly unique filename so DCC won't overwrite your key. /msg mACe0 info .Display this file again. /msg mACe0 dir .Dir of files available /msg mACe0 get filename .To get a file /msg mACe0 sendkey .DCCs mACe0's public key /msg mACe0 quest.1 .Get Hack specific Questionaire /msg mACe0 quest.2 .Get Phreak specific Questionaire /msg mACe0 quest.3 .Get Phreak/Hack mixed Questioniare << From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Mitra Date: Thu, 12 Nov 92 21:22:58 PST To: cypherpunks@toad.com Subject: How to subscribe Message-ID: <9211122121.aa04435@pandora.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain OK, I give up - what is the key I need to get on this list, I've tried cypherpunks-request@toad.com, and listserv@toad.com but neither account exists. Can someone please add me to it. - Mitra P.S. If you reply, do so by email to mitra@pandora.sf.ca.us not to the list, as I cant receive the list yet :-) / From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: crunch@netcom.com (John Draper) Date: Fri, 13 Nov 92 00:00:51 PST To: cypherpunks@toad.com Subject: Rander box and other stuff Message-ID: <9211130757.AA27092@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain To Cypherpunks: I think I have a rough description of the hardware serial random generator I want to build. I want to call it the "Rander box" for lack of a better name. It will have two serial connectors, one an input, and other the output, and connect to a modem or serial port. Physically, it should have dip switch to select baud rate, and an on-off switch. When switched on, and a "cr" (or some other character) is sent to it, random bytes will stream out continiously. Another "cr" will stop the byte stream. At least this is ONE approach. If anyone can think of a better way, Pse speak up. Next week, I plan on consulting with another hardware guru and formulate an initial design. I already know what components need to go into it, and now I want to try and eliminate an extra UART if I can figure out how to turn on and off the random stream via software. The internal code of PGP (I am told) uses an internal buffer to hold the random bytes, generated my environmental changes such as key strokes, mouse movements, or other external actions. Some of the Mac implementors are discussing the feasability of not maintaining 100% portability. I suggested that we break up the PGP program into four parts. a) Incryption engine b) Key management engine. c) GUI interface (DOS, MacOS, UNIX, Windows, etc) d) Random number generator (machine dependent, possibly hardware) Parts (a) and (b) are the "portable" parts, and (c) and (d) are the machine dependent parts. Because the Mac is not multi-tasking, we can get around that problem by implementing a random number generator as a driver. Mac drivers provide for "periodic" code to be called as often as possible, and there are plenty of places where this driver can "look for" environmental changes to generate random numbers using the hashing stuff that Phil implemented. Naturally, the IBM-PC and UNIX versions of software random number generation would be different. But as far as the Incryption and Key generators are concerned, all they need to do, is to look into the random "seed" buffer. Implementing the random number generation as a driver also affords the possibility of having total independence of a hardware device, and if one is desired, no changes to the code will be necessary to have one. We just drop an appropriate INIT into the system folder which will contain the appropriate driver. This is the Mac way of doing things. One other problem I am having in participating in this group is the extra phone expenses I will have. I cannot get on Netcom's local lines from here anymore because they are always busy, and there is a lot of other unconsiderate people that hog up all the local lines for many hours at a time, so mail responses to and from me, may take days. For instance, I cannot participate in any IRC chats unless I get local access, as I am unemployed and cannot afford to call out of my area. So please excuse any slow responses you might get from me. John D. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Fri, 13 Nov 92 01:20:39 PST To: cypherpunks@toad.com Subject: Rander box In-Reply-To: <9211130757.AA27092@netcom2.netcom.com> Message-ID: <9211130920.AA27066@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain > It will have two serial connectors, one an input, and other the >output, and connect to a modem or serial port. Physically, it should >have dip switch to select baud rate, and an on-off switch. Some simplifications I might suggest: I only think you need an output connector. See below. If you can power it off the RS-232 line, you won't need a power switch. You should be able to draw enough power off, say, the DTR line to power a simple thing like this. For a dedicated random number generator with low bandwidth, there's not much reason for variable baud rate. I'd use a fixed baud rate of, say 1200, or even 300. If you make it low enough you could just kludge together a serial interface, but with the low cost of UART's, it's probably not worth it. You might also consider using a PIC, which has built-in serial. > When switched on, and a "cr" (or some other character) is sent to it, >random bytes will stream out continiously. I'd just make the thing spew continuously. It's not like you're losing real, er, information if you ignore a few random bits. This way you don't need the added circuitry for switching on and off. The actual use of this thing is going to require a device driver to buffer up random bits for later use. So all the flow control to the higher layer happens there anyway. And if the UART buffer overflows, so what? Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Fri, 13 Nov 92 02:26:03 PST To: simsong@next.cambridge.ma.us Subject: Re: (fwd) A Silver Bullet to Limit Crypto? Message-ID: <199211131024.AA12677@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Responding to Simsong's critique of my comparison with voter registration. Point well taken. Perhaps a comparison with xerox machines in the old USSR would be more apt: the image of the copier in the guarded room with a loyal party cadre at the door, having all comers sign a book saying what their business is using the copier, and showing the material they'd be copying. The KGB of course was interested in preventing "crime" such as the spreading of anti-Soviet propaganda. Now we would say, oh that's not crime, it's just speech. Exactly: enciphered text is just speech, and if an actual crime is organised over a communications medium, the crime itself is the thing to prosecute, not the speech. The parallel of state officials controlling access to communications devices seems to be pretty straightforward to me. But would it fly on Main Street...? -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Fri, 13 Nov 92 08:57:54 PST To: cypherpunks@toad.com Subject: (fwd) A Silver Bullet to Limit Crypto? In-Reply-To: <9211131553.AA23336@newsu.shearson.com> Message-ID: <9211131657.AA13124@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain From: Tom.Jennings@F111.N125.Z1.FIDONET.ORG (Tom Jennings) >I'd much rather have email users want privacy and rag about their >compromised system. From: romkey@asylum.sf.ca.us (John Romkey) >>As long as they *know* it's compromised. Perry: >PGP is free software. [...] Why put out crap when gold is available >and cheap? Perry, Tom _is_ using PGP. Please be aware of what the actual question is, rather than red-flagging on keywords like "compromised." Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Fri, 13 Nov 92 09:21:09 PST To: cypherpunks@toad.com Subject: Rander box In-Reply-To: <9211131639.AA23711@newsu.shearson.com> Message-ID: <9211131721.AA13968@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Perry on random bit rates: >I strongly disagree -- you really want to be able to do as high a >bandwidth as possible. Cryptography is all economics. The economics here is that John Draper is going to try to market this thing, not play with it in the lab. I don't know what experience you have with electronic design, so pardon me if I condescend. You don't sell features that most people don't need. You don't add parts when only a few people are going to use the feature. You make another version if there is sufficient demand for higher performance. One-time pads are expensive to make relative to other forms of security. Period. No argument. George Gleason and I had a long conversation via email over a period of weeks about this. He was convinced. If you don't believe me, ask him. The largest need for random bits right now is for key material. If you want to use one-time pads, fine. They are secure, no problem. The random number generator we are discussing here is not suitable for making one-time pads. If you want one, build it. It's not what most people need right now. In fact, if one-time pads are economical to use, then surely there is a market for one-time pad systems. Of course, if such a market does not exist, then one-time pads don't provide economical protection for the market as a whole. Which do you think? Re: continuous spewing of bits. Perry thinks this is a bad idea because it won't work with workstations well with respect to interrupts. In my previous post, I mentioned powering the device from DTR. DTR, for those of you not familiar with RS-232, is a device control line which is separately assertable. To turn the device off, toggle DTR. Presto! No more power, no more bits. Simple, when you know what DTR does. My original point remains, though: you don't need a power switch. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: simsong@next.cambridge.ma.us (Simson L. Garfinkel) Date: Fri, 13 Nov 92 06:24:52 PST To: George A. Gleason Subject: Re: (fwd) A Silver Bullet to Limit Crypto? Message-ID: <9211131425.AA09897@next.cambridge.ma.us> MIME-Version: 1.0 Content-Type: text/plain In making public-policy arguments, analogies are dangerous. You need to take time to explain them. The opposition can use other analogies. It's far more effective to argue on the facts. With respect to encryption, the outgoing administration has argued successfully that encryption is the computer equivalent of a saturday night special. That there is no reason to use encryption unless you don't want law enforcement to be able to read what you send. They say that it is only useful against lawful wiretaps, because there are other protections against unlawful wiretaps (ie: the law). The way to attack this is not by making an analogy to photocopiers, but by saying that there are many unlawful wiretaps, breakins, and thefts, and that most of them go unknown and unreported. Argue that most communications that people have an interest in protecting are not about kidnappings but about business dealings. Argue that encryption is vital for communicating with overseas offices, where wiretaps are even more common. Argue that it is important for protecting information on your hard disk which can be stolen. No need to argue with analogy. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Fri, 13 Nov 92 08:03:32 PST To: strat@intercon.com Subject: DC 2600 mtg In-Reply-To: <9211121425.AA32211@horton.intercon.com> Message-ID: <9211131539.AA23245@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: Bob Stratton >Hi all... >I was at the latter part of the Washington 2600 meeting, feel free to ask me >questions if you want. >By the way, today's article about the event was yet another example of the >media promoting hysteria about technologically competent people. The whole >article was of the "A hacker is someone who breaks into systems" model. It >makes me sick, and I think that the crypto community (the part NOT employed >by DoD) is next for this sort of misrepresentation. Pardon, but isn't 2600 magazine a magazine by crackers for crackers? 2600 is named after frequency of the disconnect tone used in blue boxes, isn't it? What I'm afraid of is that I will get confused with one of them -- I'm not sure they are necessarily being misrepresented. The tragedies come when idiots raid Steve Jackson Games and sieze copies of "Cyberpunk" instead of shutting down the infants breaking into TRW. Blurring the distinction between hackers and crackers is the last thing we need. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Fri, 13 Nov 92 08:05:11 PST To: romkey@asylum.sf.ca.us Subject: (fwd) A Silver Bullet to Limit Crypto? In-Reply-To: <9211122315.AA09487@asylum.sf.ca.us> Message-ID: <9211131553.AA23336@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: romkey@asylum.sf.ca.us (John Romkey) > Date: Thu, 12 Nov 92 15:09:47 PDT > From: Tom.Jennings@F111.N125.Z1.FIDONET.ORG (Tom Jennings) > I'd much rather have email users want privacy and rag about their > compromised system. Even a relatively poor one buts some substantial > blocks into routine bulk monitoring of traffic... >As long as they *know* it's compromised. Too many people out there >think the Internet, for instance, is secure already. They don't >realize how easily one can spy on their email, or find out if they're >subscribed to a mailing list. I don't see what the point of putting out mediocre things is at all, given that good things exist. PGP is free software. You need a good RSA implementation? There is one out there already. Why put out crap when gold is available and cheap? Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: gnu@cygnus.com Date: Fri, 13 Nov 92 11:04:31 PST To: cypherpunks@toad.com Subject: Re: Rander box and other stuff In-Reply-To: <9211130757.AA27092@netcom2.netcom.com> Message-ID: <9211131904.AA29178@cygnus.com> MIME-Version: 1.0 Content-Type: text/plain > Some of the Mac implementors are discussing the feasability of not > maintaining 100% portability. If portability was a problem, the Mac would certainly be an answer. Howabout actually trying to be Real Programmers and writing Real Software, like the folks who did all the work that you are now benefiting from? Instead of writing dead-end software that will only live on one platform? I know it isn't the Macintosh Way, but you might learn something. The last thing PGP needs is an installed base of Mac users who are always stuck three revs back because they forked off their own wierd version and couldn't upgrade when the rest of us do. John Gilmore From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Fri, 13 Nov 92 08:47:05 PST To: crunch@netcom.com Subject: Rander box and other stuff In-Reply-To: <9211130757.AA27092@netcom2.netcom.com> Message-ID: <9211131631.AA23673@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: crunch@netcom.com (John Draper) > I think I have a rough description of the hardware serial random >generator I want to build. I want to call it the "Rander box" for >lack of a better name. > It will have two serial connectors, one an input, and other the >output, and connect to a modem or serial port. Physically, it should >have dip switch to select baud rate, and an on-off switch. > When switched on, and a "cr" (or some other character) is sent to it, >random bytes will stream out continiously. Another "cr" will stop the >byte stream. At least this is ONE approach. If anyone can think of >a better way, Pse speak up. Why two serial connectors? RS232 is bidirectional, so you could send control signals down the same pipe the output comes off of. Also, why bother decoding the CRs? Seems like overkill. You could just have CTS/RTS or other lines on the connector control whether bits are clocked out or not. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nobody@alumni.cco.caltech.edu Date: Fri, 13 Nov 92 11:34:22 PST To: cypherpunks@toad.com Subject: Anonymous return addresses Message-ID: <9211131935.AA24489@alumni.cco.caltech.edu> MIME-Version: 1.0 Content-Type: text/plain Here is an example of how to use the cryptographic remailer at to implement an anonymous return address. Note: this material is a little complicated, but if you will take it a step at a time you will see that there's not really that much to it. Suppose I want to receive mail at my address of 74076.1041@compuserve.com, but I don't want that address to be known. First, I create a file with the following contents. Call it t1: ---------------------- cut here ----------------------- :: Request-Remailing-To: 74076.1041@compuserve.com ---------------------- cut here ----------------------- This is the same as what you would normally put at the front of a message to use the remailer. Note that the last line of the file is blank. Now, I encrypt that file, using PGP, with the public key of the remailer (the key is at the end of this message). I use the command, "pgp -ea t1 alumni". I say "alumni" as a shorthand for the address of the remailer on the keyring. This creates a file, t1.asc, which looks like: ---------------------- cut here ----------------------- -----BEGIN PGP MESSAGE----- Version: 2.01 hEwCG6rHcT8LtDcBAf0YbKADFELfaRay6LFviabwpICAAGMV1Pff8meY3ND5o7hu jNy9hQv2bIMM9IyUCF2LFpgamxmMlSwpGQIVbJLEpgAAAEzDG0ddg2oBmjQFzB4c E0d/k7uE8KgxtCg6Sc+l639LN18sv4UWpq0nnyGRTUGEjL9JqtYZOSlTsiSAFU2c 4RoHslyk51suvGokhod0 =XSHb -----END PGP MESSAGE----- ---------------------- cut here ----------------------- Now, I edit the file by adding lines saying "::", and "Encrypted: PGP", and a blank line, to the beginning (and I delete the blank line at the end of the file), giving: ---------------------- cut here ----------------------- :: Encrypted: PGP -----BEGIN PGP MESSAGE----- Version: 2.01 hEwCG6rHcT8LtDcBAf0YbKADFELfaRay6LFviabwpICAAGMV1Pff8meY3ND5o7hu jNy9hQv2bIMM9IyUCF2LFpgamxmMlSwpGQIVbJLEpgAAAEzDG0ddg2oBmjQFzB4c E0d/k7uE8KgxtCg6Sc+l639LN18sv4UWpq0nnyGRTUGEjL9JqtYZOSlTsiSAFU2c 4RoHslyk51suvGokhod0 =XSHb -----END PGP MESSAGE----- ---------------------- cut here ----------------------- The content of this file is my anonymous return address. To use it, I make my posting, anonymously, and I say something like: "Anonymous return address: mail to hal@alumni.caltech.edu, with your (possibly encrypted) message preceded by:" and I put in the contents of my anonymous return address file, above. So, to use this anonymous return address, suppose someone wants to send me this message: ---------------------- cut here ----------------------- Hello, I am responding to your anonymous post on cypherpunks. I would like to know more about your anonymous habits. Please post some more. ---------------------- cut here ----------------------- All they need to do is to put the anonymous return address at the beginning, giving: ---------------------- cut here ----------------------- :: Encrypted: PGP -----BEGIN PGP MESSAGE----- Version: 2.01 hEwCG6rHcT8LtDcBAf0YbKADFELfaRay6LFviabwpICAAGMV1Pff8meY3ND5o7hu jNy9hQv2bIMM9IyUCF2LFpgamxmMlSwpGQIVbJLEpgAAAEzDG0ddg2oBmjQFzB4c E0d/k7uE8KgxtCg6Sc+l639LN18sv4UWpq0nnyGRTUGEjL9JqtYZOSlTsiSAFU2c 4RoHslyk51suvGokhod0 =XSHb -----END PGP MESSAGE----- Hello, I am responding to your anonymous post on cypherpunks. I would like to know more about your anonymous habits. Please post some more. ---------------------- cut here ----------------------- They would then send this to hal@alumni.caltech.edu. The remailer would decrypt the PGP block, finding the "Request-Remailing-To" line, and then send it on to me. If I had posted a PGP public key along with my anonymous return address, they could have encrypted their message text as well, and put the A.R.A. in front of it. The resulting message would have looked something like: ---------------------- cut here ----------------------- :: Encrypted: PGP -----BEGIN PGP MESSAGE----- Version: 2.01 hEwCG6rHcT8LtDcBAf0YbKADFELfaRay6LFviabwpICAAGMV1Pff8meY3ND5o7hu jNy9hQv2bIMM9IyUCF2LFpgamxmMlSwpGQIVbJLEpgAAAEzDG0ddg2oBmjQFzB4c E0d/k7uE8KgxtCg6Sc+l639LN18sv4UWpq0nnyGRTUGEjL9JqtYZOSlTsiSAFU2c 4RoHslyk51suvGokhod0 =XSHb -----END PGP MESSAGE----- -----BEGIN PGP MESSAGE----- Version: 2.01 hIwCqBMDr1ghTDcBA/sGAyloGGHX/CBNRFOkov8RGNxNw/HqehwZ3yT5r0n45qAt AKmETej9GyJVFLZ5Oom7cqFN6+ARaZpp4LFqaxGF7phxC6l9HEPh2zI7w2G1/Df6 pMIwJJ7G+0vk7qBKoctmanNkYVTIb/bKAxJAbK6mUfcXPdRjyUaT/vf2X9RocKYA AAB/sjDjuW2cSN7o3HOKvQ4s+CyqshOGWe7xLRIfSBVyL2PXFOJKx7QMVdRyzDwC HO62PhXswqTlgxqIod0EXDzfEA8kI4Oz2gp45AMy8ElT1nV1jEKjCGC6HWGDU/P5 ZCTPgzOgmLetDNi5Yf8cPDMTHQ3Dcl7vDyNhpMD4+fdFog== =8FPE -----END PGP MESSAGE----- ---------------------- cut here ----------------------- The first PGP message is my anonymous return address, and the 2nd PGP message (which the remailer won't try to decrypt) is the encrypted message for me. If more people will implement cryptographic remailers, you will be able to create more secure ARA's which are "nested" so that they go through two or more remailers, and no one remailer will see the correspondence between your ARA and your real address. How might you use an ARA? You could create a pseudonym, and a public key corresponding to it. You could post anonymously, using our current remailers, to this list or another list. You could sign your messages using the public key of your pseudonym, so no one else could pretend to be you. And you could put an ARA into your messages so people could reply to you. They could reply anonymously if they wanted to, and could supply you with an ARA of their own. People could communicate freely under their online net identities, with cryptographic protection of their True Names, a la Vernor Vinge. Hal P.S. Here again is the public key of the remailer at . -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.01 mQBNAisCtU0AAAEB/jNOYzN1B2YzOxlK/Zb6axoOaGlPq5I7DV9GH3hcGRN5N6Fi T4sRLhi53Sc5rUdYDa8mFQd4tqvFG6rHcT8LtDcABRG0KlJlbWFpbGluZyBTZXJ2 aWNlIDxoYWxAYWx1bW5pLmNhbHRlY2guZWR1Pg== =K00H -----END PGP PUBLIC KEY BLOCK----- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Fri, 13 Nov 92 08:47:10 PST To: hughes@soda.berkeley.edu Subject: Rander box In-Reply-To: <9211130920.AA27066@soda.berkeley.edu> Message-ID: <9211131639.AA23711@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: Eric Hughes >Some simplifications I might suggest: >For a dedicated random number generator with low bandwidth, there's >not much reason for variable baud rate. I'd use a fixed baud rate of, >say 1200, or even 300. I strongly disagree -- you really want to be able to do as high a bandwidth as possible. You might think we don't need one time pads ever anymore, but they are still the one and only provably absolutely secure method out there -- thus, sources of large numbers of random bits are going to be of use. >> When switched on, and a "cr" (or some other character) is sent to it, >>random bytes will stream out continiously. >I'd just make the thing spew continuously. It's not like you're >losing real, er, information if you ignore a few random bits. This >way you don't need the added circuitry for switching on and off. Bad idea. If I hooked it up to my workstation, I'd end up spending lots of CPU on the thing and possibly get nasty problems with buffers filling. Not everything on earth is a PC that will ignore the interrupts if the port isn't in use, you know. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Fri, 13 Nov 92 08:47:19 PST To: avalon@coombs.anu.edu.au Subject: Datalink encryption In-Reply-To: <9211131022.AA20601@coombs.anu.edu.au> Message-ID: <9211131640.AA23728@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: avalon@coombs.anu.edu.au (Darren Reed) >Hi, I've started playing around with doing encryption with telnet/telnetd >again (I'm cheating and using the rsa/prime number code from pgp-2.0) >and I'm stuck on what to use as the encryption for the actual flow of data. >(hmm...if it works for telnet/telnetd, it can probably be made to work for > the other r-daemons too :-) >The idea is telnet and telnetd each choose an rsa pub & sec key, then use >rsa to encode a key for the encryption scheme which both ends send and >then use that for the base of the link encryption. Use IDEA; its sitting right in the PGP code. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Bob Stratton Date: Fri, 13 Nov 92 09:14:22 PST To: pmetzger@shearson.com Subject: Re: DC 2600 mtg Message-ID: <9211131211.AA10662@horton.intercon.com> MIME-Version: 1.0 Content-Type: text/plain > Date: Fri, 13 Nov 92 10:39:23 EST > From: pmetzger@shearson.com (Perry E. Metzger) > In-Reply-To: Bob Stratton's message of Thu, 12 Nov 1992 14:25:32 -0500 < > 9211121425.AA32211@horton.intercon.com> Subject: DC 2600 mtg > > Pardon, but isn't 2600 magazine a magazine by crackers for crackers? > 2600 is named after frequency of the disconnect tone used in blue > boxes, isn't it? What I'm afraid of is that I will get confused with one > of them -- I'm not sure they are necessarily being misrepresented. In the case of the recent Washington Post article, I know for a fact that they're being misrepresented. I am one of the original attendees of that gathering, and I've been a professional in the computer industry for the past 9 years, not some rodent cracker downloading /etc/passwd files. Most of the people regularly attending that gathering are not involved in illicit acticity, but rather are computer and radio hobbyists, and in many cases are employed in those fields. I can personally attest to the fact that most of the discussions involve new hardware (announcements and purchases), and people's social lives. I'll grant you that 2600 frequently publishes items from miscreants, but the publisher's consistent goal has been to raise public awareness of the risks of various technologies, and their social side-effects. Unfortunately, the media environment in the country seems more oriented to hysteria and glossing over facts. > The tragedies come when idiots raid Steve Jackson Games and sieze > copies of "Cyberpunk" instead of shutting down the infants breaking into > TRW. Blurring the distinction between hackers and crackers is the last > thing we need. That's my point exactly - the media has all but abolished the distinction. They'd rather incite fear of the technically knowledgeable than educate the populace and the legislatures. The upshot of this are things like the "all hackers break into computers" definitions we frequently read, as well as the blatant misrepresentations on the part of cellular service providers that "your calls are private because it's illegal to listen to them". The papers and TV stations don't want to hear the fact that I can take an old TV set and listen to cellular phone calls without modifying it. I spend a lot of time with younger aspiring hackers in the hopes that I can help them establish productive goals, especially as regards careers. I do this for three reasons: 1) It's more personally satisfying to be paid for a job, than to have to look over your shoulder for law enforcement types. 2) The world's a little bit safer for every cracker who gets steered into a productive career. 3) My personal experience is that many of the college graduates with CS degrees these days are code grinders with no understanding or enthusiasm for an aesthetic engineering solution. I'd much rather see people who love what they do designing the things I use every day. I don't want to get too far afield of the topic of this list, so I'll stop here, but I really do believe, based on the precedents with firearms, radio receivers (scanning and paging), and recent law enforcement proposals, that cryptographic technology will be the next example vilified in the press of "things only evil people use". Bob Stratton Engineer, InterCon Systems Corp. strat@intercon.com +1 703 709 5525 (W) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: wcs@anchor.ho.att.com (Bill Stewart) Date: Fri, 13 Nov 92 09:18:32 PST To: crunch@netcom.com Subject: Re: Rander box and other stuff Message-ID: <9211131719.AA05276@anchor.ho.att.com> MIME-Version: 1.0 Content-Type: text John Draper asked for comments on a proposed interface to the Rander box. I would recommend using different characters to start and stop the transmission; if you use one character for both it's easy to get out of sync. ^S and ^Q are traditional, of course, and hardware flow control is another option (Perry's suggestion). Of course, not everybody's machine handles hardware flow control adequately. If you've got a dip switch annyway, you may want to use one switch to choose hardware or ^S/^Q. Bill From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: anthrax@cow.com Date: Fri, 13 Nov 92 09:57:45 PST To: cypherpunks@toad.com Subject: Hackers, Crackers Message-ID: <9211131757.AA05188@atdt.org> MIME-Version: 1.0 Content-Type: text/plain Let's cut out this elitist "crackers" crap altogether. It's just a little bit too PlaySkool, a little bit too "_I'm_ not a third grader! I'm a _fourth grader_!" The people who put so much energy into advertising how they're different tend not to know what the fuck they're talking about, in my experience. >> Pardon, but isn't 2600 magazine a magazine by crackers for crackers? << Beep. Sorry. Thank you for playing. >> 2600 is named after frequency of the disconnect tone used in blue boxes, isn't it? << 2600 is named after the frequency of the disconnect signal used in the telephone system for several decades. But so what? Doesn't PGP violate patent laws (or surely come pretty close)? Why would you want to be associated with PGP and its use, then? From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: crunch@netcom.com (John Draper) Date: Fri, 13 Nov 92 13:13:30 PST To: cypherpunks@toad.com Subject: Rander box Message-ID: <9211132109.AA27735@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain >>I'd just make the thing spew continuously. It's not like you're >>losing real, er, information if you ignore a few random bits. This >>way you don't need the added circuitry for switching on and off. >Bad idea. If I hooked it up to my workstation, I'd end up spending >lots of CPU on the thing and possibly get nasty problems with buffers >filling. Not everything on earth is a PC that will ignore the >interrupts if the port isn't in use, you know. I agree, dealing with continious data streams might be problematic, but it was mentioned that we could use CTS/RTS or other lines on the connector to turn on and off the stream. Any comments on doing it this way? From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: crunch@netcom.com (John Draper) Date: Fri, 13 Nov 92 13:26:53 PST To: cypherpunks@toad.com Subject: Rander Message-ID: <9211132123.AA29207@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Eric says: >In my previous post, I mentioned powering the device from DTR. DTR, >for those of you not familiar with RS-232, is a device control line >which is separately assertable. To turn the device off, toggle DTR. >Presto! No more power, no more bits. Simple, when you know what DTR >does. So far, I think this is the best idea, and after checking out my methodology and initial circuit design, I see no reason why I cannot go as high as 9600 baud. Even the more inexpensive AD converters can achieve that speed when we only want to use 8 bits. I am toying around the idea for using an 8 bit AD converter, then its just a matter of clocking them out a UART. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: crunch@netcom.com (John Draper) Date: Fri, 13 Nov 92 13:31:29 PST To: cypherpunks@toad.com Subject: PGP portability Message-ID: <9211132127.AA29554@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain John Gilmore writes: >The last thing PGP needs is an installed base of Mac users who are >always stuck three revs back because they forked off their own wierd >version and couldn't upgrade when the rest of us do. This was why I proposed the internal "engine" concept where I keep the machine independent code intact and the GUI seperate. At the moment, I can't think of a better idea. So perhaps you can give us some suggestions towards a solution to the problem, John! From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: dmandl@shearson.com (David Mandl) Date: Fri, 13 Nov 92 11:35:30 PST To: pmetzger@shearson.com Subject: Re: DC 2600 mtg Message-ID: <9211131905.AA00246@tardis.shearson.com> MIME-Version: 1.0 Content-Type: text/plain > Perry Metzger writes: > Pardon, but isn't 2600 magazine a magazine by crackers for crackers? No. It's called "The Hacker's Quarterly" and never claims to be anything else. Eric Corley (editor/publisher) is completely above-ground. He even does a computer show on WBAI here in New York, though I haven't heard it. In fact, he was on MY radio show (WFMU) a few years ago talking about hackers. I was initially surprised that he was willing to use his real name on the show; I ended up being almost disappointed by how "apolitical" he seemed. 2600 prints plenty of articles by flamboyant young pranksters on how to break into this or that system, but rather than an editorial line or policy, this is more a result of 2600's view that all this information should be available and uncensored. These are the kinds of guys who uncover holes in multinationals' computer security and TELL THEM about it. (BTW, I'm not involved with the magazine in any way; in fact, I find most of its articles kinda uninspiring or mundane.) --Dave. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: jordan@imsi.com (Jordan Hayes) Date: Fri, 13 Nov 92 11:58:01 PST To: cypherpunks@toad.com Subject: Re: Hackers, Crackers Message-ID: <9211131918.AA17661@IMSI.COM> MIME-Version: 1.0 Content-Type: text/plain From anthrax@cow.com Fri Nov 13 14:03:27 1992 Doesn't PGP violate patent laws (or surely come pretty close)? Why would you want to be associated with PGP and its use, then? Are you saying that contributing to this mailing list (let alone *subscribing* to it) necessarily implies that one is using the PGP code? If so, take me off. /jordan From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: S.E. Brown Date: Fri, 13 Nov 92 16:07:22 PST To: cypherpunks@toad.com Subject: The legality of PGP Message-ID: <9211140007.AA19365@toad.com> MIME-Version: 1.0 Content-Type: text/plain Well, I've been reading a lot of speculation and outright disinformation about the legality of PGP. Does anyone have any informed information about the actual legal status us sing and disseminating the program? Gratis My SuperIllegal Key : -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAirSjlcAAAED/ijVaTjlU62mQdXwxj+bEO3wqdMKkZlRNt1rSi8VOSkeQ0G7 7KbBeINoVCTIi12ax74q7ANhKCga+ZkBxAVTnfSBQZXfFh/5XMxzzqk7NT2fKKlZ /Hrf4cDd8VYgSl6WPhyVO+EpvyZn5HezGLBbryGpCcloSmjBcwd2g1pYVIhjAAUR tCxTLkUuIEJyb3duIDxzaGF3bmJAY3NjaWhwLmVjc3QuY3N1Y2hpY28uZWR1Pg== =Wrv7 -----END PGP PUBLIC KEY BLOCK----- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: schwarte@CS.ColoState.EDU (eric schwartz) Date: Fri, 13 Nov 92 16:47:32 PST To: cypherpunks@toad.com Subject: Re: Take You Off Message-ID: <9211140047.AA02325@beethoven> MIME-Version: 1.0 Content-Type: text/plain > > >> > Are you saying that contributing to this mailing list (let alone > *subscribing* to it) necessarily implies that one is using the PGP > code? > > > If so, take me off. > << > > As a counter to that, would you or Perry necessarily imply that > subscribing to a "KrAcKeR" magazine makes you an evil > "KrAcKeR"? > > Anyway, if you can figure out the unix commands to navigate through > your mail-box, then you should have just enough intelligence > not to have jumped to any short-sided conclusions like the one > you proposed above. > > Then again, I could be wrong. > Then again, you could be missing his (albeit subtly) sarcastic point, which is exactly what you just said. Sheesh. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Fri, 13 Nov 92 19:23:48 PST To: cypherpunks@toad.com Subject: re: (fwd) A Silver Bullet to Limit Crypto? Message-ID: <3613.2B045BBE@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain U> From: pmetzger@shearson.com (Perry E. Metzger) U> I don't see what the point of putting out mediocre things U> is at all, given that good things exist. PGP is free U> software. You need a good RSA implementation? There is one U> out there already. Why put out crap when gold is available U> and cheap? I don't think anyone has a desire to put bad things out there. My comments were assuming the real-life context of FidoNet, where we have a need to get people thinking about privacy, security, etc, and our relationships and responsibilities to each other. We *are* using PGP, which seems to be good software. Any "mediocrity" or inherent flaws I was referring to were in key systems, and suchlike. The social environment in FidoNet is completely different from here. There will never be any directed training or committees to define what a "proper" way to handle keys is, and even if there was, the newbie sysop coming online in East Overshoe Alaska wouldn't even hear about it, and would install what s/he finds available on the net. All of our social/technical systems assume this chaotic environment. It makes for some ahem interesting problems, but the robustness and growth and innovation are pretty hot. --- ReadMail * Origin: tomj@fidosw.fidonet.org / World Power Systems (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET - Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Fri, 13 Nov 92 19:23:25 PST To: cypherpunks@toad.com Subject: re: Rander box and other stuff Message-ID: <3612.2B045BBD@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain U> From: crunch@netcom.com (John Draper) U> I think I have a rough description of the hardware U> serial random generator I want to build. I want to call U> it the "Rander box" for lack of a better name. Using serial ports is probably not a good idea on PC clones. The IBM hardware design limits a machine to two ports comfortably, four practical maximum. Any machine that uses telecomm. (BBSs, etc) will have to consume the serial hardware, and will interfere with whatever you have to do. A good choice would be a parallel port, ie. a printer port. The IBM design allows 4 or more easily, and rarely do you see a pclone with more than two printers attached. If there isn't a spare port available, Fry's sells printer adapters for $19.95. Late-model printer adapters are 8 bit in and out, and are capable of Ethernet speeds. The parallel port uses standard busy/done and TTL levels. (For a "universal" serial version, you could internally have the 8 bit busy/done interface drive a UART. I bet simply fixing the data rate to 9600 baud would work.) U> When switched on, and a "cr" (or some other U> character) is sent to it, random bytes will stream out U> continiously. Another "cr" will stop the byte stream. U> At least this is ONE approach. If anyone can think of a U> better way, Pse speak up. I was about to say "prolly not necessary", but others make valid points... XON/XOFF, DTR, etc are all workable... DTR is compat w/serial and parallel too. On a pclone, producing bits continuously is easier. When not in use, the driver will dump bits onto the floor. Fancy (software) drivers could spool the bits into a nice big pile ("every bit is sacred..."). A simple driver could simply have say 10,000 bits, and continuously overwrite the oldest (wrap around the buffer...) --- ReadMail * Origin: tomj@fidosw.fidonet.org / World Power Systems (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET - Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: anthrax@cow.com Date: Fri, 13 Nov 92 15:41:16 PST To: jordan@imsi.com Subject: re: Take you off Message-ID: <9211132341.AA06610@atdt.org> MIME-Version: 1.0 Content-Type: text/plain >> Are you saying that contributing to this mailing list (let alone *subscribing* to it) necessarily implies that one is using the PGP code? If so, take me off. << As a counter to that, would you or Perry necessarily imply that subscribing to a "KrAcKeR" magazine makes you an evil "KrAcKeR"? Anyway, if you can figure out the unix commands to navigate through your mail-box, then you should have just enough intelligence not to have jumped to any short-sided conclusions like the one you proposed above. Then again, I could be wrong. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: S.E. Brown Date: Fri, 13 Nov 92 18:44:10 PST To: cypherpunks@toad.com Subject: PGP 2.01 2.02 Message-ID: <9211140244.AA22290@toad.com> MIME-Version: 1.0 Content-Type: text/plain Where can the latest revisions of PGP be found? Tried the sci.crypt archive site, but the just had 2.0. Can anyone help? BTW, here's my key: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAirSjlcAAAED/ijVaTjlU62mQdXwxj+bEO3wqdMKkZlRNt1rSi8VOSkeQ0G7 7KbBeINoVCTIi12ax74q7ANhKCga+ZkBxAVTnfSBQZXfFh/5XMxzzqk7NT2fKKlZ /Hrf4cDd8VYgSl6WPhyVO+EpvyZn5HezGLBbryGpCcloSmjBcwd2g1pYVIhjAAUR tCxTLkUuIEJyb3duIDxzaGF3bmJAY3NjaWhwLmVjc3QuY3N1Y2hpY28uZWR1Pg== =Wrv7 -----END PGP PUBLIC KEY BLOCK----- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tom.jennings@f111.n125.z1.FIDONET.ORG (tom jennings) Date: Fri, 13 Nov 92 19:23:56 PST To: cypherpunks@toad.com Subject: 1/3 Cryptography bibliography Message-ID: <3615.2B0467B1@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain * Forwarded by Rich Veraa To: All Message #: 365 From: Ed Beroset Submitted: 10 Nov 92 20:34:38 Subject: 1/3 cryptographic bibliog Status: Public Received: ** New Message Read! ** Group: 80XXX (17) I'm sorry it took me a little longer than I had anticipated to put together this list, but I think you'll find it worth while. This is a list of books which deal with various aspects of cryptography (including DES, RSA, and many other schemes and topics.) They're organized roughly in reverse chronological order, with newer texts toward the top of the list. TITLE : Cryptography : a new dimension in computer data security : a guide for the design and implementation of secure systems / AUTHOR: Meyer, Carl H. IMPR : New York : Wiley, 1982. TITLE : Traffic analysis and the Zendian problem : an exercise in communications intelligence operations / AUTHOR: Callimahos, Lambros D. IMPR : Laguna Hills, Calif. : Aegean Park Press, c1989. TITLE : Military communications : a test for technology / AUTHOR: Bergen, John D., 1942-. IMPR : Washington, D.C. : Center of Military History, U.S. Army : For sale by the Supt. of Docs., U.S. G.P.O., 1986. TITLE : Principles of secure communication systems / AUTHOR: Torrieri, Don J. IMPR : Dedham, MA : Artech House, c1985. TITLE : Contemporary cryptology : the science of information integrity / IMPR : Piscataway, NJ : IEEE Press, c1992. TITLE : Public-key cryptography : state of the art and future directions : E.I.S.S. workshop, Oberwolfach, Germany, July 3-6 1991 : final report / IMPR : Berlin ; New York : Springer-Verlag, 1992. TITLE : Advances in cryptology--EUROCRYPT '91 : Workshop on the Theory and Application of Cryptographic Techniques, Brighton, UK, April 8-11, 1991 : proceedings / AUTHOR: EUROCRYPT '91 (1991 : Brighton, England) IMPR : Berlin ; New York : Springer-Verlag, c1991. TITLE : United States cryptographic patents, 1861-1989 / ED : [2nd ed.] AUTHOR: Levine, Jack, 1907-. IMPR : Terre Haute, Ind. : Cryptologia, 1991. TITLE : Geometries, codes and cryptography / IMPR : Wien ; New York : Springer-Verlag, c1990. TITLE : Number theory and cryptography / IMPR : Cambridge ; New York : Cambridge University Press, 1990. TITLE : Cryptography : an introduction to computer security / AUTHOR: Seberry, Jennifer, 1944-. IMPR : New York : Prentice-Hall, c1989. TITLE : Codes and cryptography / AUTHOR: Welsh, D. J. A. IMPR : Oxford [Oxfordshire] : Clarendon Press ; New York : Oxford University Press, 1988. TITLE : Crypto users' handbook : a guide for implementors of cryptographic protection in computer systems / IMPR : Amsterdam [The Netherlands] ; New York : North-Holland ; New York, N.Y., U.S.A. : Sole distributors for the U.S.A. and Canada, Elsevier Science Pub. Co., 1988. TITLE : An introduction to cryptology / AUTHOR: Tilborg, Henk C. A. van, 1947-. IMPR : Boston : Kluwer Academic Publishers, c1987. TITLE : Modern cryptology : a tutorial / AUTHOR: Brassard, Gilles, 1955-. IMPR : New York : Springer-Verlag, c1988. TITLE : A course in number theory and cryptography / AUTHOR: Koblitz, Neal, 1948-. IMPR : New York : Springer-Verlag, c1987. TITLE : Cryptology yesterday, today, and tomorrow / IMPR : Norwood, MA : Artech House, c1987. TITLE : Mathematical cryptology for computer scientists and mathematicians / AUTHOR: Patterson, Wayne, 1945-. IMPR : Totowa, N.J. : Rowman & Littlefield, 1987. TITLE : Analysis and design of stream ciphers / AUTHOR: Rueppel, Rainer A., 1955-. IMPR : Berlin ; New York : Springer-Verlag, c1986. TITLE : Primality and cryptography / AUTHOR: Kranakis, Evangelos. IMPR : Stuttgart : Teubner ; Chichester [Sussex] ; New York : Wiley, c1986. -+--- continued next message ----- --- XAP 1.02+ * Origin: the birds round about are against her; (1:135/907) -- tom jennings - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!111!tom.jennings INTERNET - tom.jennings@f111.n125.z1.FIDONET.ORG rom fidogate!f111.n125.z1.FIDONET.ORG!tom.jennings@kumr.lns.com Fri Nov 13 19:23:59 1992 Return-Path: Received: from kumr.lns.com by toad.com id AA23114; Fri, 13 Nov 92 19:23:59 PST Received: by kumr.lns.com (/\==/\ Smail3.1.25.1 #25.3) id ; Fri, 13 Nov 92 18:57 PST Received: by fidogate.FIDONET.ORG (mailout1.26); Fri, 13 Nov 92 18:42:59 PDT Date: Fri, 13 Nov 92 18:56:32 PDT Message-Id: <3616.2B0467B3@fidogate.FIDONET.ORG> From: tom.jennings@f111.n125.z1.FIDONET.ORG (tom jennings) Subject: 2/3 Cryptography bibliography To: cypherpunks@toad.com X-Mailer: mailout v1.26 released * Forwarded by Rich Veraa To: All Message #: 366 From: Ed Beroset Submitted: 10 Nov 92 20:34:38 Subject: 2/3 cryptographic bibliog Status: Public Received: ** New Message Read! ** Group: 80XXX (17) RE: 2/3 cryptographic bibliography -+--- continued from previous message ----- TITLE : Two issues in public-key cryptography : RSA bit security and a new knapsack type system / AUTHOR: Chor, Ben-Zion. IMPR : Cambridge, Mass. : MIT Press, c1986. TITLE : Kryptologie / AUTHOR: Horster, Patrick. IMPR : Mannheim : Bibliographisches Institut, c1985. LANG : German TITLE : Machine cryptography and modern cryptanalysis / AUTHOR: Deavours, Cipher A. IMPR : Dedham, MA : Artech House, c1985. TITLE : Cryptanalysis of shift-register generated stream cipher systems / AUTHOR: Barker, Wayne G. IMPR : Laguna Hills, Calif. : Aegean Park Press, c1984. TITLE : Applied cryptology, cryptographic protocols, and computer security models. IMPR : Providence, R.I. : American Mathematical Society, c1983. TITLE : Secure digital communications / IMPR : Wien ; New York : Springer-Verlag, c1983. TITLE : Cipher systems : the protection of communications / AUTHOR: Beker, Henry. IMPR : New York : Wiley, c1982. TITLE : Codes, ciphers, and computers : an introduction to information security / AUTHOR: Bosworth, Bruce. IMPR : Rochelle Park, N.J. : Hayden Book Co., c1982. TITLE : Cryptography and data security / AUTHOR: Denning, Dorothy Elizabeth Robling, 1945-. IMPR : Reading, Mass. : Addison-Wesley, c1982. TITLE : Secure communications and asymmetric cryptosystems / IMPR : Boulder, Colo. : Published by Westview Press for the American Association for the Advancement of Science, 1982. TITLE : Cryptography, a primer / AUTHOR: Konheim, Alan G., 1934-. IMPR : New York : Wiley, c1981. TITLE : The origin and development of the National Security Agency / AUTHOR: Brownell, George A. IMPR : Laguna Hills, Calif. : Aegean Park Press, 1981. UNI-TI: Traite de cryptographie. English. TITLE : Treatise on cryptography / AUTHOR: Langie, Andre, 1871-. IMPR : Laguna Hills, Calif. : Aegean Park Press, c1981. TITLE : Cryptanalysis of an enciphered code problem : where an "additive" method of encipherment has been used / AUTHOR: Barker, Wayne G. IMPR : Laguna Hills, Calif. : Aegean Park Press, c1979. UNI-TI: Chifferbyraernas insatser i varldskriget till lands. English. TITLE : The contribution of the cryptographic bureaus in the World War / AUTHOR: Gylden, Yves. IMPR : Laguna Hills, Calif. : Aegean Park Press, c1978. TITLE : The protection of data by crytography / AUTHOR: Davies, (Donald Watts) IMPR : Middlesex : National Physical Laboratory, 1978. TITLE : Cryptanalysis of the Hagelin cryptograph / AUTHOR: Barker, Wayne G. IMPR : Laguna Hills, Calif. : Aegean Park Press, c1977. UNI-TI: Manuale di crittografia. Italian. TITLE : Manual of cryptography / AUTHOR: Sacco, Luigi. IMPR : Laguna Hills, Calif. : Aegean Park Press, c1977. TITLE : Pattern-word list / AUTHOR: Lynch, Frederick D. IMPR : Laguna Hills, Calif. : Aegean Park Press, c1977-. -+--- continued next message ----- --- XAP 1.02+ * Origin: If at first you don't succeed, try, try a bird. (1:135/907) -- tom jennings - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!111!tom.jennings INTERNET - tom.jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tom.jennings@f111.n125.z1.FIDONET.ORG (tom jennings) Date: Fri, 13 Nov 92 19:24:04 PST To: cypherpunks@toad.com Subject: 3/3 Cryptography bibliography Message-ID: <3617.2B0467B4@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain * Forwarded by Rich Veraa To: All Message #: 367 From: Ed Beroset Submitted: 10 Nov 92 20:41:08 Subject: 3/3 cryptographic bibliog Status: Public Received: ** New Message Read! ** Group: 80XXX (17) -+--- continued from previous message ----- TITLE : Advanced military cryptography / AUTHOR: Friedman, William Frederick, 1891-. IMPR : Laguna Hills, Calif. : Aegean Park Press, c1976. TITLE : Elementary military cryptography / AUTHOR: Friedman, William Frederick, 1891-. IMPR : Laguna Hills, Calif. : Aegean Park Press, c1976. TITLE : Elements of cryptanalysis / AUTHOR: Friedman, William Frederick, 1891-. IMPR : Laguna Hills, Calif. : Aegean Park Press, c1976. TITLE : Statistical methods in cryptanalysis / ED : [Rev. ed.] AUTHOR: Kullback, Solomon. IMPR : Laguna Hills, Calif. : Aegean Park Press, c1976. TITLE : Mathematical recreations & essays / ED : 12th ed. AUTHOR: Ball, Walter William Rouse, 1850-1925. IMPR : Toronto ; Buffalo : University of Toronto Press, [1974] TITLE : Elementary cryptanalysis; a mathematical approach. AUTHOR: Sinkov, Abraham, 1907-. IMPR : [New York] Random House [c1968] -+--- end of listing ----- I think that you'll find there's a lot more useful information out there, just waiting for you at your public library. The U.S. Government can also be a useful source of information, as are trade and technical journals and hobbyist magazines. -> Ed <- --- XAP 1.02+ * Origin: two birds alive and clean, (1:135/907) -- tom jennings - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!111!tom.jennings INTERNET - tom.jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Fri, 13 Nov 92 18:59:39 PST To: shawnb@ecst.csuchico.edu Subject: PGP 2.01 2.02 In-Reply-To: <9211140244.AA22290@toad.com> Message-ID: <9211140259.AA12754@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain As of now, PGP 2.0 is the current version. A newer one will be out shortly (it's being tested). The list will certainly be the first to know. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: avalon@coombs.anu.edu.au (Darren Reed) Date: Fri, 13 Nov 92 02:22:34 PST To: cypherpunks@toad.com Subject: Datalink encryption Message-ID: <9211131022.AA20601@coombs.anu.edu.au> MIME-Version: 1.0 Content-Type: text/plain Hi, I've started playing around with doing encryption with telnet/telnetd again (I'm cheating and using the rsa/prime number code from pgp-2.0) and I'm stuck on what to use as the encryption for the actual flow of data. (hmm...if it works for telnet/telnetd, it can probably be made to work for the other r-daemons too :-) The idea is telnet and telnetd each choose an rsa pub & sec key, then use rsa to encode a key for the encryption scheme which both ends send and then use that for the base of the link encryption. Whatever I use for encryption of the session data has to work quickly and efficiently and I've got little idea about what to use/how to and would like some opinions on what would make a good choice. Any suggestions ? (Xor seems a possibility but straight Xor is very easy to break). I hope I'm not duplicating work that has already been done :) cheers, Darren From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hollander Date: Fri, 13 Nov 92 22:38:47 PST To: Tom.Jennings@f111.n125.z1.fidonet.org (Tom Jennings) Subject: Re: Rander box and other stuff In-Reply-To: <3612.2B045BBD@fidogate.FIDONET.ORG> Message-ID: <9211140637.AA25631@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain All of these designs leave us Mac users a bit out in the cold. My powerbook 100 has one lonely little serial port and no parallel port. Desktop macs usually have two serial ports, and it's not easy to add more. For us powerbook users (and also for users of other notebooks), we want something which is internal. It's horible to have little things dangling off of your nice little notebook. They inevitably get pulled out, etc. Basically it seems to me that a good solution would be to use some type of serial device for Unix type machines, and then work on a series of cards for IBM clones and notebooks. How about a random bit device on one of those little cards that most of the newer notebooks have? I forget the name of the standard for that, but lots of them use it now. e From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: simsong@next.cambridge.ma.us (Simson L. Garfinkel) Date: Fri, 13 Nov 92 22:24:49 PST To: crunch@netcom.com (John Draper) Subject: Re: Rander Message-ID: <9211140619.AA11189@next.cambridge.ma.us> MIME-Version: 1.0 Content-Type: text/plain Perhaps I'm just out of the loop, but what do you intend to do with your stream of random numbers? You going to send a tape to your friends under armed guard? Just curious. Oh, I built a hardware random number generator a few years ago for some ESP experiments I was doing. I wanted to see if computer hackers had better odds of affecting the output of a RNG than non-hackers. (You know, the hacker walks into the room and suddenly the broken piece of equipment starts working?) Turns out they can. -simson From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: crunch@netcom.com (John Draper) Date: Sat, 14 Nov 92 01:23:48 PST To: cypherpunks@toad.com Subject: Rander Message-ID: <9211140920.AA01475@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Tom Jennings writes: >Using serial ports is probably not a good idea on PC clones. The IBM >hardware design limits a machine to two ports comfortably, four >practical maximum. Any machine that uses telecomm. (BBSs, etc) will >have to consume the serial hardware, and will interfere with whatever >you have to do. >A good choice would be a parallel port, ie. a printer port. The IBM >design allows 4 or more easily, and rarely do you see a pclone with >more than two printers attached. If there isn't a spare port >available, Fry's sells printer adapters for $19.95. Late-model printer >adapters are 8 bit in and out, and are capable of Ethernet speeds. >The parallel port uses standard busy/done and TTL levels. I already thought of that, but it would make it difficult to work on other platforms. Tom also writes: >A simple driver could simply have say 10,000 bits, and continuously >overwrite the oldest (wrap around the buffer...) This was (and probably still is) my overall intention. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Sat, 14 Nov 92 04:11:21 PST To: hughes@soda.berkeley.edu Subject: Re: Rander box Message-ID: <199211141210.AA21995@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Re Eric's quote of me agreeing with him that OTPs are "expensive to make relative to other forms of security." A point of clarification seems in order. I do agree that OTPs are more expensive and less convenient to use than PKSs. However, I also believe that the public interest would *best* be served by having *many* different kinds of cyphers available, including OTPs, PKSs, and various conventional cyphers, historic cyphers with relatively little current security value (for educational purposes) and so on. The main advantages of OTPs are provable absolute security and the fact that the basic technique is so straightforward that it probably could never be banned and put out of circulation. The time may come when we *need* OTPs, and we ought to have them ready beforehand, and have them in use in appropriate situations long before any crisis comes (to gain operational experience which could lead to improvements). With regard to PGP, I am not sure what the copyright status is on that one; and if there is any doubt about it, the govt could screw a lot of people to the wall on copyright-related charges if they so chose. I would like it very very much if PGP was free & clear public domain. The last thing we need is for the first warning of tyrrany to be a wave of hardware seizures on the grounds of having unauthorised copies of copyrighted material. Now I may be off base on this point, but the key here is the idea that many different kinds of cyphers, like many different varieties of plants and animals, make for a robust ecosystem which can't be wiped out by one plague. -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: jordan@imsi.com (Jordan Hayes) Date: Sat, 14 Nov 92 06:59:01 PST To: cypherpunks@toad.com Subject: Re: Rander box and other stuff Message-ID: <9211141425.AA00660@IMSI.COM> MIME-Version: 1.0 Content-Type: text/plain Hey, I have a PowerBook too, but don't say you're limited to one serial port. You could use the desktop bus, and there are extenders available. I do agree that a parallel box wouldn't do me much good on my Sparc. For a while, my IPX was my "portable" computer, albeit with monitors on both coasts. But the box itself is quite lugable. If I wanted to, I could plug it in along the hallways of airports and use a palmtop with a serial connection to read mail and up/down load ... /jordan From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Sat, 14 Nov 92 10:55:08 PST To: cypherpunks@toad.com Subject: "Cryptodiversity" and Foiling the "Key Grabbers" In-Reply-To: <199211141210.AA21995@well.sf.ca.us> Message-ID: <9211141851.AA05846@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain George Gleason argues for having and using several types of cryptosystems, a kind of "cryptodiversity." He writes: > I do agree that OTPs are more expensive and less convenient to use than > PKSs. However, I also believe that the public interest would *best* be > served by having *many* different kinds of cyphers available, including > OTPs, PKSs, and various conventional cyphers, historic cyphers with > relatively little current security value (for educational purposes) and so > on. The main advantages of OTPs are provable absolute security and the fact > that the basic technique is so straightforward that it probably could never > be banned and put out of circulation. The time may come when we *need* > OTPs, and we ought to have them ready beforehand, and have them in use in > appropriate situations long before any crisis comes (to gain operational > experience which could lead to improvements). .......... > on the grounds of having unauthorised copies of copyrighted material. Now I > may be off base on this point, but the key here is the idea that many > different kinds of cyphers, like many different varieties of plants and > animals, make for a robust ecosystem which can't be wiped out by one plague. A great idea. Getting several forms of crypto out there is a good insurance policy. The problem I see is that no system, be it OTP or something else, is likely to get much penetration in the market. PGP has taken off, but another system will face an uphill battle unless it is very well-written, very easy to use, and/or fills some special need. Still, I want to encourage George to pursue this (somehow). I have a CD-ROM on my Mac, but I doubt it'll be practical to burn CD-ROMs economically (one service wants $200 for one CD-ROM, with a second one for nominally more...and note that such a service is an obvious security hole). 128 MB magneto-opticals may be a better bet, though few folks have them. In terms of programming energy, vis-a-vis a point John Gilmore made recently about adding to the PGP effort, I'm sure enhancing PGP by integrating it into standard mailers (yes, I'm aware of the security holes here, too) would be even more beneficial to cryptodiversity, just in the sense of getting the volume of encrypted traffic way up. A good Mac version would also help, of course. And to head off the "key grabbers," developing steganographic methods to hide our encrypted bitstreams inside innocuous GIF files and the like (as I have written about before) may be useful. --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: awaiting Macintosh version. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Sat, 14 Nov 92 11:15:08 PST To: cypherpunks@toad.com Subject: Re: Rander box and other stuff Message-ID: <9211141911.AA08123@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Eric Hollander writes: > All of these designs leave us Mac users a bit out in the cold. My powerbook > 100 has one lonely little serial port and no parallel port. Desktop macs > usually have two serial ports, and it's not easy to add more. > > For us powerbook users (and also for users of other notebooks), we want > something which is internal. It's horible to have little things dangling > off of your nice little notebook. They inevitably get pulled out, etc. Maybe I'm being crypto-dense, but why would individual Powerbook 100 users care so much about generating the bits in the volumes that a hardware-based RNG is designed to supply? For filling a CD-ROM (600 MB) with good random bits, I can see the need for a back-biased diode source (such as Tony Patti's widget), but such filling of a CD-ROM presumes a fair amount of other stuff, like the CD-ROM burners, etc. I can't imagine a PB 100 user, and I'm one of them, developing OTPs on CD-ROMs on the PowerBook. For generating PGP keys, the keyboard timing methods work quite well, as several folks have pointed out. Maybe for some of the dynamic key generation applications that will be appearing in the next couple of years such a hardware RNG will be useful (so that the bits can be generated in the absence of a human operator, and at higher rates). But I don't see them needed immediately, and certainly not on a PowerBook. (No insult to the PowerBook, it's just that I can't see Eric Hughes' and Hal Finney's remailer running on such a platform, for obvious reasons.) Am I missing something? --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: awaiting Macintosh version. -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: awaiting Macintosh version. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: crunch@netcom.com (John Draper) Date: Sat, 14 Nov 92 14:02:15 PST To: cypherpunks@toad.com Subject: Some organizational trivia to consider Message-ID: <9211142158.AA23080@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain I will be "off line" for a few days now, as I have to do some work to help out an old friend. I'll be back "on line" sometime late Tuesday, and hopefull will have formulated some organizational plan to propose to the group. In the meantime, start thinking about how we can organize "on line" meetings (Or even meetings in person) to hammer out some type of plan. Someone mentioned a meeting to be taken place later, is this meeting for the Cypherpunks project? My involvement at this point will be that of an adviser, and perhaps pump in some ideas to the group. As the host of the Programmers Netsork, I am experienced at setting up organizational groups, but often these groups tend to "fizzle out" as people have other time committments, so it's important that we try and work out a mechanism for "passing the torch" when one person has to bow out for some reason. My recommendation is to set up an FTP site where one can download the latest organizational plan, people involved, who is doing what, etc, and keep this info updated on a regular basis. I don't recommend that just ONE person do this, it has to be done by several people in the event one (or more) have to drop out for some reason. In the meantime, just be thinking about the following: a) Setting up a cypherpunks FTP site to contain organizational info, latest source code, who is doing what, and a list of things that need to be done. b) Maintaining a SOurce code control mechanism whereby people can "check out" code modules and work in parallel towards a common goal. c) Provide periodic updates by posting important info to the rest of Cyberspace via UseNet or other on-line systems. Till next Tuesday, take care Y'all.... See U in Cypherspace next Tues Cheers John Draper crunc@netcom.com crunch@well.sf.ca.us From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Sat, 14 Nov 92 16:27:09 PST To: tcmay@netcom.com Subject: Re: Rander box and other stuff Message-ID: <199211150026.AA01440@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain I have a question regarding the ideas which have been circulating about using CD ROMs as key storage. How does one go about rapidly and effectively erasing everything on a CD ROM? The reason I ask is, in the case of OTPs you want to cancel your key as it's used, to prevent accidental double-use of key; and of course in any system you want to make sure that all your crypto material can be wiped squeaky clean in the event of a barbarian invasion. -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Sat, 14 Nov 92 17:30:13 PST To: crunch@netcom.com (John Draper) Subject: Re: Some organizational trivia to consider In-Reply-To: <9211142158.AA23080@netcom2.netcom.com> Message-ID: <9211150126.AA08860@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain > Till next Tuesday, take care Y'all.... See U in Cypherspace next Tues > > Cheers > John Draper "Cypherspace" is a _great_ name! Thanks, John. --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: awaiting Macintosh version. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Sat, 14 Nov 92 18:22:36 PST To: cypherpunks@toad.com Subject: What's More Important? Message-ID: <9211150219.AA12711@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain I try to never say on lists or newsgroups that some subject is inappropriate, or boring, has already been beaten to death, etc. Instead, I figure it's up to others to make this choice. I can always ignore threads that don't interest me. But let me confess I'm mystified as to why the subject of random number generators (and CD-ROMs filled with them) is getting so much attention while Hal Finney's remarkable post on his work toward a fully-encrypted remailer (allowing digital pseudonyms) has received no discussion whatsover! Random number generators, in software and in hardware, pop up in discussions on sci.crypt every couple of months or so. Every argument made here, every basic question, etc., has already come up several times in just past year! Furthermore, and I don't mean to sound chiding or condescending, one-time pads are fundamentally not the way to go. Yes, I know that I just applauded George Gleason's cryptodiversity idea...but I see the stark contrast between the dozens of postings on RNGs, Rander, one-time pads, and CD-ROMs and the utter lack of postings about Hal's remailer...and I am chagrined. Granted, Hal's system is hard to follow. This is another area where some diagrams would help immensely, especially drawn on a blackboard. But anonymous remailing is where cypherpunks need to be. --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: awaiting Macintosh version. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Keith Basil Date: Sat, 14 Nov 92 16:15:04 PST To: cypherpunks@toad.com Subject: cypherpunks mail list. Message-ID: <9211150014.AA14236@penda.cs.odu.edu> MIME-Version: 1.0 Content-Type: text/plain i'd like to be added to the list. thanks. keith From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Sun, 15 Nov 92 00:42:09 PST To: tcmay@netcom.com Subject: Re: What's More Important? Message-ID: <199211150841.AA06938@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain I suspect the reason why anon remailers haven't gotten their due, and OTPs are getting so much press here, is that anon remailers are being developed locally and the development problems for these are straightforward, whereas good RNGs for OTPs are a sort of sticky technical issue which seems to call for a lot of debate. You don't see anyone debating the **software** for OTPs now, do you...? And I do agree, anon remailers are absolutely vital in the overall scheme of things. If for no other reason, to stop or hinder traffic analysis, which is a way more powerful form of signals intelligence than most people realise. -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nobody@alumni.cco.caltech.edu Date: Sun, 15 Nov 92 03:17:12 PST To: cypherpunks@toad.com Subject: test message Message-ID: <9211151118.AA09055@alumni.cco.caltech.edu> MIME-Version: 1.0 Content-Type: text/plain This is an un-encrypted test message. Please ignore. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: oren@apple.com Date: Sun, 15 Nov 92 13:42:22 PST To: cypherpunks@toad.com Subject: Re: Apple including PKS? Message-ID: <9211152141.AA24753@apple.com> MIME-Version: 1.0 Content-Type: text/plain >Re: Apple include a PKS with their Macs > >Well, Apple does have a site license for RSA. Tim Oren, who's on the >list, knows more about this than I. I ask him to respond. > >Maybe Apple could license the PGP code as a system utility? > >Eric Apple does have a license from RSA, which includes both site and redistribution rights. The intent is to make security-enhanced features available in something called OCE (Open Collaboration Environment) which is to be Apple's entry in the E-mail / user directory / etc. marketplace. OCE is likely to be an add-on, that is, something not shipped with every Mac, but available at extra cost. Since I'm under NDA for the details of OCE, I will simply quote what MacLeak says: According to MacWeek, Apple is using RSA software with 150-200 digit primes for Digital Signatures. They are using "RSA's RC4 algorithm [which will] provide encryption of the fly for data transmitted across an OCE (open Collaboratioon Environment) network. Each message will be scrambled using a unique 64-bit key. BTW, notice that's decimal digits, not bits, in the signature length. Apple is set up as a certifying authority, but I don't know any details of the plans on how to certify keys. It's a far from simple problem to work out something that will work in the current personal computer market structure and isn't subject to spoofing. Re Apple licensing PGP code: While Apple could presumably do so without violating any laws, so long as any copyright holders in PGP granted appropriate rights, I don't think it's very likely. OCE is a package to be differentiated by its user interface, and apparently MacPGP's (though I haven't tried it myself yet) is rather crufty from the Mac point of view. Also, Apple traditionally wants very tight control over its source code, and is unlikely to adopt something that arrives in such a (shall we say) 'informal' fashion from outside. Finally, as a dose of preventive medicine, I should mention that all of the above is my best interpretation of Apple policy and probable action, with which I don't necessarily agree personally. Flameage ignoring this statement will be routed appropriately. Tim Oren From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: oren@apple.com Date: Sun, 15 Nov 92 13:48:38 PST To: cypherpunks@toad.com Subject: Re: Rander box and other stuff Message-ID: <9211152148.AA24934@apple.com> MIME-Version: 1.0 Content-Type: text/plain >I have a question regarding the ideas which have been circulating about >using CD ROMs as key storage. How does one go about rapidly and effectively >erasing everything on a CD ROM? The reason I ask is, in the case of OTPs >you want to cancel your key as it's used, to prevent accidental double-use >of key; and of course in any system you want to make sure that all your >crypto material can be wiped squeaky clean in the event of a barbarian >invasion. > >-gg A lab proven method: Take CD-ROM. Place in standard kitchen microwave. Set on high power cook for 5 seconds. Press start. Watch the action. Hang resulting artifact on wall as curiosity, which is all it's good for now. Let the wave air out a little (this won't fry it). A great way of trashing obsolete but confidential CD's, and perhaps the cypherpunk equivalent of flushing the dope stash. Tim O. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: karn@qualcomm.com (Phil Karn) Date: Sun, 15 Nov 92 13:58:13 PST To: oren@apple.com Subject: Re: Apple including PKS? Message-ID: <9211152157.AA22323@servo> MIME-Version: 1.0 Content-Type: text/plain After reading the details of that (formerly) secret back-room agreement between NSA and SPA, I don't think I'll *ever* trust a commercial encryption package, especially one for which source code is unavailable for scrutiny. I've learned an important lesson in this business. You can never depend on someone else to ensure your privacy. You have to do it yourself. Phil From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nobody@alumni.cco.caltech.edu Date: Sun, 15 Nov 92 17:29:37 PST To: cypherpunks@toad.com Subject: Extortion Explosion Message-ID: <9211160130.AA12418@alumni.cco.caltech.edu> MIME-Version: 1.0 Content-Type: text/plain Extortion Explosion Introduction: Governments are in the extortion-and-protection racket, as are some well-known smaller ventures. Why do these major organizations spend effort on protecting, instead of just extorting? Current protection rackets maintain a monopoly and manage "their" resources for sustained yield. Without protection, their revenues would decline through a tragedy of the commons mechanism. Other rackets would threaten the same victims, piling extortion on extortion, until the economic field is bare. Crypto technologies promise to liberate us from government extortion and the "protection" of victimless crime laws by enabling the growth of a new sphere of economic activity based on voluntary, secret transactions. But are these technologies so limited in their power? New opportunities in the extortion industry: Old problem: the victim may inform the police, making it risky to pick up the money, which will likely be watched. New solution: demand payment via cryptomoney. Old problem: if you build a reputation for carrying out your threats, parasitic competitors can issue threats in your name, collecting while your reputation is good but destroying your reputation by not following through on threats. New solution: authenticate your threats and demands with digital signatures. Old problem: you may be caught firebombing the house, shooting the victim, slashing the victim's daughter's face, or whatever; if you subcontract to a thug, the thug may be caught and inform on you. New solution: use cryptomoney (and a reputation for paying) to hire thugs while maintaining anonymity. Old problem: providing protection, so that you keep a supply of economically viable victims from whom to extort. New solution: Please find one! If the government can't protect victims from you, how can you protect them from competitors? If this analysis is correct, then crypto technologies will make extortion a highly profitable growth industry, making the security of property and persons (outside tightly-knit walled communities?) incompatible with the continued existence of free computer networks as we know them. Rather than suffering from a single oppressor with an incentive to keep us productive, we would become prey to an unbounded number, each competing to strip our assets before they vanish. Society will surely suppress free networks once this starts to happen; the harder it is to suppress free networks, the greater the oppression will be. Some objections and answers: Q:Isn't it too bleak and pessimistic to believe that the best we can do is to help our oppressors to maintain their monopoly on oppressing us? A1: The Soviet Union was established as a result of a movement that aimed to overthrow an oppressive order. Millions then died under an even more oppressive order. This was bleak, but it happened anyway. A2: Better one oppressor than many, all competing to be the first to kill and eat the goose, knowing that they can't get the golden eggs anyway. A3: Profit is a powerful motive, and conventional profitable activities are imitated and expanded until demand saturates. Crypto-extortion should be highly profitable, but the "supply" is delivered by force, so there is no problem with competitors saturating the "demand" until the victims are drained quite dry. This gives grounds for pessimism. Q: Doesn't the enormous potential of this technology for expanding liberty outweigh these theoretical dangers? What about our hopes and dreams, our vision of a better world? A: These hopes spring from a theoretical social and economic analysis of the impact of crypto technologies, and cryptomoney in particular. The above line of reasoning extends the same analysis. I hope it is wrong, and would be greatly relieved to hear a convincing reason for dismissing it. If it stands, the prospect seems to be either the destruction of society by free networks, or the destruction of free networks by society. The longer we can postpone this choice, the better. Q: Won't cryptomoney be so hard to establish that there's no point in worrying about this? A: If so, then there is equally well no benefit in attempting to implement it. The question is, are there any conditions for "success" that don't generate disaster? Saying the gun probably isn't loaded isn't an argument for putting it to your head and pulling the trigger. Q: Isn't it too late to stop these technologies? A: For public key communication (secrecy and authentication), probably yes. For cryptomoney, possibly no. Most of the benefits of crypto technology seem to come from the former, and most of the danger of an extortion explosion seems to come from the latter. Wishful thinking in the pursuit of liberty is no virtue; realism in the defense of imperfect liberty is no vice. Free-lance oppression isn't freedom, and I don't want it. Cassandra 9531290065272860 P.S. Your neighbor didn't pay me, and his house is ash. Will you pay me? All I ask this month is $100, which you can well afford. (Next month is negotiable, and I can't speak for my competitors.) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nobody@alumni.cco.caltech.edu Date: Sun, 15 Nov 92 19:09:16 PST To: cypherpunks@toad.com Subject: Extortion Explosion Message-ID: <9211160310.AA14098@alumni.cco.caltech.edu> MIME-Version: 1.0 Content-Type: text/plain Cheer up, Cassandra! Things aren't all that bad. > New opportunities in the extortion industry: > > Old problem: the victim may inform the police, making it risky to pick up the > money, which will likely be watched. > New solution: demand payment via cryptomoney. Many forms of electronic money can be traced if there is cooperation between the payer and the bank. For example, in "Untraceable Electronic Cash", by Chaum, Fiat, and Naor, in Crypto 88, we find Alice withdrawing money from the bank, re-blinding it, and developing a "digital coin", C. She then pays that to Bob, who deposits C in the bank. The protocol goes to great length to protect Alice, so that the bank can't link C with her account. However, if she simply _tells_ the bank the value of C, then when Bob goes to deposit it, he can get caught. > Old problem: if you build a reputation for carrying out your threats, > parasitic competitors can issue threats in your name, collecting while your > reputation is good but destroying your reputation by not following through on > threats. > New solution: authenticate your threats and demands with digital > signatures. I can't imagine that this is a big problem right now - people falsely claiming to represent Big Willie when they actually don't, and trying to extort money based on Willie's fearsome reputation. That sounds like a dangerous business. So reducing this "problem" won't make much of a difference. > Old problem: you may be caught firebombing the house, shooting the victim, > slashing the victim's daughter's face, or whatever; if you subcontract to a > thug, the thug may be caught and inform on you. > New solution: use cryptomoney (and a reputation for paying) to hire thugs > while maintaining anonymity. Well, if thugs know that they are now going to be taking the sole responsibility for their actions, without the safety of knowing that they can rat on their employer if worse comes to worst, then they'll charge more to make up for the greater risk. This will make extortion less profitable. > Old problem: providing protection, so that you keep a supply of economically > viable victims from whom to extort. > New solution: Please find one! If the government can't protect victims > from you, how can you protect them from competitors? This is the key point. What stops protection rackets now? Is it really the points listed above: that the money may be traced, that others may falsely benefit from my reputation, that thugs may inform on me? What about simple physical surveillance of property? What about revenge on the transgressors? (As above, the revenge would be restricted to the thugs who did the job, but if it was bad enough it would still have a strong deterrent effect.) > Wishful thinking in the pursuit of liberty is no virtue; realism in the > defense of imperfect liberty is no vice. Free-lance oppression isn't freedom, > and I don't want it. > > Cassandra > 9531290065272860 It makes more sense to have good fire and police forces to deal with the bad guys than to get all in a tizzy because the bad guys can talk to each other now without getting caught. Polyanna --- Undressed PGP public key. Dress it up yourself. --- mQA9AisGm6sAAAEBgLsub7XIi32DjNFKJmGFajDNNIeql4RBmHG/mh9Ns58aBgMv wGRi0KkZ0YIYZZnLpwAFEbQkUG9seWFubmEsIGMvbyA8Y3lwaGVycHVua3NAdG9h ZC5jb20+ =uoWN From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: phr@napa.Telebit.COM (Paul Rubin) Date: Sun, 15 Nov 92 19:43:32 PST To: oren@apple.com Subject: Rander box and other stuff In-Reply-To: <9211152148.AA24934@apple.com> Message-ID: <9211160343.AA11287@napa.TELEBIT.COM> MIME-Version: 1.0 Content-Type: text/plain >I have a question regarding the ideas which have been circulating >about using CD ROMs as key storage. How does one go about >rapidly and effectively erasing everything on a CD ROM? A lab proven method: Take CD-ROM. Place in standard kitchen microwave. Set on high power cook for 5 seconds. Press start. Watch the action. Hang resulting artifact on wall as curiosity, which is all it's good for now. Let the wave air out a little (this won't fry it). You should know better than this. Microwaving cracks the aluminum coating into a lot of small pieces, but almost all the pieces are larger than a few square mm. even if you cook until quite "well done". A few mm. of a CD is a *lot* of contiguous bits that could be recovered by a determined enough adversary, and you likely wouldn't ebe bothering with OTP's unless you're concerned with very determined adversaries. I agree with the person who griped that OTP's are making excessive list traffic compared with interesting protocols, etc. OTP's get rehashed on sci.crypt every few months, as that person pointed out. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Hal <74076.1041@CompuServe.COM> Date: Sun, 15 Nov 92 17:37:40 PST To: CYPHERPUNKS Subject: Why remailers... Message-ID: <921116013001_74076.1041_DHJ41-1@CompuServe.COM> MIME-Version: 1.0 Content-Type: text/plain Tim mentioned that not many people on the list have expressed interest in the remailers, and it occurs to me that maybe people don't all share the vision of why this crypto technology is important. I'm trying to recall how I learned about the possibilities of this technology. I recall reading "True Names" a few years ago. Vinge had his netters exchanging mail anonymously. The hero downloaded a big batch of messages from a BBS and tried decrypting all of them to see which were for him. Okay, I thought, that would be a way of disguising which messages you were _receiving_. Then Vinge said something like "and using more elaborate techniques, the sender of a message could be hidden as well." Hold on, I thought. That will never work. If they tap your line, they're going to know exactly what messages you're sending. Too bad. Vinge had a clever idea going, but it's flawed. I only learned about Chaum's crypto stuff last year. Somebody on the Extropians list mentioned PGP, and I'd always had a casual interest in crypto, so I downloaded it and played with it some. I thought it was great and really got into it in a big way. This got me interested in crypto in general, so I started doing some library research. When I found Chaum's stuff, it just blew me away. The first article I found, I think, was his CACM paper which is an overview of many of the things that are possible. I started trying to track down other papers by Chaum. Here were all the technologies needed to make Vinge's world work, technologies which Vinge apparently knew about long before I did. It seemed so obvious to me. Here we are faced with the problems of loss of privacy, creeping computerization, massive databases, more centralization - and Chaum offers a completely different direction to go in, one which puts power into the hands of individuals rather than governments and corporations. The computer can be used as a tool to liberate and protect people, rather than to control them. Unlike the world of today, where people are more or less at the mercy of credit agencies, large corporations, and governments, Chaum's approach balances power between individuals and organizations. Both kinds of groups are protected against fraud and mistreatment by the other. Naturally, in today's society, with power allocated so disproportionately, such ideas are a threat to large organizations. Balancing power would mean a net loss of power for them. So no institution is going to pick up and champion Chaum's ideas. It's going to have to be a grass-roots activity, one in which individuals first learn of how much power they can have, and then demand it. Where do the remailers fit in? They represent the "ground floor" of this house of ideas - the ability to exchange messages privately, without revealing our true identities. In this way we can engage in transactions, show credentials, and make deals, without government or corporate databases tracking our every move as they can today. Only by securing the ability to communicate privately and anonymously can we take the next steps towards a world in which we each have true ownership and control over information about our lives. Chaum's ACM paper is titled, provocatively, "Security Without Identification - Transaction Systems to Make Big Brother Obsolete." The work we are doing here, broadly speaking, is dedicated to this goal of making Big Brother obsolete. It's important work. If things work out well, we may be able to look back and see that it was the most important work we have ever done. Hal Finney 74076.1041@compuserve.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Karl L. Barrus Date: Sun, 15 Nov 92 18:43:30 PST To: cypherpunks@toad.com Subject: Chaum's papers Message-ID: <9211160243.AA07165@tree.egr.uh.edu> MIME-Version: 1.0 Content-Type: text/plain Hal Finney writes: > This got me interested in crypto in general, so I started doing some > library research. When I found Chaum's stuff, it just blew me away. What else has Chaum written about? I saw his Scientific American cryptomoney article, and have heard of his dc-nets, but what other protocols has he discussed? Any pointers on journal articles would be appreciated - I think tomorrow I'll hit the library and go sifting for everything Chaum has written! /-----------------------------------\ | Karl L. Barrus | | barrus@tree.egr.uh.edu (NeXTMail) | | elee9sf@menudo.uh.edu | \-----------------------------------/ From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Sun, 15 Nov 92 22:27:49 PST To: cypherpunks@toad.com Subject: re: Why remailers... Message-ID: <3744.2B07398C@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain U> From: 74076.1041@CompuServe.COM (Hal) re: why remailers aren't as exciting as RNG's. Well, remailers are working, admittedly a bit clunky at the moment, and RNGs being talked about aren't. And we're primarily hackers. Once something's working, it's less interesting, no? :-) The next step for remailers is to make them actually *usable*, routinely. Their current status is no fault of the implementors, it's a first pass and a test bed (I ain't complaining!) I just don't think it's a big secret, nor a big problem. Development is always slow and boring... :-) --- ReadMail * Origin: tomj@fidosw.fidonet.org / World Power Systems (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET - Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Sun, 15 Nov 92 22:27:50 PST To: cypherpunks@toad.com Subject: re: Rander box and other stuff Message-ID: <3745.2B07398E@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain U> A lab proven method: Take CD-ROM. Place in standard U> kitchen microwave. Set on high power cook for 5 U> seconds. Press start. Watch the action. If its a CD ROM, then there's a bunch of them. Someone else will have a copy. Aternately, Iif you mark which keys are used, then it will be detectable which keys were used (sic). It would be better to have all of the CD ROMs laying about, untouched, and secret the key-selection elsewhere. PS: I get lots of really bad CDs in the mail, from the days when I was doing HOMOCORE zine. I used to save up big stacks of them and try to trade them in at used record stores. They are all so awful (eg. bottom-rotation gunk on "modern rock" stations.) that the stores won't take them! I now nuke 'em. Far more fun! --- ReadMail * Origin: tomj@fidosw.fidonet.org / World Power Systems (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET - Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Mon, 16 Nov 92 00:59:25 PST To: oren@apple.com Subject: Re: Rander box and other stuff Message-ID: <199211160858.AA23576@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain So we need to set up UPSs (uninterruptable power supplies, i.e. backup power) for our u-wave ovens, and build a standard interface which will set the appropriate parameters (5 sec on high cook) and start, which can be connected to a burglar alarm with panic switches and keypad with duress code. Then if the barbarians come to the door, it's one-two-three-FLUSH! Somewhat inconvenient if the barbarians come a-callin' when you're in the middle of a crypto session ("'scuse me while I put something in for dinner...") but doable... -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Mon, 16 Nov 92 01:13:51 PST To: cypherpunks@toad.com Subject: The Dining Cryptographers Protocol Message-ID: <9211160910.AA13370@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Fellow Dining Cryptographers (and Cypherpunks), Hal Finney has been suggesting I forward to this list some articles I wrote for another list of like-minded folks, the "Extropians" list. We had some fascinating discussions of digital money, DC-nets, digital pseudonyms (a la Vernor Vinge's "True Names," as Hal has noted), etc. Basically the stuff I put in my .signature, and so on. These topics are, in my opinion, at the core of what we are doing on this list. It is highly gratifying to see the pieces falling into place. And at our crypto session at the Hackers Conference, it became clear to many people just how close we are. So since Hal just forwarded me one of my old postings, how can I resist? (I still _have_ my old posts, but no longer on my NETCOM system, so reposting them takes a bit of effort. So I'll just forward to you the posting Hal just forwarded to me!) Hal Finney writes: I was looking through some old Extropians messages and found this one which you wrote about DC nets. I don't know if you archive your old messages, but I thought this had some good stuff, especially at the end where you talk about the applications of crypto anonymity. You would probably want to change the use of Extropians to Cypherpunks or some such, if you wanted to re-post it there. Hal Return-Path: To: Extropians@gnu.ai.mit.edu From: uunet!netcom.com!tcmay (Timothy C. May) Subject: Dining Cryptographers X-Original-To: Extropians@gnu.ai.mit.edu Date: Tue, 18 Aug 92 15:45:34 PDT X-Extropian-Date: Remailed on August 18, 372 P.N.O. [22:46:47 UTC] Reply-To: uunet!gnu.ai.mit.edu!Extropians Marc R. has opened the door for me to get into some really exciting stuff: > > Tim May mentioned a new method from Chaum for defeating traffic analysis: > > > Chaum has since improved the tamper-responding "mix" by going to a pure > > software scheme which he calls "the Dining Cryptographers Protocol." It's > > described in Vol. 1, Number 1 of "Journal of Cryptology," 1988. If there's > > interest, I'll summarize it. > > Yes, please, Tim! > > > M. Complexity Warning: This stuff (I'm being informal) is easy once you get the basic idea. But getting the basic idea usually involves reading several articles on what RSA, digital signatures, etc., are all about, working out some examples, thinking about it, drawing pictures with other folks, and finally having an "Aha!" experience (in Werner Erhard's terms, you "get it"). The ASCII nature of the Net is not conducive to learning this stuff, despite the excellent summaries of crypto by Marc R. and Perry M. The almost-latest "Scientific American," August, has an article by David Chaum on digital money, and the latest "Spectrum," available at selected newstands, has several articles on security and cryptography. Also, there are lots of books. Look 'em up in a university library or flip through them at a large technical bookstore and pick the one you like the most. (I like a slim Springer-Verlag paperback, "Modern Cryptology," by Gilles Brassard, 1988, as a good intro to "modern"--as opposed to "classical"--crypto.) If the stuff in this posting, and on crypto in general, is beyond your current understanding, either ignore it, skim it and try to get the gist, or dig into the articles and books. Anyway, back to "The Dining Cryptographers Problem: Unconditional Sender and Recipient Untraceability," David Chaum, Journal of Cryptology, I, 1, 1988. Since this journal is hard to get, I'll discuss the article in some detail. (The techniques have major implications for anarchocapitalism and for Extropian ideas.) Abstract: "Keeping confidential who sends which messages, in a world where any physical transmission can be traced to its origin, seems impossible. The solution presented here is unconditionally or cryptographically secure, depending on whether it is based on one-time-use keys or on public keys. respectively. It can be adapted to address efficiently a wide variety of practical considerations." A word on terminology: "Unconditionally secure" means what it says: no computer will ever crack it. One-time pads are unconditionally secure...no code or cipher is involved, except the one-time pad, so the message is secure as long as the pad has not been compromised. "Cryptographically secure" means secure so long as various crypto ciphers are secure, which may be for a very, very long time (e.g., with very large primes, in RSA). Chaum describes some "dining cryptographers," which I will playfully change to "dining Extropians." (The term is of course a variant of the seminal "dining logicians problem" in computer science) Three Extropians are having dinner, perhaps in New York City. Their waiter tells them that their bill has already been paid, either by the NSA or by one of them. The waiter won't say more. The Extropians wish to know whether one of them paid, or the NSA paid. But they don't want to be impolite and force the Extropina payer to 'fess up, so they carry out this protocol (or procedure): Each Extropian flips a fair coin behind a menu placed upright between himself and the Extropian on his right. The coin is visible to himself AND to the Extropian on his left. Each Extropian can see his own coin and the coin to his right. STOP RIGHT HERE! Please take the time to make a sketch of the situation I've described. If you lost it here, all that follows will be a blur. I'm sparing you folks my attempt at an ASCII drawing! Each Extropians then states out loud whether the two coins he can see are the SAME or are DIFFERENT, e.g., "Heads-Tails" means DIFFERENT, and so forth. For now, assume the Extropians are truthful. A little bit of thinking shows that the total number of "DIFFERENCES" must be either 0 (the coins all came up the same), or 2. Odd parity is impossible. Now the Extropians agree that if one of them paid, he or she will SAY THE OPPOSITE of what they actually see. Remember, they don't announce what their coin turned up as, only whether it was the same or different as their neighbor. Suppose none of them paid, i.e., the NSA paid. Then they all report the truth and the parity is even (either 0 or 2 differences). They then know the NSA paid. Suppose one of them paid the bill. He reports the opposite of what he actually sees, and the parity is suddenly odd. That is, there is 1 difference reported. The Extropians now know that one of them paid. But can they determine which one? Suppose you are one of the Extropians and you know you didn't pay. One of the other two did. You either reported SAME or DIFFERENT, based on what your neighbor to the right (whose coin you can see) had. But you can't tell which of the other two is lying! (You can see you right-hand neighbor's coin, but you can't see the coin he sees to his right!) This all generalizes to any number of people. If none of them paid, the parity is even. If one of them paid, the parity is odd. But which one of them paid cannot be deduced. And it should be clear that each round can transmit a bit, e.g., "I paid" is a "1". The message "Attack at dawn" could thus be "sent" untraceably with multiple rounds of the protocol. The Crypto Ouija Board: I explain this to people as a kind of ouija board. A message, like "I paid" or a more interesting "Transfer funds from.....," just "emerges" out of the group, with no means of knowing where it came from. Truly astounding. Now there are many interesting wrinkles and elaborations to this protocol. I'll note just a few. 1. Collusion. Obviously the Extropians can collude to deduce the payer. This is best dealt with by creating multiple subcircuits (groups doing the protocol amongst themselves). Lots more stuff here. Chaum devotes most of the paper to these kind of issues and their solutions. 2. With each round of this protocol, a single bit is transmitted. Sending a long message means many coin flips. Instead of coins and menus, the neighbors would exchange lists of random numbers (with the right partners, as per the protocol above, of course. Details are easy to figure out.) 3. Since the lists are essentially one-time pads, the protocol is unconditionally secure, i.e., no assumptions are made about the difficulty of factoring large numbers or any other crypto assumptions. 4. Participants in such a "DC-Net" (and here we are coming to the heart of the "crypto anarchy" I have mentioned several times, and which is perhaps foolishly advertised in my .sig) could exchange CD-ROMs or DATs, giving them enough "coin flips" for zillions of messages, all untraceable! The logistics are not simple, but one can imagine personal devices, like smart card or Apple "Newtons," that can handle these protocols (early applications may be for untraceable brainstorming comments, secure voting in corportate settings, etc.) 5. The lists of random numbers (coin flips) can be generated with standard cryptographic methods, requiring only a key to be exchanged between the appropriate participants. This eliminates the need for the one-time pad, but means the method is now only cryptographically secure, which is often sufficient. (Don't think "only cryptographically secure" means insecure....the messages may remain encrypted for the next billion years) 6. Collisions occur when multiple messages are sent at the same time. Various schemes can be devised to handle this, like backing off when you detect another sender (when even parity is seen instead of odd parity). In large systems this is likely to be a problem. Solutions are left as an exercise. 7. Noise. Some participants may try to flood the circuit with spurious messages, to defeat the system or for whatever other reasons. This is still an issue. (If there's anything to take away from crypto, it's that nothing is as simple as it looks, that there are always devious ways to spoof, jam, and forge. I expect you've seen this from some of the debate on digital voting schemes.) What Can "DC-Net" Be Used For?: * Untraceable mail. Useful for avoiding censorship, for avoiding lawsuits, and for all kinds of crypto anarchy things. * Fully anonymous bulletin boards, with no traceability of postings or responses. Illegal materials can be offered for sale (my 1987 canonical example, which freaked out a few people: "Stealth bomber blueprints for sale. Post highest offer and include public key."). Think for a few minutes about this and you'll see the profound implications. * Decentralized nexus of activity. Since messages "emerge" (a la the ouija board metaphor), there is no central posting area. Nothing for the government to shut down, complete deniability by the participants. * Only you know who your a partners are....in any given circuit. And you can be in as many circuits as you wish. (Payments can be made to others, to create a profit motive. I won't deal with this issue, or with the issue of how reputations are handled, in this posting.) * The tamper-responding "digital mixes" can still be useful, and may supplement this purely software-based approach. * Digital money gets involved, too, both for payments in this system, and in terms of "alternative currencies." I'm not an economist, so I'll leave this for others to go into in more detail. Enough for now. Chaum's work is just the start. These systems can initially be set up for "innocuous" purposes like research into crypto techniques (not yet banned in the U.S.), role-playing games, religions, and the like. Once they get going, it'll be too late to stop the other things. Hope you liked this summary. Please read the articles...there's just no way my posting can do justice to them (though I admit I've concentrated my efforts on the political aspects, which "respectable" crypto researchers rarely mention, so perhaps the flavor here is a bit more Extropian than you'll find elsewhere.) --Tim (part of the "Too Many Tims!" Conspiracy) -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: awaiting Macintosh version. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: gnu Date: Mon, 16 Nov 92 01:45:42 PST To: markoff@nyt.com Subject: Cryptographer jailed for selling crypto to political opposition? Message-ID: <9211160945.AA19475@toad.com> MIME-Version: 1.0 Content-Type: text/plain Date: Sun, 15 Nov 92 02:17:47 -0500 From: barlow@icecube.pinedale.wy.us (John Perry Barlow) Message-Id: <9211150717.AA00755@icecube.pinedale.wy.us> To: gnu@toad.com Subject: Here's one to pass on to CypherPunk Begin forwarded message: Date: Sun, 15 Nov 1992 2:53:58 UTC+0100 From: "(Miguel Gallardo)" Subject: Cryptodanger!!! To: barlow@eff.org, barlow@icecube.pindale.wy.us, postmaster@eff.org Dear friends, I think that paranoid is almost inevitable in Cryptology. The real danger is just trying to avoid that thinking. But sometimes things are really difficult! One year ago I met a man in a conference on Cryptology. He was from Switzerland and was working for a company named CRYPTO AG. He is fluent in several lenguages, including Spanish and Arabic, and was not afraid about his interest in taboo (cryptoanalysis). I really enjoyed that conversation. Last week I listened a conversation about him, and I know now that he is in jail at Teheran (Iran). He is acused for atenting against the shii goverment just because he was sellin cryptology to the political opposition. Do you know about that? If so, do you have anything published on it? His name is Hans Buhler, CRYPTO AG, P.O. Box 474 CH-6301 Zug/Switzerland. I am really interested in any information about him! Nobody answer my fax to his company, or to Iran embassy here (!?). _ _ _ _ ' ) ) ) // / / / o __ _ // / ' (_<_(_//_/_ MIME-Version: 1.0 Content-Type: text/plain Date: Sat, 14 Nov 1992 20:17:06 -0500 To: interesting_people@aurora.cis.upenn.edu From: Dave Farber Subject: from RISKS Reprinted with permission ("do with it as you wish. Granger") A "Viewpoint " piece in The Institute, November 1992 Balancing National Interests The September/October issue of The Institute carried a front page story reporting that the Federal Bureau of Investigation is promoting legislation that would require all telephone systems to be designed in such a way that they can be wiretapped by law enforcement officials. The argument is that wiretapping is a key tool in much of law enforcement, particularly in fields such as drugs, racketeering, conspiracy and white collar crime, and that unless care is taken in the design of future telecommunications systems, this tool may become difficult or impossible to exercise. To solve this problem the FBI is promoting legislation that would establish design requirements on future telephone systems. Not surprisingly, civil liberties groups and telephone companies are reported to be less than enthusiastic. While interesting and important in its own right, this controversy is perhaps even more important as a symbol of a broader set of conflicts between a number of important national interests. As a country, we want to promote: * Individual privacy (including the right of citizens and other residents of the U.S. to keep personal records private, hold private communications with others, and move about without being "tracked".) * Security for organizations (including protection of financial transactions, and the ability to keep corporate data, plans, and communications confidential.) * Effective domestic law enforcement (including the ability to perform surveillance of legitimately identified suspects, and the ability to audit and reconstruct fraudulent activities.) * Effective international intelligence gathering (including the ability to monitor the plans and activities of organizations abroad that may pose a threat to the U.S. or to other peaceful states and peoples.) * Secure world-wide reliable communications for U.S. diplomats and the military, for U.S. business, and for U.S. citizens in their activities all around the world (including the ability to maintain and gain access to secure, reliable, communications channels.) Just as with most of our society's other fundamental objectives, these objectives are in conflict. You can not maximize them all because getting more of some involves giving up some of others. A dynamic tension must be created that keeps the various objectives properly balanced. That socially optimal point of balance may change gradually over time as world conditions and our society's values evolve. An electrical engineer who thinks for a moment about the problem of achieving any particular specified balance among the various objectives I have listed will quickly conclude that communications and information technology design choices lie at the heart of the way in which many of the necessary tradeoffs will be made. We would like easy portable communications for all, but doing that in a way that allows people to keep their legitimate travels private poses significant design challenges. Banks and other businesses would like secure encrypted communications world-wide, but promoting the general availability of such technologies all around the world severely complicates the signal intelligence operations of intelligence organizations. The troubling thing about the FBI's legislative proposals is not that they are being made, but that we lack a broader institutional context within which to evaluate them. In making such choices, we need to look systematically at all the legitimate interests that are at stake in telecommunications and information technology design choices, consider the ways in which technology and the world are evolving, and integrate all these considerations to arrive at a reasoned balance. In the old days, if things got too far out of line in some balance (for example, between freedom of the press and protection against liable), the courts simply readjusted things and we went on. Today, and increasingly in the future, with many of these balances hard wired into the basic design of our information and communication systems, it may be much harder to readjust the balance after the fact. There are several organizations that should be working harder on these issues. On the government side the Telecommunication and Computing Technologies Program in the Office of Technology Assessment should be doing more systematic studies of these tradeoffs to help inform the Congress; The National Telecommunications and Information Administration in the Department of Commerce (or some appropriate interagency committee) should be doing similar studies to develop more coherent and comprehensive executive branch policy; and the Office of Policy and Plans in the Federal Communications Commission (which is an independent regulatory agency not directly subject to executive branch policy) should be giving these issues more attention so it can better support the Commissioners when they confront such tradeoffs. On the non-government side, the Office of Computer and Information Technology at the National Research Council might appropriately mount a comprehensive study. There is an ideal opportunity here for a private foundation to fund an independent blue-ribbon commission. Finally, the computer and telecommunications industries, both individually and collectively through their industry associations, should be taking more interest in how the country will strike these all important balances. M. Granger Morgan M. Granger Morgan (F) is head of the Department of Engineering and Public Policy at Carnegie Mellon University where he is also a Professor in the Department of Electrical and Computer Engineering and in the H. John Heinz III School of Public Policy and Management. He teaches and performs research on a variety of problems in technology and public policy in which technical issues are of central importance. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Hal <74076.1041@CompuServe.COM> Date: Sun, 15 Nov 92 23:37:38 PST To: Cypherpunks Subject: Chaum's papers Message-ID: <921116073129_74076.1041_DHJ35-1@CompuServe.COM> MIME-Version: 1.0 Content-Type: text/plain A couple of people have asked for references to Chaum's papers. The August, 1992 issue of Scientific American was mentioned here, I think. The ACM paper I referred to is "Security Without Identification: Transaction Systems to Make Big Brother Obsolete", October 1985. The "DC-Net" is described in "The Dining Cryptographers Problem: Unconditional Sender and Recipient Untraceability", Cryptology, 1988, volume 1, p65-75. The "Mix-net", which is similar to the remailers we are experimenting with, is described in "Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms", CACM, February, 1981. Chaum also frequently presents papers at the Crypto conferences, so if you can get access to the proceedings of these at the library you will usually find one or two papers by him in each volume. However, in recent years he has published on other topics which don't seem as relevant to the freedom/privacy issues we are concerned with. Hal 74076.1041@compuserve.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Mon, 16 Nov 92 03:31:18 PST To: markoff@nyt.com Subject: Re: Cryptographer jailed for selling crypto to political opposition? Message-ID: <199211161129.AA29310@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Crypto AG is the current name of the Hagelin company, which was founded by Boris Hagelin shortly before WW2. Hagelin's main contribution was the advancement of the mechanical rotor system; their M-209 was a basic part of Allied battlefield operations. This machine was about the size of a desk phone base, and had a little knob which you'd turn to the letter you wanted to enter, one letter at a time, and after each letter you'd press a handle, whicc would operate the mechanism and printo out both a cleartext and ciphertext strip on paper. The ciphertext would be handed to the radio operator to be sent in morse (or in civilian use, via telegraph land-lines). Hagelin made various versions of their basic rotor machine. One was a pocket-sized unit, like 3" x 5", with a rotary alphabetic dial on the front. Hagelin supplied most of the noncommunist world with crypto tech after WW2. Chances are that Crypto AG has sufficient connexions in high places as to be able to get its people out of there. I'm familiar with another case involving a large northern Euro maker of telecom systems who had two engineers taken hostage in Iraq on some inflated charge, and sentenced to 7 years... the company fully expects to have its engineers out of there within six months, no question about it. -gg@well.sf.ca.us From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Mon, 16 Nov 92 09:12:39 PST To: cypherpunks@toad.com Subject: November 21 meeting, 12 noon, at Cygnus offices Message-ID: <9211161712.AA15115@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain ANNOUNCEMENT ============ The Third Physical Cypherpunks Meeting: Project Planning It has become clear that lots of code needs to be written, and that we will be writing it. Therefore the Third Meeting will be devoted to project planning and design review. Date: November 21 Time: 12 noon Where: Cygnus Support offices Who: you, and anybody you know who wants to come, and so on. (Please do not post this announcements to public places, but do encourage private circulation.) Positive-Confimation: Please tell me if you are coming. Replies to hughes@soda.berkeley.edu. Please, I urge all of you on the list that can make to attend this time. This will be a pivotal meeting, since we are deciding priorities here. If you want to affect the course of development, you ought to show up. If you can't attend, corner someone on the list who will be there and convince them to represent your position. Eric Hughes AGENDA ====== 1. Key exchange. Bring a diskette with your PGP public key on it. Bring a machine which can read this diskette. Bring extra diskettes to collect keys on and to give out. Let us not be hypocrites and let us all know each other's public keys. 2. Project planning. We need a list of crypto projects and who is working on them. This will help coordination and avoid duplication of effort. We need to prioritize the projects to avoid premature development. We need to create strategies and design criteria. 3. Project logistics. We need to talk about the best ways to do widely distributed software development in this fairly anarchic environment. 4. Design review. Hal Finney and I have been duking it out behind the scenes working on a design schema for the next generation remailer. I'd like to present the design and have people critique it. (would be 5.) We won't be playing the crypto-anarchy game this time. It's not a dead duck, but this time we've got more urgent things to do. DIRECTIONS ========== Here is a reposting of the directions to the meeting place. ------------------------------------------------------------------ To: cypherpunks@toad.com Subject: Better directions to the meeting on Saturday at noon From: gnu@cygnus.com Someone asked for better directions, and the original ones were pretty skimpy anyway. Here's a better try. Cygnus Support 1937 Landings Drive Mt. View, CA 94043 There's no phone service there yet. Take US 101 toward Mt. View. From San Francisco, it's about a 40-minute drive. Get off at the Rengstorff Ave/Amphitheatre Parkway exit. If you were heading south on 101, you curve around to the right, cross over the freeway, and get to a stoplight. If you were heading north on 101, you just come right off the exit to the stoplight. The light is the intersection of Amphitheatre and Charleston Rd. Take a right on Charleston; there's a right-turn-only lane. Follow Charleston for a short distance. You'll pass the Metaphor/Kaleida buildings on the right. At a clump of palm trees and a "Landmark Deli" sign, you can take a right into Landings Drive; this gets you into the complex from the north. Or you can go slightly further along Charleston and take the next right, into a driveway with a big "Landmark" sign in the middle. No matter which way you got into the complex, follow around it until you are on the side that faces the freeway. There's a clock tower that rises out of one of the buildings, to the right (south) of the deli. Enter through the doors immediately under the clock tower. They'll be open between noon and 1PM at least. (See below if you're late.) Once inside, take the stairs up, immediately to your right. At the top of the stairs, turn right past the treetops, and we'll be in 1937 on your left. If you are late and the door under the clock tower is locked, you can go to the deli (which will be around a building and left, as you face the door), cut between the buildings to the right of the deli, and into the back lawns between the complex and the farm behind it. Walk around the buildings until you see a satellite dish in the lawn. Go up the stairs next to the dish, which are the back stairs into the Cygnus office space. We'll prop the door (or you can bang on it if we forget). Or, you can find the guard who's wandering around the complex, who knows there's a meeting happening and will let you in. They can be beeped at 965 5250, though you'll have trouble finding a phone. Don't forget to eat first, or bring food at noon! I recommend hitting the burrito place on Rengstorff (La Costen~a) at about 11:45. To get there, when you get off 101, take Rengstorff (toward the hills) rather than Amphitheatre (toward the bay). Follow it about ten blocks until the major intersection at Middlefield Road. La Costen~a is the store on your left at the corner. You can turn left into the narrow lane behind the store, which leads to a parking lot, and enter by the front door, which faces the intersection. To get to the meeting from there, just retrace your route on Rengstorff, go straight over the freeway, and turn right at the stoplight onto Charleston; see above. See you there! John Gilmore From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hollander Date: Mon, 16 Nov 92 10:44:37 PST To: "George A. Gleason" Subject: Re: Rander box and other stuff In-Reply-To: <199211160858.AA23576@well.sf.ca.us> Message-ID: <9211161844.AA20421@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain I heard something somewhere about hard disks with a layer of thermite inside the platter. Can you say "ferrous vapor"? For me the ideal cryptosystem would be a small notebook with a thermite hard drive and TEMPEST shielding and no multitasking. e From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Peter Shipley Date: Mon, 16 Nov 92 11:21:05 PST To: Eric Hollander Subject: Re: Rander box and other stuff In-Reply-To: <9211161844.AA20421@soda.berkeley.edu> Message-ID: <9211161920.AA22901@edev0.TFS> MIME-Version: 1.0 Content-Type: text/plain > >I heard something somewhere about hard disks with a layer of thermite >inside the platter. Can you say "ferrous vapor"? > >For me the ideal cryptosystem would be a small notebook with a thermite hard >drive and TEMPEST shielding and no multitasking. > you forgot the auto self destruct if the unit is more then 4 meters from your person. -Pete From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Michael Gleibman Date: Mon, 16 Nov 92 02:33:09 PST To: cypherpunks@toad.com Subject: Unsubscribe Message-ID: <9211161029.AA14695@techst02.technion.ac.il> MIME-Version: 1.0 Content-Type: text/plain Unsubscribe me from this list, please, it is a huge value of mail:-)... Thank you in advance. c0408982@techst02.technion.ac.il From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: whitaker@eternity.demon.co.uk (Russell E. Whitaker) Date: Mon, 16 Nov 92 08:51:45 PST To: cypherpunks@toad.com Subject: Re: Apple including PKS? Message-ID: <4195@eternity.demon.co.uk> MIME-Version: 1.0 Content-Type: text/plain Phil Karn says: > > I've learned an important lesson in this business. You can never depend on > someone else to ensure your privacy. You have to do it yourself. > The same goes for the ultimate standard of physical security: defence of one's person against physical attack. Arguments for the right to keep and bear arms can often be directly mapped onto arguments for the right to keep and use pkeys. Russell Earl Whitaker whitaker@eternity.demon.co.uk Communications Editor 71750.2413@compuserve.com EXTROPY: The Journal of Transhumanist Thought AMiX: RWHITAKER Board member, Extropy Institute (ExI) ================ PGP 2.0 public key available ======================= From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Marc.Ringuette@GS80.SP.CS.CMU.EDU Date: Mon, 16 Nov 92 10:15:43 PST To: cypherpunks@toad.com Subject: Re: The Dining Cryptographers Protocol Message-ID: <9211161815.AA29148@toad.com> MIME-Version: 1.0 Content-Type: text/plain My spin on the Dining Cryptographers Protocol is, it's nifty and theoretically strong, but in practice mixes are better for almost all uses. If you have N people in a DC-net, you must exchange N bits of traffic per bit of anonymous message transmitted. If you use mixes and send each message on M hops, you exchange M bits of traffic per bit of anonymous message transmitted. N is typically 100-10000, and M is typically 2-10. Mixes are more efficient. One advantage of DC-nets is that they're instant; with mixes there must be some delays in order to accumulate enough cover messages to defeat traffic analysis. -- Marc Ringuette (mnr@cs.cmu.edu) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Mon, 16 Nov 92 11:26:52 PST To: shawnb@ecst.csuchico.edu Subject: The legality of PGP In-Reply-To: <9211140007.AA19365@toad.com> Message-ID: <9211161902.AA08397@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: S.E. Brown >Well, >I've been reading a lot of speculation and outright disinformation about >the legality of PGP. Does anyone have any informed information about the >actual legal status us sing and disseminating the program? PGP is based on RSA cryptography, which is patented. The patent is controlled by Public Key Partners, which has not granted a license for people to use PGP. Therefore, using PGP is possibly a patent violation, although thus far no action seems to have been taken by PKP in this respect. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tim Oren Date: Mon, 16 Nov 92 14:47:57 PST To: cypherpunks@toad.com Subject: Digital Cash bibliography Message-ID: <9211162247.AA24502@apple.com> MIME-Version: 1.0 Content-Type: text/plain As a followup to Tom's bibliography, here's a list I compiled about six months ago on digital cash, including Chaum's basic articles, others published in this area, and a list of relevant U.S. patents. - Tim O. ----------- Bibliography for Digital Cash and Checks using Cryptographic Techniques Articles Chaum, D., Showing credentials without identification: transferring signatures between unconditionally unlinkable pseudonyms. (Springer-Verlag, Berlin, West Germany, p. 246-64, 1990)(Conference: Advances in Cryptology-AUSCRYPT '90 International Conference on Cryptology. Proceedings, Sydney, NSW, Australia, 8-11 Jan. 1990) Chaum, D. den Boer, B. van Heyst, E. Mjolsnes, S. Steenbeek, A., Efficient offline electronic checks. (Springer-Verlag, Berlin, Germany, p. 294-301, 1990)(Conference: Advances in Cryptology - EUROCRYPT '89. Workshop on the Theory and Application of Cryptographic Techniques Proceedings, Houthalen, Belgium, 10-13 April 1989) Chaum, D., Online cash checks. (Springer-Verlag, Berlin, Germany, p. 288-93, 1990)(Conference: Advances in Cryptology - EUROCRYPT '89. Workshop on the Theory and Application of Cryptographic Techniques Proceedings, Houthalen, Belgium, 10-13 April 1989) Chaum, David, Security without Identification: Transaction Systems to make Big Brother Obsolete; Communications of the ACM 28/10 (1985) 1030-1044. Chaum, D. Fiat, A. Naor, M., Untraceable electronic cash. (Springer-Verlag, Berlin, West Germany, p. 319-27, 1990)(Conference: Advances in Cryptology - CRYPTO '88. Proceedings, Santa Barbara, CA, USA, 21-25 Aug. 1988) Okamoto, T. Ohta, K., Disposable zero-knowledge authentications and their applications to untraceable electronic cash. (Springer-Verlag, Berlin, West Germany, p. 481-96, 1990)(Conference: Advances in Cryptology - CRYPTO '89. Proceedings, Santa Barbara, CA, USA, 20-24 Aug. 1989) Even, S., Secure off-line electronic fund transfer between nontrusting parties. (North-Holland, Amsterdam, Netherlands, p. 57-66, 1989)(Conference: Smart Card 2000: The Future of IC Cards. Proceedings of the IFIP WG 11.6 International Conference, Laxenburg, Austria, 19-20 Oct. 1987) Tunstall, J.S., Electronic currency. (North-Holland, Amsterdam, Netherlands, p. 47-8, 1989)(Conference: Smart Card 2000: The Future of IC Cards. Proceedings of the IFIP WG 11.6 International Conference, Laxenburg, Austria, 19-20 Oct. 1987) Hayes, Barry, Anonymous One-Time Signatures and Flexible Untracable Electronic Cash, in AusCrypt '90: A Workshop on Cryptology, Secure Communication and Computer Security, January, 1990. U. S. Patents W. M. Benton, Funds Transfer System using Optically Coupled, Portable Modules, US Pat. #4,454,414, Jun 12, 1984. W. G. Bouricius and P. E. Stuckert, Method and Apparatus for Secure Message Transmission for Use in Electronic Funds Transfer Systems, US Pat. #4,302,810, Nov. 24, 1981. D. Chaum, "Cryptographic Identification, Financial Transaction, and Credential Device," US Pat #4,529,870, Jul. 16, 1985. W. S. Powell, "Information Communicating Apparatus and Method," US Pat. #4,320,387, Mar. 16, 1982. P. E. Stuckert, "Personal Portable Terminal for Financial Transactions," US Pat. #4,277,837, Jul. 7, 1981. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hollander Date: Mon, 16 Nov 92 15:11:38 PST To: Peter Shipley Subject: Re: Rander box and other stuff In-Reply-To: <9211161920.AA22901@edev0.TFS> Message-ID: <9211162311.AA09645@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain >>I heard something somewhere about hard disks with a layer of thermite >>inside the platter. Can you say "ferrous vapor"? >> >>For me the ideal cryptosystem would be a small notebook with a thermite hard >>drive and TEMPEST shielding and no multitasking. >> > >you forgot the auto self destruct if the unit is more then 4 meters from >your person. If we're going to have auto self destruct with a range limit, it should also be waterproof so I can take it swimming (and so that the self destruct system won't be impeded by water). And if it's going to have a four meter limit, it needs to be so light that I can carry it absolutely everywhere, like under 500 grams, and if it's going to be that small, it won't be able to have a keyboard (use pen input) or a hard drive (lots of battery backed ram instead). In fact, now that we've dropped the hard drive and the keyboard, it might as well just be a dedicated crytosystem, make it about 10cmX10cmX1cm and give it an ether port, an rs232 port, a pcmcia port and an rj11 port. It's doable and would provide the ultimate security. e From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hollander Date: Mon, 16 Nov 92 15:33:38 PST To: Hal <74076.1041@compuserve.com> Subject: Re: Why remailers... In-Reply-To: <921116013001_74076.1041_DHJ41-1@CompuServe.COM> Message-ID: <9211162333.AA10951@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Remailers are extremely important, but we also need anonymous IP bouncers. An IP bouncer might work like this: there would be a user, a server, and a target. The server and user would each have key pairs (probably a new pair for each session), and would trade public keys. The user would request a port from the server, and then would issue (encrypted) commands to the server. These commands might include: telnet - open a connection to the target. The target would route its packets to the server, and the server would encrypt them and route them to the user. ignore - get ready to recieve lots of random bits and perhaps pass them on to other servers. This is needed to help a user confuse trafic analysis. A side note: it would be useful to have a standard port on all machines that would accept the encrypted ignore command, so that packets could just be sent off into the ether. Users who use bouncers would want to have their machines open up connections, issue the ignore command, and send random bits at some random interval. mail - act as an anonymous remailer (like the ones we already have set up). port - provide a port that other people can telnet in to. This type of anonymous bouncer would be helpful for everything we do with TCP, including perhaps mail. e From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tom.jennings@f111.n125.z1.FIDONET.ORG (tom jennings) Date: Mon, 16 Nov 92 20:52:02 PST To: cypherpunks@toad.com Subject: ECPA - PRIVACY Message-ID: <3759.2B0852B9@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain Crossposted from FidoNet PUBLIC_KEYS from: GK Pace to: Mike Riddle I just finished reading your article concerning the "laymans view" of the ECPA. I found it very informative, and interesting reading. Thank you for taking the time to study this issue, and share with the rest of us the conclusions you arrived at, upon doing so. I would like to comment upon some of what you've written, in hopes of expanding upon what you have conveyed, and have quoted your article so that those who haven't read your article will find it easier to understand the nature of my comments. ========== Begin Quote ========== Anytime someone passes what they hope to be a private communication to another, they expect that their fellow citizens will respect its privacy. Not only do the customs of society enforce this expectation, statute laws have been enacted to insure it. Thus, everyone knows, or should know, not to tamper with the mail. Everyone knows, or should know, not to electronically eavesdrop ("bug") someone else's telephone calls. And everyone knows, or should know, not to do likewise with computer communications. Alas, not everyone knows that. If everyone did, we wouldn't need laws to protect what ought to be our reasonable expectations of privacy. Not too long ago, the Congress of the United States passed PL 99-508, the Electronic Communications Privacy Act of 1986. In doing so, Congress was recognizing the way technology has changed society and trying to react to that change. ========== End Quote ========== This statement kinda sums up what the discussion is all about... and ties this subject into the provisions of the ECPA. seems like a fitting beginning for the remainder of what I'd like to discuss. ========== Begin Quote ========== What about electronic mail, or "e-mail?" E-Mail has been the single biggest area of misinformation about the new law. First, section 2701 does make it a federal offense to read someone else's electronic mail. That would be exceeding your authorization, since "private" e-mail systems do not intend for anyone other than the sender or receiver to see that mail. But, and a big but, sysops are excluded. ========== End Quote ========== This statement in and of itself lends credibility to the position that we have the right to read any messages passing thru our system... however as you continue to mention, this exclusion is not without conditions, and it isn't necessarily a "right" but is perhaps more accurately defined as an acknowledgement of the technical aspects of our respective systems, and the part we play in accomodating the transfer of E-mail... ========== Begin Quote ========== Whoever staffed the bill for Congress realized that system operators were going to have access to information stored on their systems. ========== End Quote ========== You also of course mention reasons for which this ability might be desired: ========== Begin Quote ========== There are practical technical reasons for this, but there are also practical legal reasons. While the Act does not directly address the liability of sysops for the use of their systems in illegal acts, it recognizes they might have some liability, and so allows them to protect themselves from illegal use. ========== End Quote ========== This statement reeks of common sense... but is there anything in the ECPA which would indicate a "responsibility" on the part of the Sysop to actively monitor such communications, requiring the Sysop to assume the position of censor, police, and/or judge, over the content of those messages passing thru ones system - or does it again acknowledge the techical aspects, and responsibilities the Sysop might be required to exercise in the event the Sysop were to become aware of a message containing potentially illegal information? ========== Begin Quote ========== Sysops are given a special responsibility to go along with this special privilege. Just like a letter carrier can't give your mail to someone else, just like a telegraph operator can't pass your telegram to someone else, just like a telephone operator overhearing your call can't tell someone else what it was about, so sysops are prohibited from disclosing your e-mail traffic to anyone, unless you (or the other party to the traffic) give them permission. ========== End Quote ========== This analysis is again just plain common sense, and again the question arises, are the provisions this refers to those which are acknowledged as technical limitations, accomodating them as such, or are they to be construed as indications that we have obligations above and beyond that which is necessary for the performance of the service we are providing? ========== Begin Quote ========== What all this has said is that the federal criminal code now protects electronic communications the way it previously protected written ones. It understands that mailmen, physical or electronic, have access to the mail they carry, so it tells them not to tell. ========== End Quote ========== This statement seems clear enough... but when viewed from the aspect of the issue of wheather "private" E-mail should be allowed in Fidonet, it gives rise to some questions which can possibly be best conveyed by following the analog you have chosen... i/e that of a mailman, and that of "paper mail". The issue of the Sysop having the ability to read e-mail, as compared to the provisions of the ECPA appear to be more closely comparable to "postcards" being carried by a mailman. In this case, no one could deny that the mailman has a "technical" ability to read the postcards being carried, and that the requirements on the part of the mailman not to divulge such information he/she might happen to notice is clear... as are the responsibilities that would be evident were he/she to become aware of information which could resonably be contrued as illegal in nature. But as in the example of the mailman handling paper mail, there exists the ability to send "private" paper mail, which is enclosed in an envelope. In such cases is is not within the rights of the mailman to open such mail to enable his ability to determine the contents thereof, nor is there any legal responsibility for the mailman to have knowledge of the contents thereof. Indeed it would be a criminal act were the mailman to do so. With the above in mind, wouldn't the introduction of private e-mail capabilities in Fidonet be governed by the same logic? And isn't public key encryption simply the means of wrapping an envelope around e-mail to make it private? -gk --- GenMsg vers:1.14/a * Origin: Privacy... everyone needs it, Lets Route it thru FidoNet (1:374/26) SEEN-BY: 11/2 13/13 101/1 109/25 114/5 123/19 124/1 125/20 28 33 40 111 125 SEEN-BY: 125/180 1212 203/1 23 205/10 209/209 280/1 390/1 396/1 ;;PATH: 374/26 12 1 151/1003 13/13 396/1 203/23 125/125 33 -- tom jennings - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!111!tom.jennings INTERNET - tom.jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tribble@xanadu.com (E. Dean Tribble) Date: Mon, 16 Nov 92 18:19:20 PST To: uunet!shearson.com!pmetzger@uunet.UU.NET Subject: The legality of PGP In-Reply-To: <9211161902.AA08397@newsu.shearson.com> Message-ID: <9211170057.AA11937@xanadu.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain Also, every day they don't enforce the patent is silent reinforcement to the view that their patent is illegitamate (in that it covers a mathematical algorithm). I doubt this has legal standing other than as material to try to convince juries with. dean From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: hugh@domingo.teracons.com (Hugh Daniel) Date: Mon, 16 Nov 92 19:11:21 PST To: cypherpunks@toad.com Subject: Idea on Random Number Generators Message-ID: <9211170302.AA02806@domingo.teracons.com> MIME-Version: 1.0 Content-Type: text/plain The problem with Diodes and the like is that it is possable to induce a pattern into the output of these things. Well, might we be able to look at how and set up a counter such that if the open end is held high on one diode it gets driven down on a second circuit which get added togethor before we go onto to 0/1 ballencing? Next I would set up a drifting clock rate on the device reading the diode, this messes up many efects of interference and might help look for induced patterens! Hey, imagen a random number generator that tells you when the bad guys are trying to influence your random numbers! ||ugh From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: phr@napa.Telebit.COM (Paul Rubin) Date: Mon, 16 Nov 92 19:19:15 PST To: hugh@toad.com Subject: Idea on Random Number Generators In-Reply-To: <9211170302.AA02806@domingo.teracons.com> Message-ID: <9211170318.AA25949@napa.TELEBIT.COM> MIME-Version: 1.0 Content-Type: text/plain It is very hard to generate really random numbers no matter what you do. See the famous RAND book "One Million Random Digits with 100,000 Normal Deviates" for their adventures trying to generate random numbers by counting particle emissions from a radioactive source. Even after all kinds of statistical massaging there were still correlations in the output. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: mark@coombs.anu.edu.au (Mark) Date: Mon, 16 Nov 92 01:23:23 PST To: cypherpunks@toad.com Subject: Nuking CD's Message-ID: <9211160914.AA29147@coombs.anu.edu.au> MIME-Version: 1.0 Content-Type: text/plain If you dont have small children about the house get a container of the right acid so you slip your cd through the slot and 3 bubbles later it's disintegrated. Mark From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nobody@alumni.cco.caltech.edu Date: Mon, 16 Nov 92 21:32:47 PST To: cypherpunks@toad.com Subject: Re: Extortion Explosion Message-ID: <9211170533.AA27523@alumni.cco.caltech.edu> MIME-Version: 1.0 Content-Type: text/plain Cheer up, Cassandra! Things aren't all that bad. > New opportunities in the extortion industry: > > Old problem: the victim may inform the police, making it risky to pick up the > money, which will likely be watched. > New solution: demand payment via cryptomoney. Many forms of electronic money can be traced if there is cooperation between the payer and the bank. For example, [...] However, if she simply _tells_ the bank the value of C, then when Bob goes to deposit it, he can get caught. Fine, if there are some forms of electronic money which can be traced sufficiently to suppress extortion by rivals, and there are some forms which are less traceable, will we have the wisdom to advocate the ones which enable our main oppressor to maintain its monopoly on extorting us? I suspect for many on this list, it would be a bitter pill indeed (it was for me). > Old problem: you may be caught firebombing the house, shooting the victim, > slashing the victim's daughter's face, or whatever; if you subcontract to a > thug, the thug may be caught and inform on you. > New solution: use cryptomoney (and a reputation for paying) to hire thugs > while maintaining anonymity. Well, if thugs know that they are now going to be taking the sole responsibility for their actions, without the safety of knowing that they can rat on their employer if worse comes to worst, then they'll charge more to make up for the greater risk. This will make extortion less profitable. Enough to outweigh the new advantages? > Old problem: providing protection, so that you keep a supply of economically > viable victims from whom to extort. > New solution: Please find one! If the government can't protect victims > from you, how can you protect them from competitors? This is the key point. What stops protection rackets now? Is it really the points listed above: that the money may be traced, that others may falsely benefit from my reputation, that thugs may inform on me? What about simple physical surveillance of property? What about revenge on the transgressors? (As above, the revenge would be restricted to the thugs who did the job, but if it was bad enough it would still have a strong deterrent effect.) My impression is that *the* weak link in extortion activities now is how to pick up the money. This is where most extorters get caught, and it is where our monopolistic extortion & protect racket concentrate their protection activities when faced with a competitor. If someone has a more informed understanding of the practice of "law enforcement authorities" when faced with competitive extortion, please post. Thanks. > Wishful thinking in the pursuit of liberty is no virtue; realism in the > defense of imperfect liberty is no vice. Free-lance oppression isn't freedom, > and I don't want it. > > Cassandra It makes more sense to have good fire and police forces to deal with the bad guys than to get all in a tizzy because the bad guys can talk to each other now without getting caught. If I believed that the police forces could still protect effectively when deprived of their major tool (monitoring the money pickup), then my objection would go away. However, I don't see how they can. It's just too easy to firebomb a house (or any number of other attacks) when no one's looking. Polyanna Cassandra 1784360449840245 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Mon, 16 Nov 92 21:58:10 PST To: cypherpunks@toad.com Subject: re: Re: Rander box and other stuff Message-ID: <3762.2B08842B@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain U> In fact, now that we've dropped the hard drive and the U> keyboard, it might as well just be a dedicated U> crytosystem, make it about 10cmX10cmX1cm and give it an U> ether port, an rs232 port, a pcmcia port and an rj11 port. U> It's doable and would provide the ultimate security. And if all this is a real consideration, it might be better to use a tool that lets you use a completely non-physical key -- one you can remember in your head. Fit the tool to the job... --- ReadMail * Origin: tomj@fidosw.fidonet.org / World Power Systems (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET - Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Mon, 16 Nov 92 22:58:21 PST To: cypherpunks@toad.com Subject: re: November 21 meeting, 12 noon, at Cygnus offices Message-ID: <3765.2B0896A5@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain U> ANNOUNCEMENT U> ============ U> U> The Third Physical Cypherpunks Meeting: Project Planning U> [...] U> U> DIRECTIONS U> ========== [...] U> U> Cygnus Support U> 1937 Landings Drive U> Mt. View, CA 94043 U> U> There's no phone service there yet. Wrong! 415-903-1400 --- ReadMail * Origin: tomj@fidosw.fidonet.org / World Power Systems (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET - Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: mark@coombs.anu.edu.au (Mark) Date: Mon, 16 Nov 92 05:12:40 PST To: cypherpunks@toad.com Subject: Re: Cryptographer jailed for selling crypto to political opposition? Message-ID: <9211161312.AA09303@coombs.anu.edu.au> MIME-Version: 1.0 Content-Type: text/plain >Chances are that Crypto AG has sufficient connexions in high places as to be >able to get its people out of there. I'm familiar with another case >involving a large northern Euro maker of telecom systems who had two >engineers taken hostage in Iraq on some inflated charge, and sentenced to 7 >years... the company fully expects to have its engineers out of there within >six months, no question about it. Shades of Ross Perot. Is it illegal to attempt to attack Iraq's computer systems if you were sitting in your room one day and decided it was time to play havoc right back at them? I realise the CIA etc would be involved in that sort of thing anyway but if a private citizen decided to quietly have a dabble, and he wasnt spotted by the Iraqi's at least, would many people get upset? There is the possibility of encroaching on USA clandestine operations I guess... Are there any precedents for this? Has anyone actually become aware of attempts? :) Mark From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Tue, 17 Nov 92 00:50:35 PST To: hh@soda.berkeley.edu Subject: Re: Rander box and other stuff Message-ID: <199211170849.AA24504@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Eric (Hollander; my last post was to Eric Hughes)- Your "small laptop with (goodies)" was EXACTLY what we were trying to go for in 1983/84. This was the "Cryptex CS-3" project. Remember that there was no such thing as a laptop at the time. What I was proposing was a self-contained portable encryption terminal. It would have measured about a foot wide by 10" long by about 2-3" thick, had an LCD for about six to eight lines of text at a time, two 3-1/2" FDDs, a pair of sockets for "Codepacks" (hardware key storage devices which would have been tamper-resistant and password protected), a good quality keyboard, a modem with modular jack and optional acoustic couplers (for payphones: low-tech anonymity)... the Tempest feature would have been achieved by putting 100dB of white noise on the metal housing, which would have been imperfect but decent enough. There was no plan for a hard drive; the operating software would have been a simple line editor and the crypto routines, all burned into ROM and part of the main processor board. No plans for thermite linings at the time either, though we did have a password routine with a duress option, which would have erased anything on the FDDs or the Codepacks. My first intended market for this thing was the political dissident community, where communication has always suffered to a small but noticeable degree by the "we can't talk on the phone" factor. It never got going because the market was too small. Now it would seem the time has definitely come... though whatever ultimately arises out of the cypherpunk scene will be many many times more sophisticated and versatile. -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: hugh@domingo.teracons.com (Hugh Daniel) Date: Tue, 17 Nov 92 01:21:53 PST To: cypherpunks@toad.com Subject: Random Numbers Boxes and Cypher Processers In-Reply-To: <3762.2B08842B@fidogate.FIDONET.ORG> Message-ID: <9211170913.AA02943@domingo.teracons.com> MIME-Version: 1.0 Content-Type: text/plain Ok folks, sounds like its time to look into the guts of Telebits and XyZel's and see if we can make cypher-processers of them. Both have real CPU's and DSP's, what more do you want? ||ugh From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: phr@napa.Telebit.COM (Paul Rubin) Date: Tue, 17 Nov 92 01:29:58 PST To: hugh@toad.com Subject: Random Numbers Boxes and Cypher Processers In-Reply-To: <9211170913.AA02943@domingo.teracons.com> Message-ID: <9211170929.AA07530@napa.TELEBIT.COM> MIME-Version: 1.0 Content-Type: text/plain Ok folks, sounds like its time to look into the guts of Telebits and XyZel's and see if we can make cypher-processers of them. Both have real CPU's and DSP's, what more do you want? Hardware devices tend to have barely enough processing power to do the function they were designed for---if there were some power left over, the designers would have used a cheaper and weaker processor. Why would you want to do encryption in your modem instead of on the host cpu that the modem is talking to? From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: avalon@coombs.anu.edu.au (Darren Reed) Date: Mon, 16 Nov 92 07:03:26 PST To: cypherpunks@toad.com Subject: AUSCRYPT '92 Message-ID: <9211161438.AA12340@coombs.anu.edu.au> MIME-Version: 1.0 Content-Type: text/plain Hmmm...after reading the announcement in alt.security it seems quite a huge conference for ppl interested in cryptology...anyone going ? (Rather large number of papers being presented too!) darren From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Tue, 17 Nov 92 03:40:49 PST To: Marc.Ringuette@GS80.SP.CS.CMU.EDU Subject: The Dining Cryptographers Protocol In-Reply-To: <9211161815.AA29148@toad.com> Message-ID: <9211171140.AA14731@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Marc.Ringuette writes: >My spin on the Dining Cryptographers Protocol is, it's nifty and >theoretically strong, but in practice mixes are better for almost all >uses. [...] N is typically 100-10000, and M is typically 2-10. >Mixes are more efficient. Let me continue to be a broken record. Cryptography is all economics. You want unconditional security, you pay. Period. Sometimes it's worth it, sometimes it's not. It is not up to the cryptographer to make the economic judgement, it is up to the user. >One advantage of DC-nets is that they're instant; with mixes there must be >some delays in order to accumulate enough cover messages to defeat traffic >analysis. This idea of "delays" providing security for a mix is a common, but incorrect, notion. I don't think Marc is incorrect about this here, merely unclear. In a well used mix system, the latency time to accumulate ten messages would be only a few minutes. It is the reordering of the output messages with respect to the input that provides mix security. Any delay in merely a consequence of the time to collect. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: hugh@domingo.teracons.com (Hugh Daniel) Date: Tue, 17 Nov 92 04:00:36 PST To: cypherpunks@toad.com Subject: Random Numbers Boxes and Cypher Processers In-Reply-To: <9211170929.AA07530@napa.TELEBIT.COM> Message-ID: <9211171151.AA03083@domingo.teracons.com> MIME-Version: 1.0 Content-Type: text/plain Folks had been talking about doing some crypto things in custom hardware about the size of a Telebit. Telebits are just computers with ROM's in them and since Telebits are falling behind the tide of telecommunications I thought it might be nice to reporgram them as remote processers. The DSP's are quite fast and might give us very nice random numbers, the box has buffers and a CPU that can do flat out UUCP 'g' with compression so is likely more processer then most of the Fido systems out there currently. All around a nice box sitting there wasting, waiting to do something usefull. So, maybe hook up the modem with a shielded cable, cut/add something on the phone side so one of the phone line DSP can get random garbage (it might be much easyer then that once someone looks at the design of the things), reporgram the ROMS to add random noise software and maybe even do some number crunching for you (lets see a T2500 has three DSP's in it?) for encryption/decryption. This is all a bit far feched, but as time goes on there will be lots of discarded Telebits (can't do V.32bis, V.fast, FAX, Voice, DSU/CSU, etc.). XyZel also has a smart modem that one can blast ROM's for. Just something to think about on rainey days... ||ugh From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Tue, 17 Nov 92 10:13:59 PST To: cypherpunks@toad.com Subject: Re: Random Numbers Boxes and Cypher Processers Message-ID: <9211171810.AA16367@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Hugh Daniel writes about converting used Telebit modems for crypto use: > Folks had been talking about doing some crypto things in custom > hardware about the size of a Telebit. Telebits are just computers > with ROM's in them and since Telebits are falling behind the tide of > telecommunications I thought it might be nice to reporgram them as > remote processers. The DSP's are quite fast and might give us very > nice random numbers, the box has buffers and a CPU that can do flat > out UUCP 'g' with compression so is likely more processer then most of > the Fido systems out there currently. > All around a nice box sitting there wasting, waiting to do something > usefull. Great idea! Figuring out how to rewire and reprogram a Telebit modem and then writing a port of PGP for it seems like a real service to the half-dozen or so people in the world who have these Telebits and who want what you describe. I hope my good friend Hugh is not angered by my mocking tone! A serious issue is economics, the allocation of scarce resources. Eric Hughes keeps pounding on this. A cheap RNG might be useful, but not for most people. And I can't imagine many people trying to scrounge old Telebits so as to get good random numbers (this assumes someone actually writes the RNG code, tests it for statistical properties, and submits it for "breaking" by others). More important is getting easy to use software out there. Modifying relatively scarce hardware (which Telbitw are, outside our circle of friends :-}) goes against this "populist crypto" philosophy. Zimmerman's really important contribution was to actually get RSA out to anyone with a PC or vanilla UNIX. Finally, why focus on the Telebit? I have an old Processor Technology "Sol" computer that could be similary reprogrammed for RNG use. Any takers? (Just kidding.) --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: awaiting Macintosh version. -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: awaiting Macintosh version. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: fnerd@smds.com (FutureNerd Steve Witham) Date: Tue, 17 Nov 92 08:16:02 PST To: cypherpunks@toad.com Subject: Re: Hackers, Crackers Message-ID: <9211171542.AB00557@smds.com> MIME-Version: 1.0 Content-Type: text/plain >Let's cut out this elitist "crackers" crap altogether. Well, I don't know about this guy, but there's something similar that occurred to me during the hackers conference. Some of the people on this list heard me express it badly, and I wanted to clarify. We always used to distinguish hackers from crackers. But cracking reveals the cracks in a way that nothing else does. It makes them real, sometimes laughably or painfully so. Electronic privacy is currently a joke. It's bad. You need to know what kinds of attacks you're trying to defend against. I used to think those arguments were rationalizations. Now I'm glad there are people who know this stuff, who are actually doing it. Some of "them" are on what I think of as the good side, and "we" need that kind of knowledge, if only as an occasional splash of cold water, a spur (to switch metaphorical, er, horses in mid, um, stream). -fnerd quote me fnerd@smds.com (FutureNerd Steve Witham) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: O'Hara Walter Date: Tue, 17 Nov 92 12:20:42 PST To: Cypherpunks Subject: Any suggestions on what to do with this junk? Message-ID: <2B098C48@gallows> MIME-Version: 1.0 Content-Type: text/plain Hi, I'm new to this list so pardon my ignorance/naivete I'm a systems admin type who is upgrading a bunch of desktop computers next month. As a consequence, about half a dozen computers of the XT vintage will fall under my wing with instructions to "find something useful to do with them." Are there any good suggestions out there about what I could do with old 8-bit technology vis-a-vis crypto? Thanks, Walt From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: mark@coombs.anu.edu.au (Mark) Date: Mon, 16 Nov 92 20:01:36 PST To: cypherpunks@toad.com Subject: Re: IP bouncers Message-ID: <9211170401.AA22825@coombs.anu.edu.au> MIME-Version: 1.0 Content-Type: text/plain >Remailers are extremely important, but we also need anonymous IP bouncers. > >An IP bouncer might work like this: there would be a user, a server, and a >target. The server and user would each have key pairs (probably a new pair >for each session), and would trade public keys. The user would request a >port from the server, and then would issue (encrypted) commands to the >server. > >These commands might include: >telnet - open a connection to the target. The target would route its >ignore - get ready to recieve lots of random bits and perhaps pass them on to >mail - act as an anonymous remailer (like the ones we already have set up). >port - provide a port that other people can telnet in to. >This type of anonymous bouncer would be helpful for everything we do with I have and use something along these lines. It was written by someone for other purposes but it should be easy enough to port to this application. It's rather inefficient at the moment unfortunately. I'll see what I can do to it. Mark From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hollander Date: Tue, 17 Nov 92 16:37:25 PST To: "George A. Gleason" Subject: Re: Rander box and other stuff In-Reply-To: <199211170849.AA24504@well.sf.ca.us> Message-ID: <9211180036.AA19273@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain I thought of another thing to add to my wish list for a dedicated cryptosystem: analog input and output, for use as a phone line scambler. Such a system could be manufactured for not too much money, I think. It would be like a specialized version of the Apple Newton. Apple would never make something like this, though; they are becoming good buddies with our favorite agency. Also you would probably need a permit to own thermite. e From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: "erodenbeck" Date: Tue, 17 Nov 92 15:50:34 PST To: cypherpunks@toad.com Subject: a patently false rumor Message-ID: MIME-Version: 1.0 Content-Type: text/plain all right so i got it from MONDO. accepting that the world has already been taken over and that if its not on tv it doesn't happen I submit and propose to you that it is for the taking but of course you already know that From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: phr@napa.Telebit.COM (Paul Rubin) Date: Tue, 17 Nov 92 17:22:27 PST To: eichin@cygnus.com Subject: Rander box and other stuff In-Reply-To: <9211180058.AA15692@tweedledumber.cygnus.com> Message-ID: <9211180121.AA02510@napa.TELEBIT.COM> MIME-Version: 1.0 Content-Type: text/plain Let's see -- an ISDN-quality (quality? I use the term loosely) codec should be under $50 single quantity, the data rate isn't very high so you don't need much of a CPU (6811 might even be enough, and they're easy to interface to things -- lots of on-chip I/O). You'd need a modem-style encoder for the output (running digital from box-to-box -- "analog" scrambling (Time or Frequency domain) is way too easy to break) so maybe another $50 DSP chip... after all, you don't need to support 30 different baud rates, just one data rate with perhaps a low-line-quality backoff. The codec is pretty cheap, but you want a nice low bit rate so you can send the encrypted data over the phone. Some talk of how to do this is happening on sci.crypt. I have a scheme which I plan to float around at the cypherpunks meeting on Saturday. However, the hardware ends up being on the expensive side ($150 or so). From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Brad Huntting Date: Tue, 17 Nov 92 18:50:46 PST To: cypherpunks@toad.com (Eric Hughes) Subject: No Subject In-Reply-To: <9211150654.AA20021@toad.com> Message-ID: <199211180249.AA00524@misc.glarp.com> MIME-Version: 1.0 Content-Type: text/plain Please add me to the cypherpunks mailing lists. Here are my two public PGP keys if your interested: brad -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQBNAir99E4AAAECALCo19KN/eLnMKicKH9NK9uY3gpaNAZ3vMPpiIAOH5sWOfxK t0bv/T0NnUC0kGr+kJsYAx7dTGc4C/Rx3rZuO/8ABRG0JkJyYWQgSHVudHRpbmcg PGh1bnR0aW5nLjUxMkBnbGFycC5jb20+iQBFAgUQKv32PjNoJjtQO7sNAQHQPAF/ TK1mO9Bpm0JCtxqYvCilvMEYohlDmC6pTl6XPxViil8WXOs04nkq+vy26+QCrgd4 =T+VL -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQA9Air9nn0AAAEBgNK6vPMg3KFzZxuB4llRoKEOxJvlO/TE0NNObgpRFs+px45+ 3z4YQbgzaCY7UDu7DQAFEbQiQnJhZCBIdW50dGluZyA8aHVudHRpbmdAZ2xhcnAu Y29tPokAVQIFECr99nML9HHetm47/wEB6OMCAK82O/iSxEK6PzUd4Y0FXvfoJRKD F/h+6NvbIf2tt0b7IARoLL2e/fw0AaR0TY2U+47s3NBWEAL1Iy+5AV16qyc= =cpUM -----END PGP PUBLIC KEY BLOCK----- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: "Mark W. Eichin" Date: Tue, 17 Nov 92 16:58:34 PST To: hh@soda.berkeley.edu Subject: re: Rander box and other stuff In-Reply-To: <9211180036.AA19273@soda.berkeley.edu> Message-ID: <9211180058.AA15692@tweedledumber.cygnus.com> MIME-Version: 1.0 Content-Type: text/plain >> Also you would probably need a permit to own thermite. I don't think there's a problem with owning it or making it -- only (perhaps) selling it and transporting it; thermite is not strictly an explosive. You may wish to consider alternate ways of destroying the data, especially if you wish to ever transport the device on a commercial airline; if you've only got one RAM device that has critical data in it, then simply arrange for the battery backup circuit to have a "high current mode", perhaps feeding more of the pins -- a "light emitting RAM" should be just as blank as one burned through by thermite. >> cryptosystem: analog input and output, for use as a phone line scambler. >> Such a system could be manufactured for not too much money, I think. It Let's see -- an ISDN-quality (quality? I use the term loosely) codec should be under $50 single quantity, the data rate isn't very high so you don't need much of a CPU (6811 might even be enough, and they're easy to interface to things -- lots of on-chip I/O). You'd need a modem-style encoder for the output (running digital from box-to-box -- "analog" scrambling (Time or Frequency domain) is way too easy to break) so maybe another $50 DSP chip... after all, you don't need to support 30 different baud rates, just one data rate with perhaps a low-line-quality backoff. The connectors and the box are probably the major recurring cost (the chip prices will go way down in quantity.) Am I missing anything? The technology level of the Newton seems to be a bit of overkill (unless you actually want that kind of user interface.) _Mark_ : note that this is an unsigned message. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Tue, 17 Nov 92 21:27:43 PST To: cypherpunks@toad.com Subject: re: Message-ID: <3790.2B09CE75@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain U> From: huntting@glarp.com (Brad Huntting) U> two public PGP keys if your interested: Why did you sign your key? --- ReadMail * Origin: tomj@fidosw.fidonet.org / World Power Systems (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET - Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Wed, 18 Nov 92 01:03:18 PST To: phr@napa.Telebit.COM Subject: Re: Random Numbers Boxes and Cypher Processers Message-ID: <199211180900.AA05387@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Why do encryption in the modem instead of the host cpu? Because then you have a product which will work with any computer, and all you need is software to make it adapt to whatever you're using. Might make it easier to encrypt and decrypt on the fly also, though this point is of debatable merit. -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Judith Milhon Date: Wed, 18 Nov 92 12:04:21 PST To: cypherpunks@toad.com Subject: damn: sorry Message-ID: <199211182003.AA08793@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain my column in the current issue of mONdo pointed readers to this list, rather than -request. the final line edit didn't correct that, and the issue is now on the stands. if there ARE any readers, they may blunder in here cluelessly, and it's all my fault. damn sorry. >jude< From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: edgar@spectrx.Saigon.COM (Edgar W. Swank) Date: Wed, 18 Nov 92 15:04:26 PST To: Cypherpunks Subject: Request for more detail Message-ID: MIME-Version: 1.0 Content-Type: text/plain On Nov 15, Phil Karn wrote: After reading the details of that (formerly) secret back-room agreement between NSA and SPA, I don't think I'll *ever* trust a commercial encryption package, especially one for which source code is unavailable for scrutiny. Could Phil or anyone give more details about that agreement and/or where one could read more about it? -- edgar@spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Judith Milhon Date: Wed, 18 Nov 92 13:18:24 PST To: cypherpunks@toad.com Subject: Re: a patently false rumor Message-ID: <199211182113.AA22716@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain uh oh: i gave the wrong contact info with that Irresponsible emission: it was spozed to be cypherpunks-request@toad.com. HOWEVER: here you are, d00d. you've landed in the midst of a multistrand technical argument about the logistics of applied cryptography... >jude< From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hollander Date: Wed, 18 Nov 92 18:07:09 PST To: "McGrath, James" Subject: Re: PGP to SMTP mailer In-Reply-To: <9211182353.AA04620@crop.lincoln.cri.nz> Message-ID: <9211190206.AA13706@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain sounds like it might be a good idea to implement windowing support for pgp. we could write versions for windows, xwindows, mac and possibly other systems. it would not be too hard to write a generic windowed pgp and then make it specific for these systems. e From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: wcs@anchor.ho.att.com (Bill Stewart) Date: Wed, 18 Nov 92 19:16:30 PST To: cypherpunks@toad.com Subject: Re: PGP to SMTP mailer Message-ID: <9211190308.AA25694@anchor.ho.att.com> MIME-Version: 1.0 Content-Type: text Embedding SMTP support into a PGP mail reader is the wrong approach, though the DOS world seems to be going bananas over mail APIs. You gain a lot of flexibility by separating the Mail User Agent, which handles user interface, file storage, encryption and other decoding, etc. from the Mail Transfer Agent function, which lets you send/receive PGP messages over whatever mail systems you have available. That way you don't need to write one PGP program for SMTP, another for uucp, another for Fido, etc. On the other hand, I'd be interested in seeing a PGP hook built into Lotus Notes - does it have an open programming or file-transfer interface? It seems to be multimedia netnews for the mundanes, and getting some flavor of Public-Key encryption out there could help spread the technology, especially if Lotus were to license RSA support. Bill Stewart, somewhere in New Jersey. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: crunch@netcom.com (John Draper) Date: Thu, 19 Nov 92 03:54:30 PST To: cypherpunks@toad.com Subject: Finally back Message-ID: <9211191150.AA16617@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Greetings, I'm finally back on-line for a few days here, and want to make the most of it. I'll be checking my Email frequently during the day tommorrow, and reading all back messages (All 120 of them), getting cought up on the latest... Before I forget, if anyone wants to send me an encrypted message, My key is as follows, so Pse add it to your pubkey list in case you want to send me an encrypted message. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQBNAisLBHoAAAECALXEdhLz3F9RmO6ypGFbR4/YqLgbHOrkDxVEgGMCMVQJh8zr /75cTwvXI7dyGorWqvkvhUw1jU7BvMSvyK9YOv8ABRG0IkpvaG4gVC4gRHJhcGVy IDxjcnVuY2hAbmV0Y29tLmNvbT4= =rTrk -----END PGP PUBLIC KEY BLOCK----- I haven't really started collecting pub keys yet, but I propose that we have a list stored somewhere on an ftp site. Or perhaps someone who has the keyrings. I'll have more things to Email later on, it has been a long night here, finally got to most Email. Had one fatal crash of the MacPGP program where it hung up the system when I tried to encrypt a message to someone. I have now tested out the PGP program fully, and now know how to use it. I can see plenty of omprovements I will want to make, but to do it right, we might have extensive changes to make. Still not done looking at code yet, but the modules I ve seen are pretty easy to inderstand. Later... John D> From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Thu, 19 Nov 92 19:40:10 PST To: cypherpunks@toad.com Subject: Re: How far is to far? Message-ID: <9211191822.AA06330@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Mark (mark@coombs.anu.edu.au) writes: > Maybe it's not in the spirit of this mailing group but what of the question > of purposeful abuse of the anon mailers/newsposters? Say for instance some > person posts either a sh*tload of garbage to every known group, flooding > the USENET or a more personal attack whereby they send out anonymously > information that was so fundamentally personal to someone they could > possibly react very badly.... > > What if someone posted some top secret information and the various three > letter acronyms all went out for someone's blood. Abuses of various sorts will surely occur. The same thing happens with the postal systems of the world ("blackmail," poison pen letters, ransom demands, extortion threats, child pornography, sedition, etc.), with the phone systems (ditto above), freely available Xerox machines, and so on. Computers and computers nets will be no different. A difference is that the authorities are trying to stop all such abuses on computer nets and all such things they dislike by banning privacy and by restricting use. This is a doomed effort. > As a few people have mentioned they would *like* the opportunity to use > an anon system but the initial step of creating and running it isnt so > appealing due to the fundamental dangers of it. > > Most people would respect such systems but you find one really rotten or > immature loser that will use it for there own anti-social ends. This is where "reputations" and "kill" files come to the fore. Immature flames and other minor crimes are best dealt with by "down-checking" the reputation of the digital pseudonym of the offender. (Completely anonymous postings, where no "handle" or digital pseudonym is provided are likely to be "killed" by most readers.) For more serious "crimes" perpetrated by crypto users, well, nothing's perfect. As I said above, they have other channels to use as well. An advantage of the digital pseudonym nets is that these criminals don't know who you are or where you live (a la "True Names") and hence can't perpetrate certain crimes. When in cypherspace, be careful! --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: awaiting Macintosh version. -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: awaiting Macintosh version. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: hkhenson@cup.portal.com Date: Thu, 19 Nov 92 20:02:08 PST To: cypherpunks@toad.com Subject: Re: The legality of PGP Message-ID: <9211191023.1.22089@cup.portal.com> MIME-Version: 1.0 Content-Type: text/plain Perry writes PGP is based on RSA . . . which has not granted a license for people to use . . . . using PGP is possibly a pattent violation . . . I wonder--I have RSA Mailsafe. Do you think that would give me a license to use RSA if I loaded up PGP? Keith From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: fen@genmagic.com (Fen Labalme) Date: Thu, 19 Nov 92 19:37:21 PST To: cypherpunks@toad.com Subject: Re: PGP to SMTP mailer Message-ID: <9211191957.AA18482@> MIME-Version: 1.0 Content-Type: text/plain [wcs@anchor.ho.att.com (Bill Stewart) writes:] >On the other hand, I'd be interested in seeing a PGP hook built into >Lotus Notes .... if Lotus were to license RSA support. I believe that Lotus has licensed RSA technology for notes. Fen ~~~ ~~~ Fen Labalme General Magic We Are Everywhere 40 Carl Street #4 2465 Latham Street ------------------- San Francisco CA 94117 Mountain View CA 94040 The US Constitution 415/731-1174 (home) 415/966-6273 (my desk) may not be perfect, 415/965-9424 (fax) but it's better than what we've got now. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: fen@genmagic.com (Fen Labalme) (by way of fen@genmagic (Fen Labalme)) Date: Thu, 19 Nov 92 19:37:21 PST To: cypherpunks@toad.com Subject: Re: Anymous Remailers and Newsposters Message-ID: <9211191959.AA18490@> MIME-Version: 1.0 Content-Type: text/plain [VANGUARD@gribb.hsr.n0 writes:] >I have been aware of the need to make anonymous postings on the >newsnet. I have made most of the neseccery softwar to allow for such >a gateway, but it seems that the local system administartor is >strongly opposed to the idea of the protection given by beeing >anonymous. Such a gateway has an enourmous potential, and it is easy >to see why some wouldn't like the idea. I just thought I'd mention that there are several anonymous remailers currently in use by users of the alt.sex.bondage newsgroup. Unfortunately, I don't have the addresses handy, but they re-post the address and instructions for use every week or so... Fen ~~~ ~~~ Fen Labalme General Magic We Are Everywhere 40 Carl Street #4 2465 Latham Street ------------------- San Francisco CA 94117 Mountain View CA 94040 The US Constitution 415/731-1174 (home) 415/966-6273 (my desk) may not be perfect, 415/965-9424 (fax) but it's better than what we've got now. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: fen@genmagic.com (Fen Labalme) (by way of fen@genmagic (Fen Labalme)) Date: Thu, 19 Nov 92 19:38:52 PST To: cypherpunks@toad.com Subject: Re: How far is to far? Message-ID: <9211191959.AA18495@> MIME-Version: 1.0 Content-Type: text/plain [mark@coombs.anu.edu.au writes:] >Maybe it's not in the spirit of this mailing group but what of the question >of purposeful abuse of the anon mailers/newsposters? Say for instance some >person posts either a sh*tload of garbage to every known group, flooding >the USENET or a more personal attack whereby they send out anonymously >information that was so fundamentally personal to someone they could >possibly react very badly.... I see two answers: one is public censure, which has appeared to work to a large extent in at least one newsgroup whose users make habitual use of an anonymous remailer (alt.sex.bondage) . Another is broadcatch, a favorite topic of mine, which is concerned with the filtering of information. (Note: where "broadcast" is a one-source-to-many subscriber system, "broadcatch" scans many sources for information relevant to one subscriber. The end result is less quantity and higher quality.) With broadcatch, you could turn off threads of conversation you were not interested in, block out flamers, and IGNORE ANONYMOUS EMAIL in general. Of course, pseudonyms may come to be trusted and thus not filtered out, though they, too, are cryptographically anonymous. (Another common mechanism of broadcatch filters is to allow through articles with mentions of the subscriber's name.) Also, in the long run, when networks are made up of smarter, cooperating machines, neighboring machines to a flamer that is generating mass ammounts of email will begin to choose not to listen as often at that address. In sum, I think that it is someone's right to say anything they want, as long as I don't have to listen. Fen ~~~ ~~~ Fen Labalme General Magic We Are Everywhere 40 Carl Street #4 2465 Latham Street ------------------- San Francisco CA 94117 Mountain View CA 94040 The US Constitution 415/731-1174 (home) 415/966-6273 (my desk) may not be perfect, 415/965-9424 (fax) but it's better than what we've got now. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: "McGrath, James" Date: Wed, 18 Nov 92 15:54:04 PST To: cypherpunks@toad.com Subject: PGP to SMTP mailer Message-ID: <9211182353.AA04620@crop.lincoln.cri.nz> MIME-Version: 1.0 Content-Type: text/plain Gudday, People were suggesting that someone write a mailer with PGP support, and because my site uses lots of PCs connected to an internet host, I was thinking of using an SMTP-client based system. That much I think I can do. However, I am also now trying to learn to program for Windows, and the idea of a windows based PGP is quite nice, and with an integrated mailer it would be great. Is anyone else working on either of these two things? What are the implications (security wise) of using something like windows where tasks aren't really that hidden from each other and that swaps to disk? I notice that PGP bothers to erase its stacks and work areas. It seems that this would be a lot less possible under windows. Comments? Jim McGrath From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: VANGUARD@gribb.hsr.no Date: Thu, 19 Nov 92 04:57:31 PST To: cypherpunks@toad.com Subject: Anymous Remailers and Newsposters Message-ID: MIME-Version: 1.0 Content-Type: text/plain I have tried out the anonymous reply service at hal@alumni.caltech.com and I am very satisfied with the service, however I have a suggestion that will improve the security. The way it works now it is possible to link different messages that have the same originator, simply by comparing the return adress. Example I have a deal going with Bob and a different deal going with Alice, and it would be of my interest that Alice and Bob didnt know they where dealing with the same person. If a had given the the same Anonymous reply adress they could compare them and see that in fact they were dealing with the same person, thereby making it easier to trace me: Solutions: Use different remailers that have different public keys, or allow for a field of "random" i.e. different bytes so that if the return adress is identical the encoded block would be totally different. I have been aware of the need to make anonymous postings on the newsnet. I have made most of the neseccery softwar to allow for such a gateway, but it seems that the local system administartor is strongly opposed to the idea of the protection given by beeing anonymous. Such a gateway has an enourmous potential, and it is easy to see why some wouldn't like the idea. I have also been thinking about up such a gateway in my own name (i.e the anonymous postings would appear to come from me, with some sort of disclaimer) but I have so far been reluctant to take the risk of beeing identified with things that are none of my business. Any comments and suggestions would be appreciated. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: VANGUARD@gribb.hsr.no Date: Thu, 19 Nov 92 05:24:18 PST To: cypherpunks@toad.com Subject: Re: Anonymous Reply... Message-ID: MIME-Version: 1.0 Content-Type: text/plain Well after I made my last posting I realized there is a mush better way to avoid having identical reply adresses: Simply let pgp make a new encryption of the return adress. This works because pgp uses a different key for each message, and the key is the only information that is encrypted with th RSA algorithm. In other words if you encrypt a message once with a key and encrypt the same message again with the same key, the resulting ciphertext will be totally different, with exeption of the first bytes and the length of the text. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: "McGrath, James" Date: Wed, 18 Nov 92 17:36:04 PST To: cypherpunks@toad.com Subject: PGP to SMTP mailer Message-ID: <9211190135.AA04790@crop.lincoln.cri.nz> MIME-Version: 1.0 Content-Type: text/plain Gudday, People were suggesting that someone write a mailer with PGP support, and because my site uses lots of PCs connected to an internet host, I was thinking of using an SMTP-client based system. That much I think I can do. However, I am also now trying to learn to program for Windows, and the idea of a windows based PGP is quite nice, and with an integrated mailer it would be great. Is anyone else working on either of these two things? What are the implications (security wise) of using something like windows where tasks aren't really that hidden from each other and that swaps to disk? I notice that PGP bothers to erase its stacks and work areas. It seems that this would be a lot less possible under windows. Comments? Jim McGrath From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: crunch@netcom.com (John Draper) Date: Thu, 19 Nov 92 19:33:56 PST To: cypherpunks@toad.com Subject: Some proposals to consider Message-ID: <9211200059.AA27380@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Greetings fellow cypherpunks: A lot has happened since I got on here last Friday. My previous message contains my public key, Pse use it if you want to send me private mail. I bet the NSA boys are tearing the hair out of their heads by now, but it's about time we do something to preserve our privacy. It is my plan to help "organize" the Mac implementation of PGP, by putting together a Mac Implementation team of programmers to beef up MacPGP, by added better GUI, such as cutting and pasting of keys DIRECTLY into key rings without having to go through a file (makes for added security). My plans also call for tight coordination with the other platform development teams. I've been getting good support for my ideas on implementing machine independent modules or "Libraries" of PGP routines that don't include I/O portions, but after looking at the code, I see this is going to take a lot of work, both in organizing the effort, and in implementing the code. Just how this is going to be done, I'm not sure, but this is what cypherpunks is all about. To hash these things over, flame on each other's ideas, etc. So far, the Mac inplementaion team consists of the following individuals, and are (or soon will be) working closly with Eric Hughs, Phil Zimmerman, and the other PGP folks Mac PGP team: Richard Outerbridge [71755.204] Jim Clausing internet: jac@cis.ohio-state.edu Zbigniew Fiedorowicz internet: fiedorow@function.mps.ohio-state.edu INTERNET:crunch@netcom.com INTERNET:crunch@netcom.com Doug McNaught internet: doug@midget.towson.edu Philip Zimmermann internet: prz@sage.cgd.ucar.edu I talked with another individual last evening who also wants to be added to the team, but the others haven't yet been introduced to him yet. It is my plan to propose this idea to the PGP meeting at Sygnus this upcoming Saturday at noon. Then, I'll report to those that couldn't make it, due to their location. The progress on the Rander box is as follows: I am currently evaluating several proposed designs, and have sent out queries for data sheets on devices I plan on checking out for use, prices, etc. I have been studying the PGP code, and can see it's going to take a lot of work to get it into a form where true machine portability can be realized. As a Mac purist, a abhore the idea if translating Mac GUI actions into ascii text and sending it to the current PGP "engine". Although it would take a lot of work, I propose that we develop PGP to have the following form. a) Encryption engine library - Main set of routines currently in the PGP program dealing with encryption of data. These would be a set of "support" routines that would permit encryption of data in files, as well as data in memory. These would be totally machine independent, and only ONE set of sources should exist and contain compiler options for platform specific code. These functions would then return error codes instead of console output. Needed "key phrases" can be passed in as "char *", and sucessful operations would return NULL or if error, an appropriate code be returned. Other routines would be necessary, such as telling it where the random ring buffer is located, and how long it is. These routines would maintain their own pointers into this buffer. This library would call routines in the Random number manager and pass information such as where the buffer is located. See below: b) Key management library - Main set of routines that know how to manage the keyring files, it would have functions designed to extract keys, add and remove them, and work on the keyring files directly. Again, these would be machine independent routines. This would also call routines in the Random number manager below. c) Random number management - Main set of routines to manage a "circular buffer" of random numbers used to generate keys. This would work with both software and hardware random number generators, and would provide externally machine independent functions, but internally they would be machine specific. d) GUI's for the various PGP application programs. Mail management, file management, network applications, etc, all calling the routines in a,b, and c. Also includes Hypercard Xcmds, etc. Items a and b should have only ONE set of source code, and be maintained and managed by existing people. Items c would also be same source code, but have conditional compiler statements to "switch in" the machine dependent portions as apppropriate. I think it's possible to design the code in a and b to have very few machine dependent conditional compiler #ifdef statements, by forming the main PGP guts portion to operate on textual input in the form of "char *" instead of console input, and let the calling code pass "char *" to PGP library routines. Machine dependent stuff is in (d) and might include existing UNIX PGP "main()", Mac PGP main application, and lower level "utilities" such as Hypercar XCMD's etc. In fact, it is even possible to build these libraries to use NO global variables, and use structures instead. But me, being Mac biased, will probably get a lot of resistance to this proposal, but it is just that, a PROPOSAL. At any rate, I think that portability issues would be better solved if we were to adopt C code portability and to assume that not ALL platforms work well with console type input, and that Console I/O should be "factored out" of the machine independent portions of the existing PGP code. So, what way folks, has anyone got a better idea or proposal? Cheers JD From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: wmo@rebma.rebma.mn.org (Bill O'Hanlon) Date: Thu, 19 Nov 92 19:43:57 PST To: cypherpunks@toad.com Subject: Another remailer Message-ID: MIME-Version: 1.0 Content-Type: text/plain I've installed Eric's anonymous remailer scripts at remailer@rebma.mn.org. Rebma is my home machine... It's not right on the Internet, but it is a Telebit connection away. Feel free to use it as you see fit. I don't have Hal's PGP additions, but I am interested in running them. Hal's messages said he hoped more people put up remailers so that they could be chained together. Sounded good to me. -Bill -- Bill O'Hanlon wmo@rebma.mn.org From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: phr@napa.Telebit.COM (Paul Rubin) Date: Thu, 19 Nov 92 22:54:40 PST To: fen@genmagic.com Subject: Re: PGP to SMTP mailer Message-ID: <9211200654.AA27391@napa.TELEBIT.COM> MIME-Version: 1.0 Content-Type: text/plain Those of us who support the freedom to use cryptography, run PGP, and write whatever programs we wish (cryptographic and otherwise) should be aware that the boycott against Lotus and Apple is still on. By making PGP run on Macintoshes and with Lotus Notes, we improve the usefulness of those systems and thereby help our enemies take away our rights. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: mark@coombs.anu.edu.au (Mark) Date: Thu, 19 Nov 92 04:30:00 PST To: cypherpunks@toad.com Subject: IP Bouncer.. source included. Message-ID: <9211191229.AA12629@coombs.anu.edu.au> MIME-Version: 1.0 Content-Type: text/plain Ok an IP bouncer is something that runs on a host that basically accepts connections on one port and redirects them to another specified host and port. The one below is for tcp connections but it could also be for udp with a little work. I actually have the code for a 'server' version of this that you connect to it, tell it which host you want and then it opens a connection to it. It's on another machine at the moment which is down. I had the sent to me via IRC a while ago and have used it off and on. Ive been meaning to fine tune it a bit as it's supposed to chew CPU a bit... -------cut here--------cut here--------cut here---------cut here------------- /* This file is telserv.c and is part of the Telnet Server package v. 1.0, written by "Hal-9000". Much of this package was developed by Richard Stephens and my thanks go to "Xanadude" for providing me with that section. To compile, type "cc -O -s telserv.c -o telserv". */ #include #include #include #include #include #include #include #define SERV_TCP_PORT 12345 /* port I'll listen for connections on */ #define REM_HOST_ADDR "128.128.128.7" /* host I will bounce to */ #define REM_TCP_PORT 23 /* port I will bounce to */ main() { int sockfd, newsockfd, clilen, childpid; struct sockaddr_in cli_addr, serv_addr; sockfd = socket(AF_INET, SOCK_STREAM, 0); bzero((char *) &serv_addr, sizeof(serv_addr)); serv_addr.sin_family = AF_INET; serv_addr.sin_addr.s_addr = htonl(INADDR_ANY); serv_addr.sin_port = htons(SERV_TCP_PORT); bind(sockfd, (struct sockaddr *) &serv_addr, sizeof(serv_addr)); listen(sockfd, 5); while (1) { clilen = sizeof(cli_addr); newsockfd=accept(sockfd, (struct sockaddr *) &cli_addr, &clilen); fcntl(newsockfd,F_SETFL,O_NDELAY); childpid = fork(); if (childpid == 0) { /* child process */ close(sockfd); /* close original socket */ telcli(newsockfd); /* process the request */ exit(0); } close(newsockfd); /* parent process */ wait(0); } } telcli(clisockfd) { int servsockfd; struct sockaddr_in serv_addr; bzero((char *) &serv_addr, sizeof(serv_addr)); serv_addr.sin_family = AF_INET; serv_addr.sin_addr.s_addr = inet_addr(REM_HOST_ADDR); serv_addr.sin_port = htons(REM_TCP_PORT); servsockfd = socket(AF_INET, SOCK_STREAM, 0); connect(servsockfd, (struct sockaddr *) &serv_addr, sizeof(serv_addr)); fcntl(servsockfd,F_SETFL,O_NDELAY); communicate(servsockfd,clisockfd); close(servsockfd); exit(0); } communicate(servsockfd,clisockfd) { char rec[1]; int num; extern int errno; while (1) { num=read(servsockfd,rec,1); if ((num==-1) && (errno != EWOULDBLOCK)) return; if (num==0) return; if (num==1) write(clisockfd,rec,1); num=read(clisockfd,rec,1); if ((num==-1) && (errno != EWOULDBLOCK)) return; if (num==0) return; if (num==1) write(servsockfd,rec,1); } } From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tenney@netcom.com (Glenn S. Tenney) Date: Thu, 19 Nov 92 23:49:58 PST To: phr@napa.Telebit.COM (Paul Rubin) Subject: Re: PGP to SMTP mailer In-Reply-To: <9211200654.AA27391@napa.TELEBIT.COM> Message-ID: <9211200744.AA28178@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain phr@napa.Telebit.COM says: > > Those of us who support the freedom to use cryptography, run PGP, and > write whatever programs we wish (cryptographic and otherwise) should > be aware that the boycott against Lotus and Apple is still on. By > making PGP run on Macintoshes and with Lotus Notes, we improve the > usefulness of those systems and thereby help our enemies take away our > rights. > Oh give me a break! I don't see YOU boycotting the Hayes modem standard (AT). Enough of this boycott crap! -- Glenn Tenney voice: (415) 574-3420 fax: (415) 574-0546 tenney@netcom.com Ham radio: AA6ER From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Fri, 20 Nov 92 00:29:17 PST To: fen@genmagic.com Subject: Re: How far is to far? Message-ID: <199211200828.AA03551@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Re. Fen's proposal to utilise "broadcatch." We still have the problems of slander/libel and breaches of legitimate secrecy. At risk of sounding naive/idealistic, it would seem that since there is no way to block information passing through the net (aside from screening at source, impractical at least!), the solution rests with education of the net-using population. Power carries responsibility in equal measure. We are giving ourselves the power which comes with privacy; we can begin to take responsibility for promoting a sense of ethics in the use of the net. One possible place to start would be at highschool-level computer courses; perhaps with accomplished hackers coming in and giving guest lectures or something... the culture of computer-literate youth can begin to include strong ethical positions regarding respect for the privacy of others, respect for truthfulness, and a position of personal conscience regarding law and authority. Re the latter, this isn't the same thing as blind obedience, but rather the idea that if there is to be disobedience it needs to be grounded in deeply held personal ethics, as for example in the case of civil disobedience. A strong set of cultural values in these areas might set a tone which discourages mindless negativity and wrecking. Now there will always be those who wreck for thrills.... I don't know how to address that problem except to note that such individuals are hardly stopped today by the threat of prosecution. -gg@well.sf.ca.us From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: mark@coombs.anu.edu.au (Mark) Date: Thu, 19 Nov 92 05:43:04 PST To: cypherpunks@toad.com Subject: How far is to far? Message-ID: <9211191342.AA18149@coombs.anu.edu.au> MIME-Version: 1.0 Content-Type: text/plain Maybe it's not in the spirit of this mailing group but what of the question of purposeful abuse of the anon mailers/newsposters? Say for instance some person posts either a sh*tload of garbage to every known group, flooding the USENET or a more personal attack whereby they send out anonymously information that was so fundamentally personal to someone they could possibly react very badly.... What if someone posted some top secret information and the various three letter acronyms all went out for someone's blood. As a few people have mentioned they would *like* the opportunity to use an anon system but the initial step of creating and running it isnt so appealing due to the fundamental dangers of it. Most people would respect such systems but you find one really rotten or immature loser that will use it for there own anti-social ends. Comments? Mark mark@coombs.anu.edu.au mark@gnu.ai.mit.edu markm@rmit.edu.au From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: crunch@netcom.com (John Draper) Date: Fri, 20 Nov 92 01:01:11 PST To: cypherpunks@toad.com Subject: Lots of work to do. Message-ID: <9211200857.AA02944@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain I said earlier: >> I've been getting good support for my ideas on implementing machine >>independent modules or "Libraries" of PGP routines that don't include >>I/O portions, but after looking at the code, I see this is going to >>take a lot of work, both in organizing the effort, and in implementing >>the code. Just how this is going to be done, I'm not sure, but this >>is what cypherpunks is all about. To hash these things over, flame on >>each other's ideas, etc. Miron says: >It would be very nice if PGP behaved better as a UNIX filter. For >example, I'd like it to return an exit code if it fails. I'd >also like it to have a flag that disables any access to the tty >for prompts. For example, if I have an automatic filter that >tries to decrypt all incoming messages, I don't want it to prompt >for a secret ring file when it can't decrypt something. I say the folliwing: The UNIX filter can certainly be written, but it should use the "services" of the PGP library code, which might have functions specifically for use with UNIX, But may not be called by Mac API's. It's important for me to point out that these PGP routines as C functions should be implemented as "Agents" or "Engines" and be totally self contained and not be depending on UNIX, MacOS or other facilities. It is fair for UNIX programs to CALL them, but the PGP should not depend on UNIX, or Machine dependent facilities other than File IO. Paul Rubin writes: >Those of us who support the freedom to use cryptography, run PGP, and >write whatever programs we wish (cryptographic and otherwise) should >be aware that the boycott against Lotus and Apple is still on. By >making PGP run on Macintoshes and with Lotus Notes, we improve the >usefulness of those systems and thereby help our enemies take away our >rights. I say --- Great!! but I have invested a lot of my own finances into purchasing my Mac II (Probably long before the boycott), and I certainly want to put it to good use. This includes my rights to privacy and to use PGP. I don't like Apple's policy, and think it sucks, especially if they dump hundreds of Mac programmers on the job marketplace, but sure don't want to ditch my Mac just because a few Apple FAT CATS made bad decisions. David Clunie writes: >2. A preliminary perusal of the code makes it obvious that extracting the > functionality from the interface is not an easy task. I agree, this isn't going to be easy, SW development is NEVER easy, so who is afraid of a little work? With all those unemployed programmers out there, we should be able to get PLENTY of help! JD From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: miron@extropia.wimsey.com (Miron Cuperman) Date: Thu, 19 Nov 92 21:09:14 PST To: cypherpunks@toad.com Subject: Re: Some proposals to consider In-Reply-To: <9211200059.AA27380@netcom2.netcom.com> Message-ID: <1992Nov20.045112.2129@extropia.wimsey.bc.ca> MIME-Version: 1.0 Content-Type: text/plain crunch@netcom.com (John Draper) writes: >Greetings fellow cypherpunks: > I've been getting good support for my ideas on implementing machine >independent modules or "Libraries" of PGP routines that don't include >I/O portions, but after looking at the code, I see this is going to >take a lot of work, both in organizing the effort, and in implementing >the code. Just how this is going to be done, I'm not sure, but this >is what cypherpunks is all about. To hash these things over, flame on >each other's ideas, etc. It would be very nice if PGP behaved better as a UNIX filter. For example, I'd like it to return an exit code if it fails. I'd also like it to have a flag that disables any access to the tty for prompts. For example, if I have an automatic filter that tries to decrypt all incoming messages, I don't want it to prompt for a secret ring file when it can't decrypt something. A very important addition to PGP would be multi-recipient encryption. RIPEM implements this nicely, by having one private key (PGP has this too - it uses IDEA) and encrypting this key with each recipient's key. We could then run this list encrypted, in order to excercise PGP and to see what user interface issues become important with heavy use. (Not much security is afforded because of the public nature of the list.) -- Miron Cuperman | NeXTmail/mime ok | Public key avail AMIX: MCuperman | immortalcybercomputinglaissezfaire | From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Fri, 20 Nov 92 14:19:20 PST To: cypherpunks@toad.com Subject: "Young Men's Crypto Association," (YMCA) In-Reply-To: <199211200828.AA03551@well.sf.ca.us> Message-ID: <9211201741.AA11668@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain "Young Men's Crypto Association" (YMCA) George Gleason raises some interesting points about teaching ethics and morality to nascent hackers, in the hope of heading off some of the darker aspects of anonymous remailers, digital pseudonyms, and the like: > At risk of sounding naive/idealistic, it would seem that since there is no > way to block information passing through the net (aside from screening at > source, impractical at least!), the solution rests with education of the > net-using population. Power carries responsibility in equal measure. We > are giving ourselves the power which comes with privacy; we can begin to > take responsibility for promoting a sense of ethics in the use of the net. > One possible place to start would be at highschool-level computer courses; > perhaps with accomplished hackers coming in and giving guest lectures or > something... the culture of computer-literate youth can begin to include > strong ethical positions regarding respect for the privacy of others, > respect for truthfulness, and a position of personal conscience regarding > law and authority. Re the latter, this isn't the same thing as blind I doubt this'll work. You're welcome to try, though. We had this same discussion in a nanotech group I attend (Ted Kaehler's "Assembler Multitude," in Palo Alto), where the concern was about the "grey goo" that could result from replicator development. Several folks recommended that the best approach to handling malicious "nanotech hacking" is _education_, just as George is recommending for what might be called "malicious crypto." The problems are: 1. Moral education (= Christian, in the West) has been tried for centuries, with little apparent effect on murders, rapes, war, and pillage. I won't knock religion here, but the teachings don't seem to have much of an effect. 2. There's usually some fringe, which may be 10% or which may be 1%, which does the _opposite_ of the mainstream teachings. For example, let us suppose George successfully organizes the "Young Men's Crypto Association," or YMCA, to go out to high schools and shopping malls to preach the virtues of crypto temperance, of the evils of computer viruses (a parallel to the crypto stuff talked about here, and an even better example of "hacker morality"), etc. This YMCA will perhaps teach some set of values to perhaps 90% or even 99% of the hacker community it preaches to. But what of the rest? A case can be made that such preaching will _energize_ this minority into action, if only to poke a stick into the eye of society. 3. Practically speaking, how can a handful of we crypto enthusiasts even begin to compete with the teachings of other moralists and religious types? We've got other fish to fry. 4. Finally, many of the "crypto anarchy" views I've been espousing for several years now have been seen by some as grossly immoral and dangerous. Should the YMCA (the Young Men's Crypto Association, remember) argue _against_ such ideas? > obedience, but rather the idea that if there is to be disobedience it needs > to be grounded in deeply held personal ethics, as for example in the case of > civil disobedience. A strong set of cultural values in these areas might > set a tone which discourages mindless negativity and wrecking. Now there > will always be those who wreck for thrills.... I don't know how to address > that problem except to note that such individuals are hardly stopped today > by the threat of prosecution. I agree with George that some will always "wreck for thrills." What crypto and privacy techniques do is give us some protection against these vandals. Like locks on doors, or sealed envelopes, these techniques protect us a lot better than moral lectures against thievery or fraud. Having said all this, if George decides to go ahead with his version of the YMCA, maybe I'll even stand outside in the cold and ring a bell. --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Fri, 20 Nov 92 14:18:40 PST To: cypherpunks@toad.com Subject: The Cypherpunks Mail Project Message-ID: <9211201830.AA29311@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain The time is now arrived for a more concerted effort to deploy encryption. It has become clear from the discussions on the list here that the first step should be encrypted e-mail. Unfortunately, mail is not homogeneous; there is no one place to push on the mail system to add encryption. Thus, regardless of the method used for encryption, we will need to add support to every single mail user agent. I now call for this work to begin. We will begin with the first step: a survey of existing mail agents. I volunteer to conduct the survey. I want to collect the following information from _everybody_ on the list: 1. What mail agent(s) do you use to read your everyday mail? 2. What platforms, hardware and software, do you use it on? Reply to hughes@soda.berkeley.edu as soon as you read this message. It only takes a minute to tell me how you read mail. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Fri, 20 Nov 92 14:18:20 PST To: cypherpunks@toad.com Subject: The Cypherpunks Mail Project Message-ID: <9211201843.AA29819@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Step Two in the Mail Project is to gather together the social facts of mail software development: where the source code is and who maintains it. Participation in this step is not required, but a distributed effort to find this information would be greatly appreciated. Therefore, if you know where to find source code for your own (or any other) mail reader, please send it along. Be complete. Include at least the following information: 1. The name of the mail agent. 2. The current version number. 3. A machine name where the code is located, presumably via anonymous ftp. 4. The directory on the machine where it can be found. 5. The author(s) and maintainer(s) of the software. 6. The licensing status of the software: public domain, Gnuware, university property but publicly usable, etc. 7. Any useful political information about convincing whoever to support encryption. If your mail agent is commercial, then send the name of the manufacturer and any other information you can think of. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: avalon@coombs.anu.edu.au (Darren Reed) Date: Thu, 19 Nov 92 19:35:05 PST To: mark@coombs.anu.edu.au (Mark) Subject: Re: How far is to far? In-Reply-To: <9211191342.AA18149@coombs.anu.edu.au> Message-ID: <9211192343.AA27930@coombs.anu.edu.au> MIME-Version: 1.0 Content-Type: text/plain I've fixed the IP bouncer so it doesnt chew so much cpu any more, backgrounds itself and detachs from the tty. In testing last night, it was using less %cpu than the telnet being used to connect to it on the same machine (hope that bodes well! :). Darren ----------------------------------------------------------------------------- /* This file is telserv.c and is part of the Telnet Server package v. 1.0, written by "Hal-9000". Much of this package was developed by Richard Stephens and my thanks go to "Xanadude" for providing me with that section. Performance fix by Darren Reed. To compile, type "cc -O -s telserv.c -o telserv". */ #include #include #include #include #include #include #include #include #define SERV_TCP_PORT 12345 /* port I'll listen for connections on */ #define REM_HOST_ADDR "127.0.0.1" /* host I will bounce to */ #define REM_TCP_PORT 19 /* port I will bounce to */ char sbuf[2048], cbuf[2048]; main() { int sockfd, newsockfd, clilen, childpid, opt = 1; struct sockaddr_in cli_addr, serv_addr; sockfd = socket(AF_INET, SOCK_STREAM, 0); setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)); bzero((char *) &serv_addr, sizeof(serv_addr)); serv_addr.sin_family = AF_INET; serv_addr.sin_addr.s_addr = htonl(INADDR_ANY); serv_addr.sin_port = htons(SERV_TCP_PORT); if (bind(sockfd, (struct sockaddr *) &serv_addr, sizeof(serv_addr)) == -1) { perror("bind"); exit(-1); } listen(sockfd, 5); setpgrp(getpid(), 0); close(0); close(1); close(2); #ifdef TIOCNOTTY if ((newsockfd = open("/dev/tty", O_RDWR)) >= 0) { ioctl(newsockfd, TIOCNOTTY, (char *)0); close(newsockfd); } #endif if (fork()) exit(0); while (1) { clilen = sizeof(cli_addr); newsockfd=accept(sockfd, (struct sockaddr *) &cli_addr, &clilen); if (newsockfd == -1) exit(-1); setsockopt(newsockfd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)); /* ** NB: FNDELAY and O_NDELAY aren't the same on all machines and on most ** we want FNDELAY. The differences are subtle but differences all the ** same. */ #ifdef FNDELAY fcntl(newsockfd,F_SETFL,fcntl(newsockfd,F_GETFL,0)|FNDELAY); #else fcntl(newsockfd,F_SETFL,O_NDELAY); #endif childpid = fork(); if (childpid == 0) { /* child process */ close(sockfd); /* close original socket */ telcli(newsockfd); /* process the request */ exit(0); } close(newsockfd); /* parent process */ wait(0); } } telcli(clisockfd) { int servsockfd; struct sockaddr_in serv_addr; bzero((char *) &serv_addr, sizeof(serv_addr)); serv_addr.sin_family = AF_INET; serv_addr.sin_addr.s_addr = inet_addr(REM_HOST_ADDR); serv_addr.sin_port = htons(REM_TCP_PORT); servsockfd = socket(AF_INET, SOCK_STREAM, 0); connect(servsockfd, (struct sockaddr *) &serv_addr, sizeof(serv_addr)); #ifdef FNDELAY fcntl(servsockfd,F_SETFL,fcntl(clisockfd,F_GETFL,0)|FNDELAY); #else fcntl(servsockfd,F_SETFL,O_NDELAY); #endif communicate(servsockfd,clisockfd); close(servsockfd); exit(0); } communicate(sfd,cfd) { char *chead, *ctail, *shead, *stail; int num, nfd, spos, cpos; extern int errno; fd_set rd, wr; chead = ctail = cbuf; cpos = 0; shead = stail = sbuf; spos = 0; while (1) { FD_ZERO(&rd); FD_ZERO(&wr); if (spos < sizeof(sbuf)-1) FD_SET(sfd, &rd); if (ctail > chead) FD_SET(sfd, &wr); if (cpos < sizeof(cbuf)-1) FD_SET(cfd, &rd); if (stail > shead) FD_SET(cfd, &wr); nfd = select(256, &rd, &wr, 0, 0); if (nfd <= 0) continue; if (FD_ISSET(sfd, &rd)) { num=read(sfd,stail,sizeof(sbuf)-spos); if ((num==-1) && (errno != EWOULDBLOCK)) return; if (num==0) return; if (num>0) { spos += num; stail += num; if (!--nfd) continue; } } if (FD_ISSET(cfd, &rd)) { num=read(cfd,ctail,sizeof(cbuf)-cpos); if ((num==-1) && (errno != EWOULDBLOCK)) return; if (num==0) return; if (num>0) { cpos += num; ctail += num; if (!--nfd) continue; } } if (FD_ISSET(sfd, &wr)) { num=write(sfd,chead,ctail-chead); if ((num==-1) && (errno != EWOULDBLOCK)) return; if (num>0) { chead += num; if (chead == ctail) { chead = ctail = cbuf; cpos = 0; } if (!--nfd) continue; } } if (FD_ISSET(cfd, &wr)) { num=write(cfd,shead,stail-shead); if ((num==-1) && (errno != EWOULDBLOCK)) return; if (num>0) { shead += num; if (shead == stail) { shead = stail = sbuf; spos = 0; } if (!--nfd) continue; } } } } From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Fri, 20 Nov 92 14:18:02 PST To: cypherpunks@toad.com Subject: The Cypherpunks Mail Project Message-ID: <9211201847.AA29990@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Hey, this means you! Have you sent me the name of the software you use to read e-mail with yet? Even if you've never posted to the list or replied to any of the messages, I expect to hear from you. I not only want to collect a list of names of software, I want to know which ones are in most common use. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: miron@extropia.wimsey.com (Miron Cuperman) Date: Fri, 20 Nov 92 04:11:08 PST To: cypherpunks@toad.com Subject: Re: How far is to far? In-Reply-To: <199211200828.AA03551@well.sf.ca.us> Message-ID: <1992Nov20.111126.1376@extropia.wimsey.bc.ca> MIME-Version: 1.0 Content-Type: text/plain gg@well.sf.ca.us (George A. Gleason) writes: >Re. Fen's proposal to utilise "broadcatch." We still have the problems of >slander/libel and breaches of legitimate secrecy. >At risk of sounding naive/idealistic, it would seem that since there is no >way to block information passing through the net (aside from screening at >source, impractical at least!), the solution rests with education of the >net-using population. Power carries responsibility in equal measure. We Nah, education is too hard. :) There are two other options: - Have the mix accessible to only a selected group. Provide the group with signed certificates. It is possible to sign certificates such that they are untracable to their owner, exactly like crypto money. A security concern here is that the mix owner can tell when the same user uses the mix more than once (but the owner can't tell which user). - Charge for the mix services with crypto-money. The crypto-money could be some networking service. It could be even mix transmission. For example, the basic currency could be the transmission of 10K through a mix. One would have to create a mix and let the bank route some traffic through it thereby putting credits in your account. Once you have credits, you could spend them anywhere. One might want to fiddle with the definition of the currency so that it does not depreciate with time. I prefer the second option. I think mixes and crypto-money really go hand in hand. -- Miron Cuperman | NeXTmail/mime ok | Public key avail AMIX: MCuperman | immortalcybercomputinglaissezfaire | From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Fri, 20 Nov 92 14:25:24 PST To: hkhenson@cup.portal.com Subject: The legality of PGP In-Reply-To: <9211191023.1.22089@cup.portal.com> Message-ID: <9211201648.AA19486@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: hkhenson@cup.portal.com >Perry writes PGP is based on RSA . . . which has not granted a license >for people to use . . . . using PGP is possibly a pattent violation . . . >I wonder--I have RSA Mailsafe. Do you think that would give me a license >to use RSA if I loaded up PGP? Keith Doubtful -- RSA tends to be licensed on a per application per copy basis, not on a per human basis. If it was licensed on a per-human basis, I would have bought a personal "unlimited use" license long ago. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Marc.Ringuette@GS80.SP.CS.CMU.EDU Date: Fri, 20 Nov 92 14:17:44 PST To: cypherpunks@toad.com Subject: Re: The Dining Cryptographers Protocol Message-ID: <9211201907.AA12713@cygnus.com> MIME-Version: 1.0 Content-Type: text/plain Can DC-nets be used in a hierarchical or "backbone" framework to reduce communications overhead? Bill Stewart (in personal mail) suggested that such a scheme could satisfy my objections to DC-nets, namely that in order to get N-way anonymity, you must exchange N bits of traffic per bit of anonymous message transmitted. But when we tried to come up with such a scheme, it ended up being an unsatisfying hybrid of DC-nets and mixes. If you know of a backbone arrangement for DC-nets with a local net of size L< MIME-Version: 1.0 Content-Type: text/plain I thinat in the case of  n reading back over the debate about mail encryptionthrough the encryption debate,my main thought seems to be,like the someone said earlier, that really the thing to push for is a mass people's movement to encrypyt all mail as a matter of course, with the tools to encrypt/decrypt be ing programs whose source code is freely published and open to scrutiny.Ultimately,if ALL mail, of any kind is routinely encrypted and decrypted using a suitable encryption metheod,privacy will be something we will tajke for granted.This right should be guaranteed via a Constitutional amendment.The decreasing cost of silicon will make this increasingly practical, and the money saved through the curtailment of credit card fraud,etc. (uncrackable digital suignatures would also have a side-benefit in that they would eliminate most credit card fraud.)would make this a win win situation..(except fotr the spooks and the crooks..) -Chris. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hollander Date: Fri, 20 Nov 92 16:37:47 PST To: cypherpunks@toad.com Subject: transport Message-ID: <9211210037.AA08344@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Is there anyone going to tommorow's meeting from bekreley that I could get a ride from? If so please mail me or call me at 510 559 8470. Thanks, Eric Hollander From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: dclunie@pax.tpa.com.AU (David Clunie) Date: Thu, 19 Nov 92 23:01:19 PST To: cypherpunks@toad.com Subject: Re: Some proposals, Anonymous mailers Message-ID: <9211200659.AA00380@britt> MIME-Version: 1.0 Content-Type: text/plain > I've been getting good support for my ideas on implementing machine > independent modules or "Libraries" of PGP routines that don't include > I/O portions, but after looking at the code, I see this is going to > take a lot of work, both in organizing the effort, and in implementing > the code. Just how this is going to be done, I'm not sure, but this > is what cypherpunks is all about. To hash these things over, flame on > each other's ideas, etc. > > I have been studying the PGP code, and can see it's going to take a > lot of work to get it into a form where true machine portability can > be realized. As a Mac purist, a abhore the idea if translating Mac > GUI actions into ascii text and sending it to the current PGP "engine". > > Although it would take a lot of work, I propose that we develop PGP > to have the following form. > > a) Encryption engine library - Main set of routines currently in the > PGP program dealing with encryption of data. These would be I strongly support this concept. Having just implemented a new anonymous mail and posting system with privacy enhancement using PGP on a Unix machine, using the existing PGP code which is very keyboard oriented, proved to be a real headache, trying to second guess the responses that pgp expected. The whole deal would have been much easier calling library routines, or even more "Unix" like tool type interfaces. I am seriously considering rewriting some bits of PGP to do what I need but unfortunately: 1. I don't know anything about encryption, as Phil has made obvious in his responses to my ideas (quite rightly so). 2. A preliminary perusal of the code makes it obvious that extracting the functionality from the interface is not an easy task. However, I would be happy to volunteer my services should no one Unix based with more PGP or encryption experience is available. I also live outside the US at present which is a plus I guess as far as RSA is concerned. BTW. Re. my anonymous service - once I have Phil and Hal's suggestions implemented feel free to use it. Send mail to "anon.info@pax.tpa.com.au". The service is not yet really on-line, but if anyone wants to play with it feel free (given the proviso that I might change things and take it up and down periodically until I get it right; I will try to preserve alias #'s and stored public keys that have already been sent along). It is not based on the current perl scripts - I hacked it up in Bourne shell scripts before I heard about other peoples efforts, so all bugs are mine ! Note that it is basically a typical anonymous mailing system like that used in the various alt.personals and alt.sex groups, except that you can encrypt your messages to it, and it will encrypt responses back to you automatically, so dubious bounced mail and replies will not be readable by other's at your site or on the path. At present it is set up to allow posting to any group, but I am seriously considering blocking out the k12 groups after the recent godiva fiasco, quite against my philosophy, but my better judgement may yet prevail :( The same may go for file size and even rapidly repeated messages to the same addresses to prevent common patterns of "anonymous abuse". I hate to do this and may not, but I get the impression that I would be foolish not to. The immaturity of some people out there amazes me. BTW. I have also started a new mailing list for discussion of anonymous groups in general as well as my system. Send mail to "anon.subscribe@ pax.tpa.com.au" if you want to join. The list is strictly plaintext at the moment though unfortunately ! david From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Brad Huntting Date: Fri, 20 Nov 92 17:10:16 PST To: hughes@soda.berkeley.edu Subject: Re: The Cypherpunks Mail Project In-Reply-To: <9211201847.AA29990@soda.berkeley.edu> Message-ID: <199211210109.AA00635@misc.glarp.com> MIME-Version: 1.0 Content-Type: text/plain > Hey, this means you! Have you sent me the name of the software you > use to read e-mail with yet? > Even if you've never posted to the list or replied to any of the > messages, I expect to hear from you. > I not only want to collect a list of names of software, I want to know > which ones are in most common use. I use mime-mh... A variant of mh which supports MIME. Incorporating pgp with MIME, and then cleaning up pgp a little so it can deal with stdin/stdout would probably serve me just fine... brad From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: phr@napa.Telebit.COM (Paul Rubin) Date: Fri, 20 Nov 92 18:47:12 PST To: whitaker@eternity.demon.co.uk Subject: The Cypherpunks Mail Project In-Reply-To: <4475@eternity.demon.co.uk> Message-ID: <9211210246.AA17433@napa.TELEBIT.COM> MIME-Version: 1.0 Content-Type: text/plain > Hey, this means you! Have you sent me the name of the software you > use to read e-mail with yet? > > Eric > PCElm 3.01. Everyone, please send the name of your email software to Eric, so he can do useful and wonderful things with the information. But please *don't* clutter the rest of the list with it. Thanks. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Bill O'Hanlon Date: Fri, 20 Nov 92 20:46:59 PST To: hughes@soda.berkeley.edu Subject: Re: The Cypherpunks Mail Project In-Reply-To: <9211201847.AA29990@soda.berkeley.edu> Message-ID: MIME-Version: 1.0 Content-Type: text/plain I use elm and mh-6.7. I just started using mh and am still learning my way around it. The platforms I use are Sun Sparcstations, at work, and 386-based PCs running Interactive, DOS, and 386BSD at home. Good luck with the survey, Bill From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: ghoast@gnu.ai.mit.edu Date: Fri, 20 Nov 92 19:21:02 PST To: th@gnu.ai.mit.edu Subject: NSA readings Message-ID: <9211210320.AA49284@hal.gnu.ai.mit.edu> MIME-Version: 1.0 Content-Type: text/plain If one is looking to find out as much as possible on the NSA (it s past doings as well as known present doings), what should one read, aside from the aforementioned "Puzzle Palace"? Are there any other accurate books or articles available? From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Fri, 20 Nov 92 23:28:18 PST To: cypherpunks@toad.com Subject: re: The Cypherpunks Mail Project Message-ID: <3844.2B0DE187@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain U> From: hughes@soda.berkeley.edu (Eric Hughes) U> Have you sent me the name of the U> software you use to read e-mail with yet? Program: ReadMail. MSDOS, FidoNet *.MSG message base compatible. --- ReadMail * Origin: tomj@fidosw.fidonet.org / World Power Systems (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET - Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Fen Labalme Date: Sat, 21 Nov 92 00:35:00 PST To: cypherpunks@toad.com Subject: The Cypherpunks Mail Project Message-ID: <199211210833.AA19473@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Eric Hughes writes: >It has become clear from the discussions on the list here that the >first step should be encrypted e-mail. Unfortunately, mail is not >homogeneous; there is no one place to push on the mail system to add >encryption. I may disagree with this (I say, "I may" as there are many sides to this compicated issue, but the side I currently agree with I will state here) and I hesitate to bring this up as I don't want to slow down the (imo) much-needed development of encrypted mailers. But I think that an approach may exist that has better long-term consequences than the one that advocates shoe-horning PGP into every mailer. There is an attempt to to create a new mail standard on top (or next to) the current so-called RFC-822 mail standard that will allow multi-part typed messages. This proposed standard, known as MIME (for Multipurpose Internet Mail Extensions) is nearly complete and will allow rich text, binary and other formats to be included in a single internet mail message. There has been a disagreement between the PEM (Privacy Enhanced Mail) and MIME communities as to which should be integrated into the other; simply put, the PEM folk feel that you simply encrypt an entire MIME message, and the MIME folk think that PEM messages are just another one of the many types of content parts that a MIME message can contain. I tend to agree with the latter camp, as it appears to be more flexible. For example, what happens if I wish to start communications with someone using a different standard than PGP (gasp - they may be using RSA's mailsafe), or even a newer, perhaps incompatible version of PGP? Or maybe I want to send them a message partly encrypted and partly in the clear? MIME is designed to handle these scenarios (and more). I must admit that this thought coalesced in my head due to the confluence of two different streams of communications both heading towards this solution at the same time: 1) I asked Steve Dorner (author of the excellent Eudora Macintosh email reader) if he was considering adding encryption to his mailer (specifically PGP) and he replied no, but that he was integrating MIME into it; 2) The pem-dev email list, which has been discussing threads on PGP and MIME, recently carried an interesting proposal on MIME-PEM integration (though I expect to see the other camp come out with their PEM-MIME integration plan soon!). I think this latter document is excellent reading, and I will forward it in a followup message to this one. By the way, it has a short set of six references that I consider required reading for anyone interested in doing serious work on Internet mailers. In case all this is new to you, I've included at the bottom a blurb from the RFC-index explaining how to find these RFCs and more. My $0.02. Fen ~~~ Many RFCs are available online; if not, this is indicated by (Not online). Online copies are available via FTP or Kermit from NIC.DDN.MIL as rfc/rfc####.txt or rfc/rfc####.PS (#### is the RFC number without leading zeroes). Additionally, RFCs may be requested through electronic mail from the automated NIC mail server by sending a message to SERVICE@NIC.DDN.MIL with a subject line of "rfc ####" for text versions or a subject line of "rfc ####.PS" for PostScript versions. To obtain the RFC index, the subject line of your message should read "rfc index". From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: wmo@rebma.rebma.mn.org (Bill O'Hanlon) Date: Fri, 20 Nov 92 23:24:21 PST To: cypherpunks@toad.com Subject: Apology Message-ID: MIME-Version: 1.0 Content-Type: text/plain Oops. Sorry about sending my response to Eric's survey to the entire list. Honestly, I know better, but I think that was the first time that I've used mh's repl, and I didn't check the cc. Oops. Anyway, I've had a couple queries on Eric's remailer. Hal Finney, just so you know, I've not heard responses from you to a couple letters, and neither has at least one other person. We're interested in your code for the Encrypted: part of the remailer. -- Bill O'Hanlon wmo@rebma.mn.org From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Fen Labalme Date: Sat, 21 Nov 92 00:42:36 PST To: cypherpunks@toad.com Subject: The Cypherpunks Mail Project Message-ID: <199211210841.AA20896@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain To: pem-dev@TIS.COM, ietf-822@dimacs.rutgers.edu Subject: MIME-PEM Interaction Reply-To: ietf-822@dimacs.rutgers.edu Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Date: Mon, 16 Nov 1992 16:41:22 -0800 From: Marshall Rose Sender: pem-dev-relay@TIS.COM ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Friends, at the request of the participants at the SAAG meeting this afternoon, I am posting a draft regarding the interaction of MIME and PEM. I believe that this draft will be presented by Ned Freed at the PEM meeting on Wednesday (which, regrettably, I will be unable to attend due to a conflict.) Although Steve, Ned and I think that the draft is fairly complete, there are likely some issues which remain to be resolved or at least given greater exposition. As such, your comments are most certainly welcome! /mtr ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-Description: mime-pem.txt draft MIME-PEM Interaction Nov 92 MIME-PEM Interaction Mon Nov 16 15:51:54 1992 Steve Crocker Trusted Information Systems crocker@tis.com Ned Freed Innosoft International, Inc. ned@innosoft.com Marshall T. Rose Dover Beach Consulting, Inc. mrose@dbc.mtview.ca.us 1. Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as a "work in progress". 2. Abstract This memo defines a framework for interaction between MIME and PEM services. Expires May 16, 1993 [Page 1] draft MIME-PEM Interaction Nov 92 3. Introduction In the Internet community, an electronic mail message has two parts: the headers and the body. The headers form a collection of field/value pairs structured according to RFC 822 [1], whilst the body, if structured, is defined according to Multipurpose Internet Mail Extensions (MIME) [2]. Privacy Enhanced Mail (PEM) [3-6] allows encryption and authentication services to be applied to an electronic mail message. This memo defines a framework whereby the services provided by MIME and PEM are used in a complementary fashion. In order to provide for MIME-PEM interaction, two content types, "multipart/pem" and "application/pem", are defined. Then, the relationship between MIME and PEM is described in terms of two functions: message composition and message delivery. Expires May 16, 1993 [Page 2] draft MIME-PEM Interaction Nov 92 4. Definiton of new Content Types 4.1. Definition of the multipart/pem Content Type (1) MIME type name: multipart (2) MIME subtype name: pem (3) Required parameters: boundary, privacy (4) Optional parameters: none (5) Encoding considerations: always 7bit (6) Security Considerations: see [3] This subtype of multipart always contains two body parts: the first is an arbitrary content; and, the second is an application/pem content which describes the privacy- enhancements which resulted in the first body part. The value of the first body part corresponds to as defined in [3]. Note that if is represented using the base64 encoding, then a a Content-Transfer-Encoding: header is present which indicates use of the base64 content encoding. Otherwise, if a Content-Transfer-Encoding: header is present, it indicates use of the 7bit content encoding. The syntax and semantics of the boundary parameter is defined in [2]. The syntax of the privacy parameter, using the ABNF notation of [1], is: privacy-value ::= "ENCRYPTED" / "MIC-ONLY" / "MIC-CLEAR" with each value conveying the intent as specified in [3]. Expires May 16, 1993 [Page 3] draft MIME-PEM Interaction Nov 92 4.2. Definition of the application/pem Content Type (1) MIME type name: application (2) MIME subtype name: pem (3) Required parameters: none (4) Optional parameters: none (5) Encoding considerations: always 7bit (6) Security Considerations: see [3] The syntax of this content type corresponds to the production defined in [3]. Expires May 16, 1993 [Page 4] draft MIME-PEM Interaction Nov 92 5. Message Composition When a user composes a message, it is the responsibility of the user agent to use the Content-Type: header. This allows the receiving user agent to unambiguously interpret the body and process it accordingly. This memo introduces a new header field, "Content-Privacy", which is used to indicate that the message should undergo privacy-enhancement prior to submission. The syntax of this header field corresponds to the production defined above. 5.1. Pre-Submission Algorithm Prior to submission, the user agent applies this algorithm: (1) If the content does not contain the Content-Privacy: header, then the user agent sees if the content is either multipart or message. If so, it then recursively applies this algorithm to the encapsulated body parts; if not, it terminates processing for this content. (2) If the content does contain the Content-Privacy: header, the content is transformed from local form to its canonical form. Note that if a Content-Transfer- Encoding: header is present, then the content encoding is reversed as a part of this process. (3) If the canonical form of the content uses octet values outside of the NVT ASCII repertoire, and if the value of the Content-Privacy: header is MIC-CLEAR, then this inconsistency is reported to the user and the algorithm aborts. (4) Otherwise, the privacy-enhancement indicated by the Content-Privacy: header is performed, constructing a new content. The Content- headers, other than Content- Transfer-Encoding: and Content-Privacy:, are taken from the original content, if any. (5) If the value of the Content-Privacy: header is not MIC- CLEAR, then the base64 content encoding is applied and a Content-Transfer-Encoding: header is added to the new Expires May 16, 1993 [Page 5] draft MIME-PEM Interaction Nov 92 content. (6) Finally, a multipart/pem content is constructed, whcih contains the new content and a corresponding application/pem content. The multipart/pem content replaces the original content. Expires May 16, 1993 [Page 6] draft MIME-PEM Interaction Nov 92 6. Message Delivery When a user receives a message containing an multipart/pem content, the user agent may transform the content back into its original content type. This operation, the post-delivery algorithm, is performed by reversing the steps performed during the pre-submission algorithm. When the original content is reconstituted into canonical form, it may use octet values outside of the NVT ASCII repertoire. If the user agent replaces the multipart/pem content with the original content, then it must select an appropriate transfer encoding and include the appropriate Content-Transfer-Encoding: header. Upon successful completion of the post-delivery algorithm for each content, the user agent adds a new header field, "Content-Annotation", which is used to indicate the privacy- enhancements that were in effect when the content was submitted. The syntax of this header field, using the ABNF notation of [1], is: content-annotation ::= "Content-Annotation" ":" annotation-value annotation-value ::= ";" with corresponding to the privacy-enhancements that was in effect during submission, and , defined in [1], indicates the date and time that the privacy- enhancements were verified by the receiving user agent. NOTE It must be strongly emphasized that the user's level of trust in the value of the Content-Annotation: header should be no higher than the user's level of trust in the message store employed by the user agent. Expires May 16, 1993 [Page 7] draft MIME-PEM Interaction Nov 92 7. An Example For example, suppose the following message was being readied for submission: Date: Thu, 12 Nov 1992 21:43:40 -0800 From: scrocker@tis.com To: ned@innosoft.com Subject: example #1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Privacy: mic-clear Hi Ned. See how much nicer this works! After applying pre-submission algorithm, the message submitted for delivery would appear as: Date: Thu, 12 Nov 1992 21:43:40 -0800 From: scrocker@tis.com To: ned@innosoft.com Subject: example #1 MIME-Version: 1.0 Content-Type: multipart/pem; boundary="next-part"; privacy=mic-clear Content-Type: text/plain; charset=us-ascii Hi Ned. See how much nicer this works! --next-part Content-Type: application/pem Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-ID-Asymmetric: ... MIC-Info: RSA-MD5,RSA, ... --next-part-- Expires May 16, 1993 [Page 8] draft MIME-PEM Interaction Nov 92 After applying the post-delivery algorithm, the resulting message would appear as: Date: Thu, 12 Nov 1992 21:43:40 -0800 From: scrocker@tis.com To: ned@innosoft.com Subject: example #1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Annotation: mic-clear; Thu, 12 Nov 1992 22:13:40 -0800 (integrity verified) Hi Ned. See how much nicer this works! Of course, as the message being submitted was only plain text, the Content-Type: header could be ommitted. In that case, after applying the pre-submission algorithm, the message submitted for delivery would appear as: Date: Thu, 12 Nov 1992 21:43:40 -0800 From: scrocker@tis.com To: ned@innosoft.com Subject: example #1 MIME-Version: 1.0 Content-Type: multipart/pem; boundary="next-part"; privacy=mic-clear Hi Ned. See how much nicer this works! --next-part Content-Type: application/pem Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-ID-Asymmetric: ... MIC-Info: RSA-MD5,RSA, ... --next-part-- Expires May 16, 1993 [Page 9] draft MIME-PEM Interaction Nov 92 8. Observations The use of the pre-submission and post-delivery algorithms exhibit several properties: (1) It allows privacy-enhancement of an arbitrary content, not just an RFC 822 message. (2) For a multipart or message content, it allows the user to decide whether the structure of the content should receive privacy-enhancement. (3) It allows a message to contain several privacy enhanced contents, thereby removing the requirement for PEM software to be able to generate or interpret a single content which intermixes both unenhanced and enhanced components. (4) It minimizes confusion when viewing a MIC-CLEAR content without a PEM-capable user agent. (5) It minimizes confusing when viewing a MIC-ONLY content with a MIME-capable user agent that is not PEM-capable. 9. Acknowledgements David H. Crocker suggested the use of a multipart structure for MIME-PEM interaction. Expires May 16, 1993 [Page 10] draft MIME-PEM Interaction Nov 92 10. References [1] D.H. Crocker. Standard for the Format of ARPA Internet Text Messages. Request for Comments 822, (August, 1982). [2] N. Borenstein, N. Freed, Multipurpose Internet Mail Extensions. Request for Comments 1341, (June, 1992). [3] J. Linn, Privacy Enhancement for Internet Electronic Mail -- Part I: Message Encryption and Authentication Procedures. Internet-Draft, (July 23, 1992). [4] S. Kent, Privacy Enhancement for Internet Electronic Mail -- Part II: Certificate-Based Key Management. Internet-Draft, (August 6, 1992). [5] D. Balenson, Privacy Enhancement for Internet Electronic Mail -- Part III: Algorithms, Modes, and Identifiers. Internet-Draft, (September 3, 1992). [6] B. Kaliski, Privacy Enhancement for Internet Electronic Mail -- Part IV: Key Certification and Related Services Internet-Draft, (September 1, 1992). Expires May 16, 1993 [Page 11] draft MIME-PEM Interaction Nov 92 Table of Contents 1 Status of this Memo ................................... 1 2 Abstract .............................................. 1 3 Introduction .......................................... 2 4 Definiton of new Content Types ........................ 3 4.1 Definition of the multipart/pem Content Type ........ 3 4.2 Definition of the application/pem Content Type ...... 4 5 Message Composition ................................... 5 5.1 Pre-Submission Algorithm ............................ 5 6 Message Delivery ...................................... 7 7 An Example ............................................ 8 8 Observations .......................................... 10 9 Acknowledgements ...................................... 10 10 References ........................................... 11 Expires May 16, 1993 [Page 12] ------- =_aaaaaaaaaa0-- [ sorry for the double spacing - my mailer's acting up and I'm too tired to fight with it anymore. What we need MORE than encrypted mailers is mailers that do the standard stuff right... The one on the WELL sux!] From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: whitaker@eternity.demon.co.uk (Russell E. Whitaker) Date: Fri, 20 Nov 92 18:17:57 PST To: cypherpunks@toad.com Subject: Re: The Cypherpunks Mail Project Message-ID: <4475@eternity.demon.co.uk> MIME-Version: 1.0 Content-Type: text/plain > Hey, this means you! Have you sent me the name of the software you > use to read e-mail with yet? > > Eric > PCElm 3.01. Russell Earl Whitaker whitaker@eternity.demon.co.uk Communications Editor 71750.2413@compuserve.com EXTROPY: The Journal of Transhumanist Thought AMiX: RWHITAKER Board member, Extropy Institute (ExI) ================ PGP 2.0 public key available ======================= From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Sat, 21 Nov 92 02:24:11 PST To: miron@extropia.wimsey.com Subject: Re: How far is to far? Message-ID: <199211211022.AA06269@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Miron writes, "Charge for the mix services with crypto money. The crypto money could be some networking service..." Only problem is, once we start anything like a formal barter system, it comes under the IRS. The way to avoid that is to keep it a volunteer organisation with an expectation of time commitment to projects or to payment of membership dues. Not-for-profit organisations are of course regulated in a minimal way (think of your local Model Railroad Club), but the accounting isn't as strict and the membership transactions don't have to be reported in detail. -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Sat, 21 Nov 92 02:40:14 PST To: tcmay@netcom.com Subject: Re: "Young Men's Crypto Association," (YMCA) Message-ID: <199211211039.AA08783@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Tim, you raise a good point about those who'll wreck for the fun of it, and more so in reaction to any perceived ethical mainstream position. Re crypto-anarchy, at heart I'm in favor; in practice I'm in favor; and I see no contradiction in promoting an internalised sense of ethics in these areas. The underlying deep problem is we live in a society which is addicted to the emotions that go along with violent acts. Ultimately that problem needs to be addressed, and it's beyond the scope of this group to do that, except as each of us can do things in other contexst of our civic lives. The difficulty of promoting an ethic of conscience is real; but so is the difficulty of arriving at a solution to a technical problem; and difficulty by itself does not stop anyone. It is erroneous to think that technical problems are easier to solve than social ones; any of us can name ten or more areas in which technical problems have proven incredibly complex. In most of these examples, the complex problems arise when dealing with networked systems or systems involving relationships among many elements which can vary in ways that can't be controlled. You can see a straightforward parallel to social problems here: the more variable elements, the more complexity of solution. But let's not let that stop us. -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Ittai Hershman Date: Sat, 21 Nov 92 08:52:59 PST To: cypherpunks@toad.com Subject: Re: The Cypherpunks Mail Project In-Reply-To: <199211210833.AA19473@well.sf.ca.us.ans-relay> Message-ID: <199211211650.AA02274@shemesh.ans.net> MIME-Version: 1.0 Content-Type: text/plain I am in full agreement with Fen's comments regarding MIME. Let me add a short bit of history here. MIME came about because of an effort within the IETF (Internet Engineering Task Force) to extend Internet mail standards to support 8-bit extended character sets and (gasp) to potentially even support the sending of arbitrary binary data. A working group was formed and it took several months and literally thousands of messages before some form of consensus was reached on the technical issues (note -- not the solution, just the issues!). To make a long story short, it quickly became obvious that there was no agreed upon solution which would both provide the functionality the various camps wanted, and backwards compatability for the million or so hosts currently on the Internet. The MIME effort was a creative stroke of genius which allowed us to get out of this fix. Simply put, it allows for a) arbitrary data types to be encoded into 7-bit ASCII and transported using standard RFC-821 SMTP, and b) the structuring of chunks of different data type "parts" into a single e-mail message such that MIME-aware mail-agents/readers can intelligently display multi-media mail intelligently. In other words, the problem was moved from the protocol space to the applications space. Why is this relevant? Well, in order for MIME to be useful, the mail readers that people use have to be modified to support MIME. Fortunately, Nathaniel Borenstein of Bellcore has assembled a kit to make this much easier, and in fact provides patches for many mailers. Now, the authors of all the freebie mail readers we use are being asked to incorporate these changes into their mailers. Do we really want to give them an additional burden -- or do we want to leverage off work that is already being done? -Ittai PS: For those who are interested, these are the relevant RFC's: 1344 Implications of MIME for Internet mail gateways. Borenstein, N. 1992 June; 8 p. (Format: TXT=25872, PS=51812 bytes) 1343 User agent configuration mechanism for multimedia mail format information. Borenstein, N. 1992 June; 10 p. (Format: TXT=29295, PS=59978 bytes) 1342 Representation of non-ASCII text in Internet message headers. Moore, K. 1992 June; 7 p. (Format: TXT=15845 bytes) 1341 MIME (Multipurpose Internet Mail Extensions): Mechanisms for specifying and describing the format of Internet message bodies. Borenstein, N.; Freed, N. 1992 June; 69 p. (Format: TXT=211117, PS=347082 bytes) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: donb@netcom.com (Don Bellenger) Date: Sat, 21 Nov 92 21:16:52 PST To: cypherpunks@toad.com Subject: SUBSCRIBE Message-ID: <9211220512.AA07634@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain SUBSCRIBE Please add me to your mailing list at this address. Thanks, Don Bellenger donb@netcom.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: edgar@spectrx.Saigon.COM (Edgar W. Swank) Date: Sun, 22 Nov 92 05:02:03 PST To: Cypherpunks Subject: Problems with remailer Message-ID: MIME-Version: 1.0 Content-Type: text/plain Distribution: Hal <74076.1041@compuserve.com> Cypherpunks Hal: I tried to test your remailer, but didn't have any luck. I can see that other people (Cassandra & Pollyanna among others) are using it. This small (and free) system does not allow me to specify network headers (except Subject), so I used the "::" convention. I tried three configurations of sending something to myself on Nov 17, 1:08am. As of my last session, Nov 19, 4:45pm, I had not received an echo from any of the three. Here is the record of the mailings. Note the sequence numbers are not part of the message. ---------------------------------------------------------------- To: Remailing Service Subject: Remail Unincrypted 1> :: 2> Request-Remailing-To: edgar@spectrx.saigon.com (Edgar W. Swank) 3> 4> This is an unencrypted test message. 5> /s (Queued for Internet delivery) To: Remailing Service Subject: Remail Encrypted c:\tlxd\spies7.msg :: Request-Remailing-To: edgar@spectrx.saigon.com (Edgar W. Swank) This is an encrypted test message. c:\tlxd\spies7.asc 1> :: 2> Encrypted: PGP 3> 4> -----BEGIN PGP MESSAGE----- 5> Version: 2.0 6> 7> hEwCG6rHcT8LtDcBAf4ime6fkvJE3hKvET5lNeG7U51cFM5B9bCRuYdgDN8gXGef 8> tXpamyWSXHDRvpb/PeebBdG/Gqxb571l54vqAO5opgAAAIepaWGSNzSfnMSOWV+a 9> VFETSI7H7i2m3ZagT/XbgVqzfVUXkkqBYXKESlcsAiUWnF8tXGwYJ/KYUvHWW/ve 10> qPvlbdYAoe+iMtR7asvPCEz+WxEmdIQqTxUPCT1tiIaaplsk5l7p80dW8NkArCH6 11> BTowA85FQrI7gBUBevSs8hq62JUAs6GH5T8= 12> =XUQk 13> -----END PGP MESSAGE----- 14> 15> /s (Queued for Internet delivery) To: Remailing Service Subject: Remail With Anon Return 1> :: 2> Encrypted: PGP 3> 4> -----BEGIN PGP MESSAGE----- 5> Version: 2.0 6> 7> hEwCG6rHcT8LtDcBAf0SgMh0C4raXWqjXytzsmpt2b8veBXZhUvez+ZI309w1Y8w 8> oiYcPjGHhL6l7ad0IXuXFUgBwxAmHbzexSLVeKvgpgAAAGuiL3psLLLJfKeDGXjD 9> hDK3KWoFGlzyzssiudBe+f5kv/1j4EnzkviyQgxCxFTYUd04Z6az1HWRWU7Fvanq 10> KZarLLBgfe8eqzIa82FyOh6CMFqg2Ou4VkaTbQma8LQk4u+7JRNxKBMmy7TrTQ== 11> =0mFO 12> -----END PGP MESSAGE----- 13> 14> This is a message using anonymous return address. 15> /s (Queued for Internet delivery) ---------------------------------------------------------------- Hope you can tell me where I went wrong, especially since you have the convenience of the remailer secret key. In one post, you said: You could post anonymously, using our current remailers, to this list or another list. This implies you now have more than one remailer. Where is (are) the other one(s)? I've since lost track of the details, but I recall reading about a gateway from E-Mail to any Usenet newsgroup. Of course, with your remailer, it's now possible to use that to anonymously post to any usenet newsgroup. Since I'm writing to you anyway, I'd be interested in knowing what (if any) records are kept by the remailer, and for how long are they retained. Where the forwarding address is encrypted, is the decryption of same erased both in memory & on disk (overlay erased on disk) as soon as the message is sent? Memory buffers of incoming net headers (which aren't encrypted) and messages (which may not be encrypted) also need to be erased promptly & not left lying around until reused. Is it possible the remailer held up forwarding my messages waiting for other messages to arrive with different destinations (to confuse traffic analysis)? To avoid long waits, you might want to send out dummy messages to a variety of addresses when traffic is low. I hereby volunteer my address to receive up to ten such messages per day. Once there are enough remailers so that most messages are being forwarded to another remailer, then all the dummy messages can be sent to the other remailers. -- edgar@spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Sun, 22 Nov 92 11:54:53 PST To: cypherpunks@toad.com Subject: Crypto Glossary Message-ID: <9211221950.AA28744@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Here's the glossary of crypto terms we passed out in printed form at the first Cypherpunks meeting in September 1992. Some compromises had to be made in going from the printed form to the ASCII of this transmission, so I hope you'll bear with me. I'm sending it to the entire list because nearly everyone who hears about it says "Is it online?" and wants a copy. If you don't want it, discard it. I'm not going to be maintaining the "Cypherpunks FAQ," so don't send me corrections or additions. Enjoy! --Tim May CRYPTO GLOSSARY Compiled by Tim May (tcmay@netcom.com) and Eric Hughes (hughes@soda.berkeley.edu), circa September 1992. Major Branches of Cryptology (as we see it) - (these sections will introduce the terms in context, though complete definitions will not be given) *** Encryption - privacy of messages - using ciphers and codes to protect the secrecy of messages - DES is the most common symmetric cipher (same key for encryption and decryption) - RSA is the most common asymmetric cipher (different keys for encryption and decryption) *** Signatures and Authentication - proving who you are - proving you signed a document (and not someone else) *** Untraceable Mail - untraceable sending and receiving of mail and messages - focus: defeating eavesdroppers and traffic analysis - DC protocol (dining cryptographers) *** Cryptographic Voting - focus: ballot box anonymity - credentials for voting - issues of double voting, security, robustness, efficiency *** Digital Cash - focus: privacy in transactions, purchases - unlinkable credentials - blinded notes - "digital coins" may not be possible *** Crypto Anarchy - using the above to evade government, to bypass tax collection, etc. - a technological solution to the problem of too much government *** G L O S S A R Y *** *** agoric systems -- open, free market systems in which voluntary transactions are central. *** Alice and Bob -- cryptographic protocols are often made clearer by considering parties A and B, or Alice and Bob, performing some protocol. Eve the eavesdropper, Paul the prover, and Vic the verifier are other common stand-in names. *** ANDOS -- all or nothing disclosure of secrets. *** anonymous credential -- a credential which asserts some right or privilege or fact without revealing the identity of the holder. This is unlike CA driver's licenses. *** asymmetric cipher -- same as public key cryptosystem. *** authentication -- the process of verifying an identity or credential, to ensure you are who you said you were. *** biometric security -- a type of authentication using fingerprints, retinal scans, palm prints, or other physical/biological signatures of an individual. *** bit commitment -- e.g., tossing a coin and then committing to the value without being able to change the outcome. The blob is a cryptographic primitive for this. *** blinding, blinded signatures -- A signature that the signer does not remember having made. A blind signature is always a cooperative protocol and the receiver of the signature provides the signer with the blinding information. *** blob -- the crypto equivalent of a locked box. A cryptographic primitive for bit commitment, with the properties that a blobs can represent a 0 or a 1, that others cannot tell be looking whether itUs a 0 or a 1, that the creator of the blob can "open" the blob to reveal the contents, and that no blob can be both a 1 and a 0. An example of this is a flipped coin covered by a hand. *** channel -- the path over which messages are transmitted. Channels may be secure or insecure, and may have eavesdroppers (or enemies, or disrupters, etc.) who alter messages, insert and delete messages, etc. Cryptography is the means by which communications over insecure channels are protected. *** chosen plaintext attack -- an attack where the cryptanalyst gets to choose the plaintext to be enciphered, e.g., when possession of an enciphering machine or algorithm is in the possession of the cryptanalyst. *** cipher -- a secret form of writing, using substitution or transposition of characters or symbols. *** ciphertext -- the plaintext after it has been encrypted. *** code -- a restricted cryptosystem where words or letters of a message are replaced by other words chosen from a codebook. Not part of modern cryptology, but still useful. *** coin flipping -- an important crypto primitive, or protocol, in which the equivalent of flipping a fair coin is possible. Implemented with blobs. *** collusion -- wherein several participants cooperate to deduce the identity of a sender or receiver, or to break a cipher. Most cryptosystems are sensitive to some forms of collusion. Much of the work on implementing DC Nets, for example, involves ensuring that colluders cannot isolate message senders and thereby trace origins and destinations of mail. *** computationally secure -- where a cipher cannot be broken with available computer resources, but in theory can be broken with enough computer resources. Contrast with unconditionally secure. *** countermeasure -- something you do to thwart an attacker. *** credential -- facts or assertions about some entity. For example, credit ratings, passports, reputations, tax status, insurance records, etc. Under the current system, these credentials are increasingly being cross-linked. Blind signatures may be used to create anonymous credentials. *** credential clearinghouse -- banks, credit agencies, insurance companies, police departments, etc., that correlate records and decide the status of records. *** cryptanalysis -- methods for attacking and breaking ciphers and related cryptographic systems. Ciphers may be broken, traffic may be analyzed, and passwords may be cracked. Computers are of course essential. *** crypto anarchy -- the economic and political system after the deployment of encryption, untraceable e-mail, digital pseudonyms, cryptographic voting, and digital cash. A pun on "crypto," meaning "hidden," and as when Gore Vidal called William F. Buckley a "crypto fascist." *** cryptography -- another name for cryptology. *** cryptology -- the science and study of writing, sending, receiving, and deciphering secret messages. Includes authentication, digital signatures, the hiding of messages (steganography), cryptanalysis, and several other fields. *** cyberspace -- the electronic domain, the Nets, and computer-generated spaces. Some say it is the "consensual reality" described in "Neuromancer." Others say it is the phone system. Others have work to do. *** DC protocol, or DC-Net -- the dining cryptographers protocol. DC-Nets use multiple participants communicating with the DC protocol. *** DES -- the Data Encryption Standard, proposed in 1977 by the National Bureau of Standards (now NIST), with assistance from the National Security Agency. Based on the "Lucifer" cipher developed by Horst Feistel at IBM, DES is a secret key cryptosystem that cycles 64-bit blocks of data through multiple permutations with a 56-bit key controlling the routing. "Diffusion" and "confusion" are combined to form a cipher that has not yet been cryptanalyzed (see "DES, Security of"). DES is in use for interbank transfers, as a cipher inside of several RSA-based systems, and is available for PCs. *** DES, Security of -- many have speculated that the NSA placed a trapdoor (or back door) in DES to allow it to read DES-encrypted messages. This has not been proved. It is known that the original Lucifer algorithm used a 128-bit key and that this key length was shortened to 64 bits (56 bits plus 8 parity bits), thus making exhaustive search much easier (so far as is known, brute-force search has not been done, though it should be feasible today). Shamir and Bihan have used a technique called "differential cryptanalysis" to reduce the exhaustive search needed for chosen plaintext attacks (but with no import for ordinary DES). *** differential cryptanalysis -- the Shamir-Biham technique for cryptanalyzing DES. With a chosen plaintext attack, they've reduced the number of DES keys that must be tried from about 2^56 to about 2^47 or less. Note, however, that rarely can an attacker mount a chosen plaintext attack on DES systems. *** digital cash, digital money -- Protocols for transferring value, monetary or otherwise, electronically. Digital cash usually refers to systems that are anonymous. Digital money systems can be used to implement any quantity that is conserved, such as points, mass, dollars, etc. There are many variations of digital money systems, ranging from VISA numbers to blinded signed digital coins. A topic too large for a single glossary entry. *** digital pseudonym -- basically, a "crypto identity." A way for individuals to set up accounts with various organizations without revealing more information than they wish. Users may have several digital pseudonyms, some used only once, some used over the course of many years. Ideally, the pseudonyms can be linked only at the will of the holder. In the simplest form, a public key can serve as a digital pseudonym and need not be linked to a physical identity. *** digital signature -- Analogous to a written signature on a document. A modification to a message that only the signer can make but that everyone can recognize. Can be used legally to contract at a distance. *** digital timestamping -- one function of a digital notary public, in which some message (a song, screenplay, lab notebook, contract, etc.) is stamped with a time that cannot (easily) be forged. *** dining cryptographers protocol (aka DC protocol, DC nets) -- the untraceable message sending system invented by David Chaum. Named after the "dining philosophers" problem in computer science, participants form circuits and pass messages in such a way that the origin cannot be deduced, barring collusion. At the simplest level, two participants share a key between them. One of them sends some actual message by bitwise exclusive-ORing the message with the key, while the other one just sends the key itself. The actual message from this pair of participants is obtained by XORing the two outputs. However, since nobody but the pair knows the original key, the actual message cannot be traced to either one of the participants. *** discrete logarithm problem -- given integers a, n, and x, find some integer m such that a^m mod n = x, if m exists. Modular exponentiation, the a^m mod n part, is straightforward (and special purpose chips are available), but the inverse problem is believed to be very hard, in general. Thus it is conjectured that modular exponentiation is a one- way function. *** DSS, Digital Signature Standard -- the latest NIST (National Institute of Standards and Technology, successor to NBS) standard for digital signatures. Based on the El Gamal cipher, some consider it weak and poor substitute for RSA- based signature schemes. *** eavesdropping, or passive wiretapping -- intercepting messages without detection. Radio waves may be intercepted, phone lines may be tapped, and computers may have RF emissions detected. Even fiber optic lines can be tapped. *** factoring -- Some large numbers are difficult to factor. It is conjectured that there are no feasible--i.e."easy," less than exponential in size of number-- factoring methods. It is also an open problem whether RSA may be broken more easily than by factoring the modulus (e.g., the public key might reveal information which simplifies the problem). Interestingly, though factoring is believed to be "hard", it is not known to be in the class of NP-hard problems. Professor Janek invented a factoring device, but he is believed to be fictional. *** information-theoretic security -- "unbreakable" security, in which no amount of cryptanalysis can break a cipher or system. One time pads are an example (providing the pads are not lost nor stolen nor used more than once, of course). Same as unconditionally secure. *** key -- a piece of information needed to encipher or decipher a message. Keys may be stolen, bought, lost, etc., just as with physical keys. *** key exchange, or key distribution -- the process of sharing a key with some other party, in the case of symmetric ciphers, or of distributing a public key in an asymmetric cipher. A major issue is that the keys be exchanged reliably and without compromise. Diffie and Hellman devised one such scheme, based on the discrete logarithm problem. *** known-plaintext attack -- a cryptanalysis of a cipher where plaintext-ciphertext pairs are known. This attack searches for an unknown key. Contrast with the chosen plaintext attack, where the cryptanalyst can also choose the plaintext to be enciphered. *** mail, untraceable -- a system for sending and receiving mail without traceability or observability. Receiving mail anonymously can be done with broadcast of the mail in encrypted form. Only the intended recipient (whose identity, or true name, may be unknown to the sender) may able to decipher the message. Sending mail anonymously apparently requires mixes or use of the dining cryptographers (DC) protocol. *** minimum disclosure proofs -- another name for zero knowledge proofs, favored by Chaum. *** mixes -- David Chaum's term for a box which performs the function of mixing, or decorrelating, incoming and outgoing electronic mail messages. The box also strips off the outer envelope (i.e., decrypts with its private key) and remails the message to the address on the inner envelope. Tamper-resistant modules may be used to prevent cheating and forced disclosure of the mapping between incoming and outgoing mail. A sequence of many remailings effectively makes tracing sending and receiving impossible. Contrast this with the software version, the DC protocol. *** modular exponentiation -- raising an integer to the power of another integer, modulo some integer. For integers a, n, and m, a^m mod n. For example, 5^3 mod 100 = 25. Modular exponentiation can be done fairly quickly with a sequence of bit shifts and adds, and special purpose chips have been designed. See also discrete logarithm. *** National Security Agency (NSA) -- the largest intelligence agency, responsible for making and breaking ciphers, for intercepting communications, and for ensuring the security of U.S. computers. Headquartered in Fort Meade, Maryland, with many listening posts around the world. The NSA funds cryptographic research and advises other agencies about cryptographic matters. The NSA once obviously had the world's leading cryptologists, but this may no longer be the case. *** negative credential -- a credential that you possess that you don't want any one else to know, for example, a bankruptcy filing. A formal version of a negative reputation. *** NP-complete -- a large class of difficult problems. "NP" stands for nondeterministic polynomial time, a class of problems thought in general not to have feasible algorithms for their solution. A problem is "complete" if any other NP problem may be reduced to that problem. Many important combinatorial and algebraic problems are NP-complete: the traveling salesman problem, the Hamiltonian cycle problem, the word problem, and on and on. *** oblivious transfer -- a cryptographic primitive that involves the probabilistic transmission of bits. The sender does not know if the bits were received. *** one-time pad -- a string of randomly-selected bits or symbols which is combined with a plaintext message to produce the ciphertext. This combination may be shifting letters some amount, bitwise exclusive-ORed, etc.). The recipient, who also has a copy of the one time pad, can easily recover the plaintext. Provided the pad is only used once and then destroyed, and is not available to an eavesdropper, the system is perfectly secure, i.e., it is information- theoretically secure. Key distribution (the pad) is obviously a practical concern, but consider CD-ROM's. *** one-way function -- a function which is easy to compute in one direction but hard to find any inverse for, e.g. modular exponentiation, where the inverse problem is known as the discrete logarithm problem. Compare the special case of trap door one-way functions. An example of a one-way operation is multiplication: it is easy to multiply two prime numbers of 100 digits to produce a 200-digit number, but hard to factor that 200-digit number. *** P ?=? NP -- Certainly the most important unsolved problem in complexity theory. If P = NP, then cryptography as we know it today does not exist. If P = NP, all NP problems are "easy." *** padding -- sending extra messages to confuse eavesdroppers and to defeat traffic analysis. Also adding random bits to a message to be enciphered. *** plaintext -- also called cleartext, the text that is to be enciphered. *** Pretty Good Privacy (PGP) -- Phillip ZimmermanUs implementation of RSA, recently upgraded to version 2.0, with more robust components and several new features. RSA Data Security has threatened PZ so he no longer works on it. Version 2.0 was written by a consortium of non-U.S. hackers. *** prime numbers -- integers with no factors other than themselves and 1. The number of primes is unbounded. About 1% of the 100 decimal digit numbers are prime. Since there are about 10^70 particles in the universe, there are about 10^23 100 digit primes for each and every particle in the universe! *** probabilistic encryption -- a scheme by Goldwasser, Micali, and Blum that allows multiple ciphertexts for the same plaintext, i.e., any given plaintext may have many ciphertexts if the ciphering is repeated. This protects against certain types of known ciphertext attacks on RSA. *** proofs of identity -- proving who you are, either your true name, or your digital identity. Generally, possession of the right key is sufficient proof (guard your key!). Some work has been done on "is-a-person" credentialling agencies, using the so-called Fiat-Shamir protocol...think of this as a way to issue unforgeable digital passports. Physical proof of identity may be done with biometric security methods. Zero knowledge proofs of identity reveal nothing beyond the fact that the identity is as claimed. This has obvious uses for computer access, passwords, etc. *** protocol -- a formal procedure for solving some problem. Modern cryptology is mostly about the study of protocols for many problems, such as coin-flipping, bit commitment (blobs), zero knowledge proofs, dining cryptographers, and so on. *** public key -- the key distributed publicly to potential message-senders. It may be published in a phonebook-like directory or otherwise sent. A major concern is the validity of this public key to guard against spoofing or impersonation. *** public key cryptosystem -- the modern breakthrough in cryptology, designed by Diffie and Hellman, with contributions from several others. Uses trap door one-way functions so that encryption may be done by anyone with access to the "public key" but decryption may be done only by the holder of the "private key." Encompasses public key encryption, digital signatures, digital cash, and many other protocols and applications. *** public key encryption -- the use of modern cryptologic methods to provided message security and authentication. The RSA algorithm is the most widely used form of public key encryption, although other systems exist. A public key may be freely published, e.g., in phonebook-like directories, while the corresponding private key is closely guarded. *** public key patents -- M.I.T. and Stanford, due to the work of Rivest, Shamir, Adleman, Diffie, Hellman, and Merkle, formed Public Key Partners to license the various public key, digital signature, and RSA patents. These patents, granted in the early 1980s, expire in the between 1998 and 2002. PKP has licensed RSA Data Security Inc., of Redwood City, CA, which handles the sales, etc. *** quantum cryptography -- a system based on quantum- mechanical principles. Eavesdroppers alter the quantum state of the system and so are detected. Developed by Brassard and Bennett, only small laboratory demonstrations have been made. *** reputations -- the trail of positive and negative associations and judgments that some entity accrues. Credit ratings, academic credentials, and trustworthiness are all examples. A digital pseudonym will accrue these reputation credentials based on actions, opinions of others, etc. In crypto anarchy, reputations and agoric systems will be of paramount importance. There are many fascinating issues of how reputation-based systems work, how credentials can be bought and sold, and so forth. *** RSA -- the main public key encryption algorithm, developed by Ron Rivest, Adi Shamir, and Kenneth Adleman. It exploits the difficulty of factoring large numbers to create a private key and public key. First invented in 1978, it remains the core of modern public key systems. It is usually much slower than DES, but special-purpose modular exponentiation chips will likely speed it up. A popular scheme for speed is to use RSA to transmit session keys and then a high-speed cipher like DES for the actual message text. *** Description -- Let p and q be large primes, typically with more than 100 digits. Let n = pq and find some e such that e is relatively prime to (p - 1)(q - 1). The set of numbers p, q, and e is the private key for RSA. The set of numbers n and e forms the public key (recall that knowing n is not sufficient to easily find p and q...the factoring problem). A message M is encrypted by computing M^e mod n. The owner of the private key can decrypt the encrypted message by exploiting number theory results, as follows. An integer d is computed such that ed =1 (mod (p - 1)(q - 1)). Euler proved a theorem that M^(ed) = M mod n and so M^(ed) mod n = M. This means that in some sense the integers e and d are "inverses" of each other. [If this is unclear, please see one of the many texts and articles on public key encryption.] *** secret key cryptosystem -- A system which uses the same key to encrypt and decrypt traffic at each end of a communication link. Also called a symmetric or one-key system. Contrast with public key cryptosystem. *** smart cards -- a computer chip embedded in credit card. They can hold cash, credentials, cryptographic keys, etc. Usually these are built with some degree of tamper- resistance. Smart cards may perform part of a crypto transaction, or all of it. Performing part of it may mean checking the computations of a more powerful computer, e.g., one in an ATM. *** spoofing, or masquerading -- posing as another user. Used for stealing passwords, modifying files, and stealing cash. Digital signatures and other authentication methods are useful to prevent this. Public keys must be validated and protected to ensure that others don't substitute their own public keys which users may then unwittingly use. *** steganography -- a part of cryptology dealing with hiding messages and obscuring who is sending and receiving messages. Message traffic is often padded to reduce the signals that would otherwise come from a sudden beginning of messages. *** symmetric cipher -- same as private key cryptosystem. *** tamper-responding modules, tamper-resistant modules (TRMs) -- sealed boxes or modules which are hard to open, requiring extensive probing and usually leaving ample evidence that the tampering has occurred. Various protective techniques are used, such as special metal or oxide layers on chips, armored coatings, embedded optical fibers, and other measures to thwart analysis. Popularly called "tamper-proof boxes." Uses include: smart cards, nuclear weapon initiators, cryptographic key holders, ATMs, etc. *** tampering, or active wiretapping -- interfering with messages and possibly modifying them. This may compromise data security, help to break ciphers, etc. See also spoofing. *** token -- some representation, such as ID cards, subway tokens, money, etc., that indicates possession of some property or value. *** traffic analysis -- determining who is sending or receiving messages by analyzing packets, frequency of packets, etc. A part of steganography. Usually handled with traffic padding. *** transmission rules -- the protocols for determining who can send messages in a DC protocol, and when. These rules are needed to prevent collision and deliberate jamming of the channels. *** trap messages -- dummy messages in DC Nets which are used to catch jammers and disrupters. The messages contain no private information and are published in a blob beforehand so that the trap message can later be opened to reveal the disrupter. (There are many strategies to explore here.) *** trap-door -- In cryptography, a piece of secret information that allows the holder of a private key to invert a normally hard to invert function. *** trap-door one way functions -- functions which are easy to compute in both the forward and reverse direction but for which the disclosure of an algorithm to compute the function in the forward direction does not provide information on how to compute the function in the reverse direction. More simply put, trap-door one way functions are one way for all but the holder of the secret information. The RSA algorithm is the best-known example of such a function. *** unconditional security -- same as information- theoretic security, that is, unbreakable except by loss or theft of the key. *** unconditionally secure -- where no amount of intercepted ciphertext is enough to allow the cipher to be broken, as with the use of a one-time pad cipher. Contrast with computationally secure. *** voting, cryptographic -- Various schemes have been devised for anonymous, untraceable voting. Voting schemes should have several properties: privacy of the vote, security of the vote (no multiple votes), robustness against disruption by jammers or disrupters, verifiability (voter has confidence in the results), and efficiency. *** zero knowledge proofs -- proofs in which no knowledge of the actual proof is conveyed. Peggy the Prover demonstrates to Sid the Skeptic that she is indeed in possession of some piece of knowledge without actually revealing any of that knowledge. This is useful for access to computers, because eavesdroppers or dishonest sysops cannot steal the knowledge given. Also called minimum disclosure proofs. Useful for proving possession of some property, or credential, such as age or voting status, without revealing personal information. -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Sun, 22 Nov 92 12:15:22 PST To: cypherpunks@toad.com Subject: The Crypto Anarchist Manifesto Message-ID: <9211222011.AA29961@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Cypherpunks of the World, Several of you at the "physical Cypherpunks" gathering yesterday in Silicon Valley requested that more of the material passed out in meetings be available electronically to the entire readership of the Cypherpunks list, spooks, eavesdroppers, and all. Here's the "Crypto Anarchist Manifesto" I read at the September 1992 founding meeting. It dates back to mid-1988 and was distributed to some like-minded techno-anarchists at the "Crypto '88" conference and then again at the "Hackers Conference" that year. I later gave talks at Hackers on this in 1989 and 1990. There are a few things I'd change, but for historical reasons I'll just leave it as is. Some of the terms may be unfamiliar to you...I hope the Crypto Glossary I just distributed will help. (This should explain all those cryptic terms in my .signature!) --Tim May ................................................... The Crypto Anarchist Manifesto Timothy C. May tcmay@netcom.com A specter is haunting the modern world, the specter of crypto anarchy. Computer technology is on the verge of providing the ability for individuals and groups to communicate and interact with each other in a totally anonymous manner. Two persons may exchange messages, conduct business, and negotiate electronic contracts without ever knowing the True Name, or legal identity, of the other. Interactions over networks will be untraceable, via extensive re- routing of encrypted packets and tamper-proof boxes which implement cryptographic protocols with nearly perfect assurance against any tampering. Reputations will be of central importance, far more important in dealings than even the credit ratings of today. These developments will alter completely the nature of government regulation, the ability to tax and control economic interactions, the ability to keep information secret, and will even alter the nature of trust and reputation. The technology for this revolution--and it surely will be both a social and economic revolution--has existed in theory for the past decade. The methods are based upon public-key encryption, zero-knowledge interactive proof systems, and various software protocols for interaction, authentication, and verification. The focus has until now been on academic conferences in Europe and the U.S., conferences monitored closely by the National Security Agency. But only recently have computer networks and personal computers attained sufficient speed to make the ideas practically realizable. And the next ten years will bring enough additional speed to make the ideas economically feasible and essentially unstoppable. High-speed networks, ISDN, tamper-proof boxes, smart cards, satellites, Ku-band transmitters, multi-MIPS personal computers, and encryption chips now under development will be some of the enabling technologies. The State will of course try to slow or halt the spread of this technology, citing national security concerns, use of the technology by drug dealers and tax evaders, and fears of societal disintegration. Many of these concerns will be valid; crypto anarchy will allow national secrets to be trade freely and will allow illicit and stolen materials to be traded. An anonymous computerized market will even make possible abhorrent markets for assassinations and extortion. Various criminal and foreign elements will be active users of CryptoNet. But this will not halt the spread of crypto anarchy. Just as the technology of printing altered and reduced the power of medieval guilds and the social power structure, so too will cryptologic methods fundamentally alter the nature of corporations and of government interference in economic transactions. Combined with emerging information markets, crypto anarchy will create a liquid market for any and all material which can be put into words and pictures. And just as a seemingly minor invention like barbed wire made possible the fencing-off of vast ranches and farms, thus altering forever the concepts of land and property rights in the frontier West, so too will the seemingly minor discovery out of an arcane branch of mathematics come to be the wire clippers which dismantle the barbed wire around intellectual property. Arise, you have nothing to lose but your barbed wire fences! -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: crunch@netcom.com (John Draper) Date: Mon, 23 Nov 92 02:17:59 PST To: cypherpunks@toad.com Subject: Status on Mac PGP Message-ID: <9211231013.AA10065@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Greetings cypherpunks: Talked to Phiil Zimmerman on phone this evening, and he recommends that the current Mac team be devided up into teo parts. One a short term team which no doubt will be what exists already, and a long term team to do a more Mac'ish GUI. I agreed to do that, and Phil is planning to set up a phone conference call with the entire Mac PGP team to introduce the new proposals to everyone at once. this meeting will happen sometime early this week, and I'll be giving reports on what has transpired. I also sent to each of the Mac PGP members the details of the cypherspace meeting, but have not yet mentioned my proposal to help manage the team, as I want to meet everyone first. I also agreed to make up a function list of the C functions in the PGP program (Which I usually do when I study new code), and will send it to anyone who wants it. Oh!! By the way, If I start up the existing Mac PGP, running Microphone II at the same time. Then, when I encrypt a file, it hangs up the system. This only hangs up when I decrypt a file first, then I go into editor to edit a file, and save it. After saving the plaintext file, then I encrypt it, it will hang up the Mac and needs resetting. It requires a COLD boot, and not a simple reset. Has anyone else experienced this problem? I suspect that a new version of Mac PGP might soon become available. Hmmm I must start thinking of what the ICON should look like!! More later.... John D. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: andrew m. boardman Date: Mon, 23 Nov 92 02:02:28 PST To: pmetzger@shearson.com Subject: The legality of PGP In-Reply-To: <9211201648.AA19486@newsu.shearson.com> Message-ID: <9211230949.AA13573@shadow.cs.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain >I wonder--I have RSA Mailsafe. Do you think that would give me a license >to use RSA if I loaded up PGP? Keith Doubtful -- RSA tends to be licensed on a per application per copy basis, not on a per human basis. If it was licensed on a per-human basis, I would have bought a personal "unlimited use" license long ago. Well, they sell licenses for RC2 and RC4 for $100 per, which are on a per-person basis. And something said to me at Weenix Expo by an RSA salesdroid implied that $100 could get one a generic kind of RSA license. I didn't press the point, and I don't have anything in writing, but they're happy to talk at 415.595.8782 if you want better than unsubstantiated hearsay... I'd call myself if I was ever awake during PST business hours... andrew From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: "Mark W. Eichin" Date: Mon, 23 Nov 92 12:17:13 PST To: crunch@netcom.com Subject: re: Status on Mac PGP In-Reply-To: <9211231013.AA10065@netcom2.netcom.com> Message-ID: <9211232016.AA12371@tweedledumber.cygnus.com> MIME-Version: 1.0 Content-Type: text/plain >> short term team which no doubt will be what exists already, and I assume you already know that a Mac PGP exists? I didn't mention it before because the discussion seemed to be about doing a "real" version. mac.archive.umich.edu:mac/util/encryption/macpgp2.0.sit.hqx is the path. It is still there right now... _Mark_ % ftp mac.archive.umich.edu Connected to mac.archive.umich.edu. 220- 220- Welcome to 220- the U of M Software Archives 220- 220- 220 carpediem.ccs.itd.umich.edu FTP server (Version 6.9 Thu Oct 15 23:44:46 EDT 1992) ready. Name (mac.archive.umich.edu:eichin): ftp 331 Guest login ok, send e-mail address as password. Password: 230-Please read the file 00readme.txt 230- it was last modified on Tue Nov 17 22:08:12 1992 - 6 days ago 230 Guest login ok, access restrictions apply. ftp> cd mac 250- 250-Please read the files in /mac/00help if you have problems. 250- 250 CWD command successful. ftp> cd util 250 CWD command successful. ftp> cd encryption 250 CWD command successful. ftp> dir 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls. total 364 drwxrwxr-x 2 20020 staff 2048 Dec 31 1991 .AppleDouble -rw-rw-r-- 1 25319 staff 54788 Oct 13 05:42 crypto1.23.cpt.hqx -rw-rw-r-- 1 20062 staff 19987 Feb 6 1991 des.hqx -rw-rw-r-- 1 25319 staff 56824 Nov 14 08:55 enigma1.1.sit.hqx -rw-rw-r-- 1 20062 staff 26227 Feb 1 1992 leescrypto1.2.cpt.hqx -rw-rw-r-- 1 23424 staff 210389 Oct 30 19:45 macpgp2.0.sit.hqx 226 Transfer complete. 439 bytes received in 0.21 seconds (2 Kbytes/s) ftp> From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: edgar@spectrx.Saigon.COM (Edgar W. Swank) Date: Wed, 25 Nov 92 03:28:55 PST To: Cypherpunks Subject: SF Bay Area Parties Message-ID: MIME-Version: 1.0 Content-Type: text/plain Distribution: Cypherpunks Extropians Libernet Since all the above groups, of which I am a member, are not known for sponsoring social functions, I suggest we co-opt the Pen SFA parties. Their latest "Winnie" newsletter is attached. Please note and follow "rules". I especially recommend the 12/26 party. PGPers, bring your printed public keys for exchange. If you like these parties, please sign up for free E-Mail distribution of your own copy of the newsletter, as I will not post it every month. =================Copy of Newsletter follows========================== Date: Sat, 21 Nov 92 12:51:33 PST Subject: Winnie the POO #380 Winnie the POO #380, November 21, 1992 Published for the Peninsula Science Fantasy Association by its commander, Rich McAllister, 149 Webster St, Palo Alto, CA 94301. (415)328-2741. rfm@Eng.Sun.com. Winnies are available by US Mail at 5/$2, or via electronic mail (Internet/UUCP/CompuServe/FIDONET) free. If you're mailing payment make checks to Rich McAllister, or send stamps. I prefer stamps, so I'll give you one issue for each 29 cent stamp you send, and eat the repro cost myself. The number above your name on the label is the number of the last Winnie you will receive unless you Do Something. A 999 means you get Winnie by trade. PenSFA standard party rules: bring something edible or drinkable to share, or pay the host $2. Don't smoke in the house without checking with the host first. Normal start time is 8PM. NO SECOND NOVEMBER MEETING (11/28) We will not have a second November meeting because of Silicon. NOTE: SILICON IS NOT AT THE RED LION! (This seems to be a well kept secret.) Silicon is at the Westin Santa Clara. This is the hotel between Techmart and the Santa Clara Convention Center. (It used to be the Doubletree.) Take the Great America Parkway exit from 101, go past Great America; as soon as you cross the trolley tracks, you're there. Friday, Saturday, and Sunday. I probably won't be there to organize a PenSFA event. I suggest interested folks meet at 6PM Saturday in the lobby for a dinner expedition. FIRST DECEMBER MEETING (12/12) Party at Danny Low's, 1460 San Marcos Circle, Mtn. View. (415)964-0688. Standard time, 8PM, standard rules. Easy to find with a map. SECOND DECEMBER MEETING (12/26) Potluck at the home of Keith Henson and Arel Lucas, 1794 Cardel Way, San Jose, CA. (408)978-7616. 5PM start. Standard party/potluck rules: bring dinner and munchies/drinks if you come early, or just munchies/drinks if you come at 8PM. Keith offered to fire up the BBQ, weather permitting, but I wouldn't count on it. NEW DIRECTIONS (road construction has made the old directions obsolete.) Directions: From 280, take 17 south to Camden Ave exit. Go under freeway, follow Camden east. Turn south from Camden on Leigh, go two lights south to Los Gatos Almaden road, left and almost to where it ends in a T is Elrose. Left onto Elrose and another immediate left onto Cardel Way. We are near the end at 1794. NOT A DECEMBER MEETING (12/31) Mike Ward is having a New Year's party again, and again all PenSFAns are invited. 1181 Martin Drive, San Jose. 408-298-3269. Future Meetings: NOTHING SCHEDULED until 3/6-MIke Ward. As always, contact the Commander to take a date. -- edgar@spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: fnerd@smds.com (FutureNerd Steve Witham) Date: Mon, 23 Nov 92 14:40:40 PST To: cypherpunks@toad.com Subject: Re: Hackers, Crackers Message-ID: <9211232221.AB05926@smds.com> MIME-Version: 1.0 Content-Type: text/plain >Let's cut out this elitist "crackers" crap altogether. >It's just a little bit too PlaySkool, a little bit too >"_I'm_ not a third grader! I'm a _fourth grader_!" The people >who put so much energy into advertising how they're different >tend not to know what the fuck they're talking about, in >my experience. Well, I don't know about this guy, but there's something similar that occurred to me during the hackers conference. Some of the people on this list heard me express it badly, and I wanted to clarify. We always used to distinguish hackers from crackers. But cracking reveals the cracks in a way that nothing else does. It makes them real, sometimes laughably or painfully so. Electronic privacy is currently a joke. It's bad. You need to know what kinds of attacks you're trying to defend against. I used to think those arguments were rationalizations. Now I'm glad there are people who know this stuff, who are actually doing it. Some of "them" are on what I think of as the good side, and "we" need that kind of knowledge, if only as an occasional splash of cold water, a spur (to switch metaphorical, er, horses in mid, um, stream). -fnerd quote me fnerd@smds.com (FutureNerd Steve Witham) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Tue, 24 Nov 92 11:58:48 PST To: cypherpunks@toad.com Subject: Scenario for a Ban on Cash Transactions Message-ID: <9211241954.AA17648@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Cypherpunks of the World, I'm relatively convinced that the various "trial balloons" for restricting the use of encryption are part and parcel of a larger, albeit not formally discussed, plan to adopt some form of a digital cash system. Before your start cheering, it is highly unlikely that this system will the "digital cash" system of the form we have been discussing (anonymous transactions, untraceability, David Chaum-style systems, etc.). My grim scenario is contained in the message below, which I just posted to another list, the "Extropians" list. --Tim May Forwarded message: From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay (Timothy C. May) Date: Tue, 24 Nov 92 11:44:08 PST To: extropians@gnu.ai.mit.edu Subject: Scenario for a Ban on Cash Transactions Message-ID: <9211241944.AA16548@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain SCENARIO FOR A BAN ON CASH TRANSACTIONS The recent discussions about black markets, loss of tax revenues, and restrictions on the use of encryption lead me to speculate that moves may be afoot to ban or severely restrict the use of cash. Such talk of a "cashless society" comes up periodically, with some taking a religious/conspiratorial view (electronic bank accounts tatooed on our foreheads, fulfilling the "mark of the Beast" prophecy) and others talking about how the "international bankers" have already selected a system (to be implemented in a national emergency, perhaps an Emergency Order following a series of bank collapses). Some putative benefits of banning cash and replacing it with electronic versions (such as debit cards, either privately issued or issued by the government): 1. Faster and more complete tax collection, with the tax authorities and implicit partner in all economic transactions (save for black markets, but I'll discuss that later). The "faster" part will be a one-shot gain, just as the witholding tax system instituted in WWII as an emergency program was a one-shot benefit. But such an immediate gain may be quite attractive to planners faced with rapidly escalating national debt. ($4.5 trillion, increasing by at least $400 billion a year...more if the "IOUs" for social security are considered) The "more complete" part will be an attempt to recapture taxes now lost to the underground, or barter, economy. "Serious" black marketeers, or dealers in illegal substances, will of course not be greatly affected, but a shift to purely electronic money will hurt their ability to move money (unless they control the banks and S&Ls, as may be the case....but that's another story). 2. A general closing of the underground economy, separate from the issue of recapturing lost tax revenues. As the underground economy increases, especially to the levels seen in other countries, pressures to "close the loopholes" (= cash) may mount. The failing "War on Drugs" has already been used to justify many serious abridgements of basic rights; applying the same logic to creating a cashless society seems to be the next step. 3. "Welfare reform" by restricting the allowable expenditures that can be made. For example, a welfare, food stamp, or AFDC recipient could be barred from buying liquor with his or her "money." Electronic money need not be "fungible," in the sense that all forms are interchangeable--it is fairly easy to attach various restrictions to the electronic databases which hold the money. Such restrictions would meet with a lot of popular support, and so could undercut the protests a bit. (Support may also come from the "national identity card" aspects, as such a card would help to solve the problem of illegal immigrants and those who move to jurisdictions with better welfare benefits. I'm not _approving_ of this, merely pointing out a source of support for "welfare cards.") (Bypasses can still be done, as with food stamps which are sold in exchange for booze. Ironically, the flourishing black market in food stamps is a motivation for going to an "electronic welfare card," which is being talked about and which is an obvious precursor step to the eventual ban on paper money cash.) 4. Fears of the growing ease of counterfeiting may push this shift along. Color copiers are now so good that nearly undetectable counterfeiting of U.S. currency is straightforward. Attempts to embed conductive threads, holograms, etc., are helping, but the longterm future is not bright for physical money (excluding gold, which has its own problems that I won't discuss here). (Note that foreign printing presses can quite easily produce excellent counterfeit currency, for use in destabilizing foreign regimes, in economic warfare, etc. Apparently the U.S. has supported the flooding of Iraq with counterfeit currency. And Iraq has supposedly printed vast amounts of counterfeit U.S. and European currency. Digital money, cryptographically protected, is about the only protection against this threat.) 5. If the government controls and sets the protocols for electronic money, this gives them de facto control over encryption systems and protocols. Use of non-approved protocols may be considered ipso facto proof of money laundering, black marketeering, and tax evasion. The Dennning/Rivest key registration proposal appears to be some advance planning for creating a system in which the government is effectively a third party in all communications (= transactions). I suggest we look at all such key registration proposals in this light. 6. More speculatively, the elimination of cash may be used to prop up U.S. banks, which many feel are facing a rocky future. By making the banks the "mediators" of such a government-mandated electronic money system, this both "privatizes" the system and provides a new revenue stream for these powerful lobbying interests. For example, your local bank may issue the debit card and may take, say, 0.5% of every transaction. The government might then take, say, 3% of every transaction as its "cut." (The actual details are likely to be hideously complex, along the lines of the V.A.T. taxes of Europe, and so this example should only be taken as a rough example of what could happen.) Now it has long been clear to me that the future of money lies in electronic form, cryptographically protected. The prolific use of credit cards for mail-order purchases points to the need for a purely electronic form of usable money, as do systems like AMIX (which uses VISA-type credits and debits). The issue is who creates this system, and what controls exist. It seems unlikely that the U.S. government will allow "competing currencies" (one form of digital money, and arguably what we already have with various tradable financial instruments, which rise and fall in value depending on various forces) to spring into being, at least not in forms that are truly like cash. However, if the government creates this cashless society, then the government will have unprecedented control over nearly all aspects of our lives. All transactions, no matter how trivial, will be recorded, stored, and subject to analysis. A complete audit trail of all purchases, food preferences, entertainment choices, liasons with others, etc., will exist. This is the concern David Chaum has eloquently raised, and which he has been dealing with (partially) with his digital money and untraceable transactions systems. Furthermore, transactions which are deemed to be politically incorrect, and there are dozens of obvious examples to choose from, can be _outlawed_ by the mere typing of a few lines of instructions into the appropriate data bases. (For example, someone arrested for DUI tries to buy some beer..."Your transaction cannot be completed. Have a nice day." appears on the cash register. Or a pregnant woman--and under Clinton's computerized health care system this will all be known--tries to buy some cigarettes....) Reread John Brunner's amazingly prescient "Shockwave Rider" for some visions of a fully-computerized society. This trend toward a cashless society, controlled by the government, represents the greatest threat to our libery and our future I can imagine. We need to start planning to head this off. Those interested in "crypto anarchy" as one technological solution are encourage to get in touch with me. (I now have MacPGP, which makes things slightly easier than before, but it's still a pain to download files and decrypt them. The anonymous remailer services discussed on the "Cypherpunks" list should help as well.) Make no mistake, a government-run cashless society will be worse that Orwell's worst. --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: fnerd@smds.com (FutureNerd Steve Witham) Date: Tue, 24 Nov 92 11:06:50 PST To: cypherpunks@toad.com Subject: Remailer ideas Message-ID: <9211241849.AB05399@smds.com> MIME-Version: 1.0 Content-Type: text/plain Tom.Jennings@f111.n125.z1.FIDONET.ORG sez >Well, remailers are working, admittedly a bit clunky at the moment, Okay, here's something easy to implement: a "From: stripper" specifically for the cypherpunks address, like, cypherpunks-anon@toad.com . The point is that all you have to do to use it is to have the address. The same for the following ideas: Harder: something that takes mail to arbitrary "user ids" at its machine and remails based on them, so you could send to me at, say, sw%%smds.com@remailer.somewhere.com . Harder: take a long encrypted address as the user id. Do mail systems allow arbitrary length user ids? Anyway, you'd be mailing to things like: wjefa248hap94ghs39p8g4s9perspe98b9p08serhg9p8serh9sherp9hse9rp89sper898psexrg99p8ser989regp9ser9pys98per9pse8ry9p8sxyer9p8yser9p8ys9per8p9se8ry9pseyr8sezrpahw4pwa49nw84th9w8y34w456yuvw05536vue4w5vw38064vw306uw45@remailer.somewhere.com I realize these things have weaknesses beyond the kazoo, but wadaya think? -fnerd fnerd@smds.com (FutureNerd Steve Witham) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: julian@panix.com (Julian Dibbell) Date: Tue, 24 Nov 92 13:47:22 PST To: cypherpunks@toad.com Subject: Mailing-list Message-ID: <9211242017.AA21820@panix.com> MIME-Version: 1.0 Content-Type: text/plain Can you add me to the cypherpunks mailing list? --Julian Dibbell, julian@panix.com (Steven Levy and/or Tim May may [or may not] vouch for my worthiness, as necessary) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Fan Li TAI Date: Tue, 24 Nov 92 14:57:29 PST To: cypherpunks@toad.com Subject: Question about the MacPGP Message-ID: <9211242257.AA21968@toad.com> MIME-Version: 1.0 Content-Type: text/plain Hiya, About the MacPGP, isn't it possible to sort of write a script addon to the various telecoms software? What I mean is that when you start reading mail, you click somewhere, and all input from the modem is translated direct by the script so that you can read the plaintext. But when you reply, you will have to use the telecoms' editor and upload the text... Somewhat like that rot13 thing in news really (or the VMS implemantation of it). Ciao. -Tai From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: dkrieger@netcom.com (David Krieger) Date: Tue, 24 Nov 92 17:01:11 PST To: crunch@netcom.com (John Draper) Subject: One Mac feature I'd like Message-ID: <9211250057.AA08182@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain John -- While using MacPGP yesterday, I thought of a useful feature that (I hope) wouldn't be too hard to implement -- the ability to encrypt to/ decrypt from the Clipboard. This would eliminate the need for saving one's text as a file in order to use PGP... one could Copy text from any text application, open PGP, encrypt it in the Clipboard, and switch to a terminal program to Paste it to a host for mailing... or, one could Copy ciphertext from the terminal program and decrypt it from the Clipboard. dk -- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Tue, 24 Nov 92 17:54:15 PST To: cypherpunks@toad.com Subject: The List is YOURS, So Speak Up! Message-ID: <9211250150.AA12171@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Lurking Cypherpunks, My message earlier today on a scenario for the banning of cash led to about 10 responses mailed to me in private e-mail. Typical is the following (the author has been deleted, as he chose not to post it to the list as a whole): "I'm interested. I was considering removing myself from the cyberpunks list, because the traffic/info. ratio is too high (low?).. I'm glad I didn't, because your message is the type of thing I joined the list to read. I don't suppose there somewhere where I can get a 'condensed version' of the cyberpunks list, or something similar? "I've heard a bit about "crypto anarchy" (only from cyberpunks mailing list), and i'm interested. What's the next step?" You folks out there ARE the list! If there's something you want discussed, go ahead and start a new thread. Raise some issues, stir up some shit. It seems from some of the messages I got today that people think they either have little to add to the discussion, or are fearful of the consequences of posting their comments to a list such as ours. About the former point, all I can say is that the best learning comes from arguing a position and learning to defend it. Merely _posting_ a message generates added interest and piquancy about the list, I've discovered. So consider this an invitation to the hundred or so folks who have yet to post on this list! For those who are paranoid, well, chances are They already know who you are. They have files on you. Remember this, * It is not illegal to advocate violence. AND * it is not illegal to advocate the overthrow of the government. HOWEVER, * it _is_ illegal to advocate the overthrow of the government by violent means. If you stay away from this last item, you're relatively safe. (Even advocating drug use has not seemed to have much effect on the posters on alt.drugs.) In any case, the work being done by Eric Hughes, Hal Finney, and others, should give us fully anonymous posting capabilitites in the near future. Even with digital pseudonyms! (Check out the postings of "Cassandra" and "Pollyanna" for starters.) If the socioeconomic aspects of crypto anarchy interest you more than, say, discussions of random number generators, then clearly you should _post_ on those topics! And if all you have are _questions_, then by all means ask them! Those of us who post frequently on this list cannot try to anticipate your questions and concerns. I've been spouting this stuff for years and they haven't taken me away yet, nor have they [TRANSMISSION HALTED BY ORDER OF THE CRYPTO AUTHORITY] -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Tue, 24 Nov 92 18:24:38 PST To: cypherpunks@toad.com Subject: Re: DC-NETS & bibliography request In-Reply-To: <9211250202.AA11244@tweedledumber.cygnus.com> Message-ID: <9211250220.AA14681@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Reading Material: > This list is the first place I'd seen references to DC-NETS; thanks > for the glossary posting explaining what the term is. Is there a > published paper on them, or somewhere else I can get info on the > algorithms involved? > On a related note, is there a "crypto anarchy reading list" or > bibliography that anyone has collected, for further delving into the > terms brought up? I suspect many of the better references would only > be available in electronic form, but they should still be listed... > > _Mark_ > MIT Student Information Processing Board > Cygnus Support The article I posted, and the article Hal Finney posted, contains references to the original DC-Net paper. It was in the Journal of Cryptology, Volume I, Number 1. Only a very large university library will carry it. (My nearest university, UC Santa Cruz, does _not_. I subscribed for a while, because of attending the Crypto '88 conference, and so I was able to include this seminal paper in the Xeroxed handout for the attendees at our first Cypherpunks meeting. I regret that I cannot mail anymore copies to people. If you are really interested in DC-Nets, read the posted articles first and then you'll surely find a way to get the journal articles.) The standard sources for modrern crypto are the proceedings each year of the "Crypto" and "EuroCrypt" conferences. Also, at least half a dozen good books have been written, some of which have been mentioned in earlier postings. And Fen Le Balme posted his won search list a few weeks ago. At some point an FAQ and bibliography list will exist (I am not maintaing the FAQ or the bibio, though). Here's a typical reference: 16. CRYPTO '91 (1991 : University of California, Santa Barbara) Advances in cryptology--CRYPTO '91 : proceedings / J. Feigenbaum (ed.). Berlin ; New York : Springer-Verlag, c1992. Series title: Lecture notes in computer science ; 576. UCB Engin QA76.9.A25 C79 1991 UCD Phys Sci QA267.A1 L43 no.576 UCI Main Lib QA76.9.A25 C79 1991 UCLA Engr/Math QA 76.9 A25 C79 1991 UCR Rivera QA76.9.A25 C79 1991 UCSB Library QA76.9.A25 C79 1991 Sci-Engrg UCSC Science QA76.9.A25C79 1991 UCSD S & E QA76.9.A25 C79 1991 The books in the "QA76.9.A25" section (Library of Congress numbering of course) will provide pointers. Sadly, there are no "Neat Crypto Ideas for the Casually Interested" books. Some of us have debated writing such a book for Loompanics Press. --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tribble@xanadu.com (E. Dean Tribble) Date: Tue, 24 Nov 92 19:03:37 PST To: uunet!smds.com!fnerd@uunet.UU.NET Subject: Hackers, Crackers We always used to distinguish hackers from crackers. But cracking reveals the cracks in a way that nothing else does. It makes them real, sometimes laughably or painfully so. Electronic privacy is currently a joke. It's bad. You need to know what kinds of attacks you're trying to defend against. I used to think those arguments were rationalizations. Now I'm glad there are people who know this stuff, who are actually doing it. Some of "them" are on what I think of as the good side, and "we" need that kind of knowledge, if only as an occasional splash of cold water, a spur (to switch metaphorical, er, horses in mid, um, stream). In-Reply-To: <9211232221.AB05926@smds.com> Message-ID: <9211250220.AA26816@xanadu.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain And if I shoot you or poison you, I will have vividly revealed to you your pathetic lack of physical defenses. Will I have done you a service? How about if I just break your windows or doors? That rationalization for crackers is based on the idea that perfect security is feasible. Once you view this from an economic perspective, then the only things the crackers do is raise the cost of getting to a level of security such that operation can continue uninterrupted. BTW: I happen to believe that within a trusted infrastructure, perfect security is possible. Even so, consider the cost of changing operating systems, retraining all staff, reproducing familiar applications on a new substrate. Even if perfect security is possible, the use of it is still bounded by economic and social concerns. dean BTW: feel free to forward to extropians. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tribble@xanadu.com (E. Dean Tribble) Date: Tue, 24 Nov 92 19:03:37 PST To: uunet!smds.com!fnerd@uunet.UU.NET Subject: Remailer ideas In-Reply-To: <9211241849.AB05399@smds.com> Message-ID: <9211250223.AA26837@xanadu.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain The mail handling stuff we discussed at the last cypherpunks meeting will implement what you requested. The particular thing that hadn't occurred to me in what you said is that a mailing list supplier could provide those extra services of anonymity in a way very accessible to users of the mailing list. That could make such anonymity slightly easier to spread. dean From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: "Mark W. Eichin" Date: Tue, 24 Nov 92 18:02:57 PST To: cypherpunks@toad.com Subject: DC-NETS & bibliography request Message-ID: <9211250202.AA11244@tweedledumber.cygnus.com> MIME-Version: 1.0 Content-Type: text/plain This list is the first place I'd seen references to DC-NETS; thanks for the glossary posting explaining what the term is. Is there a published paper on them, or somewhere else I can get info on the algorithms involved? On a related note, is there a "crypto anarchy reading list" or bibliography that anyone has collected, for further delving into the terms brought up? I suspect many of the better references would only be available in electronic form, but they should still be listed... _Mark_ MIT Student Information Processing Board Cygnus Support From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Tue, 24 Nov 92 21:12:15 PST To: cypherpunks@toad.com Subject: An Anonymous Contribution... Message-ID: <9211250508.AA01456@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain (The following message arrive in my mailbox, with a request to repost it anonymously. Sometimes these "manual" methods work pretty well! --Tim May) Tim, I have been following your arguments in CypherPunks. The name will turn off a lot of your natural friends, but your arguments are dead on. The Crux of the matter is digital cash. And getting these anonymous remailers working. PGP is a basic enabling thing. Not that RSA hasn't been around forever, but it just wasn't useable without a standard. My deepest gratitude to you and your friends. The remailer business needs to get standardized also. My personal hack is attached below. One problem not addressed in the first crop of remailers is the problem of how do you handle return paths. There are lots of trivial ways to get anonymous outgoing mail. Most telephone systems do not identify the caller, there are lots of other ways to get this function. But the problem is getting an answer back with out unmasking. The mathematicians may be able to conjure up a better scheme, but I see the backward security to be simply a matter of tearing the connection (return path down) faster than it can be backtraced. It would be nicer if some kind of DC-net return path could be devised. But timeout control will definitely work. With a large number of the forwaring nodes, and multi-hop paths, it would become quickly very impractical to shake down the originator, So the return path could be left "up" for quite some time before having to replace it. Certainly long enough for a reasonable reply. Better yet of cource would be a completely uncrackable return path that you could leave up long enough to use institutional advertising. Eg: run a business from. Another way to leave up long lasting connections (return paths) is to select one really HARD point node. This is the one they have to shake down first. And use continuously shifting paths behind that node. (all sounds like a router ? ) If you could repost this anonymously I sure would appreciate it. I am (ahem, respectable), and have some kids left to feed. Could you tell me how to find out more about David Chaum's work? do you have an email address for him, is he on one of the mailers, or have anything published? My hunch is that this whole business could heat up fast. Within just a few years the government could be forced into "wage/price" controls. A great application for the NREN? Thanks, xxxxxxxx@yyyyyy.zzz ---------Tear off ----- This is a proposal for a simple anonymous forwarding protocol. 1> With the exception of cases 4> and 5> below: Any message addressed to the forwarding node that does not contain a valid PGP encrypted block, encrypted with the node's public key causes the forwarding node to reply to the sender with its public key, plus whatever other text the node wishes to add. 2> If a properly encrypted message is decrypted with the node's secret key; The body of the decrypted message is scanned for the following sequence: "Please forward this message to:" FORWARD.ADDRESS "Thank you." The trigger strings are what is shown above in the quote marks but not including the quote marks. No actual quote marks are used. Everything after the period of the Thank you. string is forwarded to the address specified by the FORWARD.ADDRESS string. Messages not containing the forwarding request are presumed to be addressed to the node itself. 3> The incoming RETURN.ADDRESS and the FORWARD.ADDRESS are stored by the node. ---- Clean up. 4> Receipt of a message whose RETURN.ADDRESS matches a stored FORWARD.ADDRESS will be repeated without modification to the stored RETURN.ADDRESS associated with the stored FORWARD. ADDRESS. Bounced mail is returned similarly, 5> Receipt of a message whose RETURN.ADDRESS matches a previously stored RETURN.ADDRESS will cause a message to be forwarded to the previously stored FORWARD.ADDRESS If the incomming message in this case contains a valid encrypted block, It will be decrypted and forwarded. Otherwise, whatever contents of the body found will be forwarded. Subject lines should be repeated without modification. Null bodies or subject lines should work. 6> In both cases 4> and 5>, the stored RETURN/FORWARD addresses are erased. -xxxxxxx -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Bob Stratton Date: Tue, 24 Nov 92 18:16:51 PST To: cypherpunks@toad.com Subject: Re: The List is YOURS, So Speak Up! Message-ID: <9211242116.AA28432@horton.intercon.com> MIME-Version: 1.0 Content-Type: text/plain Hi all, After Tim's stirring message about the use of the list, I couldn't help but drop a line to the list myself. I'm yet another person interested in Mac implementations of PGP, and encrypted mailers. I work for a Macintosh software company as a developer, but have spent most of the last several years working with big machines, so I haven't picked up all of the bad habits that I see Macs furthering across the Net. (Most of these have to do with writing unportable code, as if no other manufacturers' hardware matters.) I'm also sort a mailer weenie, so this talk of encrypted mailers has me quite interested. I've started studying more of the fundamentals (I've only read David Kahn's book, back in 8th grade, which was a while ago :-) I'm especially interested in the MIME/PEM issues, and fervently request coredumps from anyone who's been following those to date. My company (which I DO NOT speak for) develops TCP/IP based communications software for the Mac, so needless to say, a nice RSA-encrypted Mac mailer could fall within our purview. My company is also very interested in privacy issues. In point of fact, the VP of Engineering and I recently addressed a Virginia state assembly subcommittee for purposes of having them remove SSNs from driver's licenses.. (YAY!) I'm new to tbe Mac world, but not the mailer world. I shall try to be a resource for this list's work. There's another person here who's also interested in the GUI design for a new Mac incarnation of PGP. I see a couple of possible UI features: - Live folders, for drag and drop en/decryption - Encryption to/from the clipboard (which is basically what I'm doing now, except through intermediate files) - An MPW tool implementation, with pipes. (I suspect that I'd use this mostly for testing the 'engines') I want to reiterate the sentiment posted by several to KEEP THINGS PORTABLE. I know it's not chic for a Mac developer to say that, but so be it. Bob Stratton Engineer, InterCon Systems Corp. +1 703 709 5525 "The Constitution's not perfect, but it's a damn sight better than what we have now." From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nobody@alumni.cco.caltech.edu Date: Tue, 24 Nov 92 22:12:47 PST To: cypherpunks@toad.com Subject: Re: Extortion Explosion Message-ID: <9211250614.AA17663@alumni.cco.caltech.edu> MIME-Version: 1.0 Content-Type: text/plain Here's another thought about how crypto anonymity can improve public safety. Today, a lot of police activity is based on informants and "anonymous" tips. Policemen build up relationships with underworld characters who can give them information about criminal activity. In return, the police may offer favors, immunity from arrest, perhaps even cash or contraband in some instances. Some people have claimed that "anonymous sources" are an excuse sometimes used to cover up illegal police activity. An illegal wiretap is used to acquire information, then a warrant is obtained based on this information with the claim that it was actually acquired through an anonymous informant. With the warrant in place, the wiretap is now done legally, and evidence is produced which can be used in court. One problem with anonymous tips is that the people making them are taking a risk. If word gets out that a certain person tipped off the police to some criminal act, they may be targetted for revenge. Personal meetings between police and informers are often necessary (perhaps for payoffs to occur) and these are risky for all involved. Crypto anonymity could make anonymous informing easy and safe. Of course, not all tips would be valuable, but some fraction would be helpful in preventing crimes. Crypto pseudonyms and signatures could be used for informants to develop reputations so that those who have been accurate in the past will get the most attention. Digital cash could even be used for payoffs from cops to informants "under the table", with no need for dangerous face-to-face meetings. A system could even develop in which police would have to bring to a judge not just a blanket claim that there was an anonymous informant, but more substantial evidence, in the form of a digitally signed statement by a pseudonym known to have produced useful information in the past. This could reduce the problem of imaginary informants invented to excuse illegal police activity. Polyanna -----BEGIN PGP PUBLIC KEY BLOCK----- mQA9AisGm6sAAAEBgLsub7XIi32DjNFKJmGFajDNNIeql4RBmHG/mh9Ns58aBgMv wGRi0KkZ0YIYZZnLpwAFEbQkUG9seWFubmEsIGMvbyA8Y3lwaGVycHVua3NAdG9h ZC5jb20+ -----END PGP PUBLIC KEY BLOCK----- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: DELTORTO@AppleLink.Apple.COM (Imaja, David Del Torto,PAS) Date: Tue, 24 Nov 92 16:36:01 PST To: CYPHERPUNKS@TOAD.COM Subject: virgin key Message-ID: <722650089.8392816@AppleLink.Apple.COM> MIME-Version: 1.0 Content-Type: text/plain Greetings CypherFolk, I'm still in Europe, researching combinations of sleep deprivation and extended train travel, but the time for return to sf.ca.us is drawing closer. I'm still temporarily off the c-punks mail alias due to technical/fiscal reasons so buzz me directly at until January 93. Appended below is my brand-spankin'-new 512-bit public key. Give it a workout so I can see if it works (out). I have an interesting keyring from over here if anyone is interested. Will attend meeting anytime in '93 if I'm notified so we can pass the baton -er- floppy. dave del torto -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQBNAisMWqcAAAECALhs0wMpfVaVFIP/pk3MouI7X8sqpbB6eKiCoVPWBAOeMhB3 bOE8gibIgx5Gg+yTTmp5WOBXzmqmN8s2NPwzoIMABRG0LkRhdmlkIERlbCBUb3J0 byA8ZGVsdG9ydG9AYXBwbGVsaW5rLmFwcGxlLmNvbT4= =cnh0 -----END PGP PUBLIC KEY----- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Wed, 25 Nov 92 01:24:26 PST To: tcmay@netcom.com Subject: Re: Scenario for a Ban on Cash Transactions Message-ID: <199211250923.AA21269@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Tim refers to Brunner's Shockwave Rider as "amazingly prescient." As he says of Brunner's diagnosis, so say I of Brunner's prescription. -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Wed, 25 Nov 92 02:03:52 PST To: cypherpunks@toad.com Subject: Re: Question about the MacPGP Message-ID: <199211251002.AA24840@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain re Tai's item about more user-friendly decryption on the Mac version.... Seems to me we need it for encryption as well... For instance, telecom software which allows you to back out into a screen editor where you write something and then encrypt it, and then get back to telecom and transmit the ciphertext directly. In my use of email, spontaneous mail and replies are vital. Having to go offline, go into WP, compose, go to crypto and encrypt, then go back to telecom, link up again, and transmit.... Holy cow, if that were a prescription for safe sex, it would be "Start a romantic evening. Just when you and your Love are sitting by the fire holding hands, get in the car, go to the drugstore and buy condoms. Then come back to where you've left your Love waiting by the fireplace, and try to get back in the romantic mood. Then before bedtime, walk around the house to make sure all the lights are off and the oven is off and the dog is in and the cat is out. Then retire for the night, and try to get the romantic mood going again, hoping that your Love hasn't fallen asleep while you were making your rounds..." Eee-yow, we can do better than that! -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Tue, 24 Nov 92 23:13:08 PST To: cypherpunks@toad.com (CypherPunks Mailing List) Subject: RS232 Crypto Dongle (idea for widely accessible crypto technology) Message-ID: <9211250712.AA03659@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain A very useful device for people who can not trust the host they are talking to such as users of multiuser unix systems, or low security BBS systems, or "public access" workstations or PC-s, (this includes almost every single person that uses e-mail, except probably for users of a high-security mainframe communications system) would be an RS232 crypto "dongle" that would sit between the terminal (or modem) and the remote system. It would contain some tamperproof (write and decrypt only, can not be read out without a great deal of trouble) memory (as someone at the midnight crypto session at Hackers was talking about) for storage of the private key, some nonvolatile memory (flash eprom?) for the public key ring, and a processor to do the encryption/decryption. It would look (if all that can be fit into a small enough space) like a null modem or a gender changer. (or an RS232 break-out box). If crypto tech ever becomes illegal, it could even be disguised as one, with some special signal combination enabling the crypto function. It should also contain some out-of-band signal such as an LED to indicate that it is actually doing the decryption, instead of the host mimicking it. If introduced now or in near future, this device could become incredibly widespread, since most everybody that is accessing any form of e-mail goes at some point through an RS-232 link (either a terminal hanging off a terminal server, or a PC connected to a modem). Also, it would not require ANY special software on the host or the pc, nor any special terminal. Thus it would work with any of the great variety of e-mail and BBS sysetems that exist, instead of having to deal with each of them individually as a purely software-based approach would have to. It would also be completely independent of the type of computer/terminal or operating system used. You would send the usual mail command to the host, type the magic sequence to the encryption device (or even better, flip a little switch), and then type your message. The device would send to the host the ciphertext, while echoing the plaintext to your terminal so you can see what you are typing. The plaintext would never travel further than the RS232 connection between your terminal and the encryption device. When you receive an encrypted message, flip the switch on your device to "decrypt", and tell the host to send you the message. The host and any intervening networks would only see the ciphertext. The only place the decrypted text appears is on your terminal. I think this is as secure as you can get (until a decryption implant can be put in your head :-). Now, to allow the use of existing tools (pagers, editors, mailers, etc) the device should be completely transparent except when performing the crypto function. Even then, careful design should make it pretty transparent. For example if it passed all control characters intact, it could be used with a text editor that uses control key sequences for movement. It could be programmed for most common arrow key sequences, and for commands for editors such as EMACS, vi, etc, to pass them through unchanged. Same thing for receiving. When decrypting, it should pass through unchanged any characters passing through the other way, and should not interfere with terminal control characters, so any mail viewing program would not be affected. Additional functions it might include are generation and verification of signatures, an echo mode with decrypt/encrypt (so you could store the encrypted texts on your local drive, and to view would just "ascii upload" them to the device while in a comm program; also you could prepare the text of a message locally, while storing the encrypted text echoed back. Then you could upload the cyphertext to the system), a simple local editor and viewer, and anything else we have the ROM space for. Once the basic hardware is developed, there is nothing to stop one from including any desired features. Is anyone here already working on something like this? If not, is anyone interested in working with me on developing this kind of a device? I have the design pretty much thought out (this post is just a summary). I also have a clear picture of the prototyping and development process, and am capable of writing the software part. I would like to work with a partner who knows the hardware part of all this. I.E. the RS232/UART control, PCB layouts, that kind of stuff. Also, I know almost nothing about the technology of tamperproof memory storage. The main objective of this is not to make loads of money (though that would not hurt either) but to increase widespread accessibility and use of good crypto technology. So I would make the schematics and code available, in case anyone wants to be SURE and build one themselves. This could probably also be made available in kit form, that could be assembled by the user. (an interesting parrallel: this is how the personal computer was first distributed... look at the prevalence of PC use today!) This way they can be more sure that it does what it says it does. So, if you have read this far you are probably interested in this. PLEASE reply to me or to the list. If you are the person I am looking for to help with the development, please contact me soon, using one of the addresses or numbers listed in the signature. If you think you would be interested in buying or using such a device when it is ready, please let me know. If you have any improvements to the idea, or other comments, or reasons why you think this device would not be useful or could not work, please let me know too. Waiting for your feedback.... -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Wed, 25 Nov 92 02:21:46 PST To: nobody@alumni.cco.caltech.edu Subject: Re: Extortion Explosion Message-ID: <199211251020.AA26264@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Polyanna's item about crypto-anonymity protecting informants and background sources is most interesting. DEspite my dislike of spying, this idea sounds pretty decent. No invasions of privacy or civil rights are necessarily involved; infiltration is somehow not quite as awful as the spectre of mass surveillance (if nothing else it's labor intensive, which limits its use to substantial cases). And it might just get a lot of results. Might also lead to a lot of whistle-blowing on white collar baddies like the S&L fraudsters. Hey, long before Michael Milliken's name was in the media, I heard about his little fraud scheme from a fellow telecom technician who worked on the PBX in his office and got a whole lot first-hand from casual chat overheard in the office. Consider all the secretaries who know their bosses are cheating, ripping off, and all that. (Consider them dead if their crooked bosses ever go through the hard discs and find fragments of cleartext or even ciphertext hanging about: we need to educate the public on crypto protocol so people don't make dumb errors that may cost them dearly!) -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Tue, 24 Nov 92 23:33:02 PST To: cypherpunks@toad.com Subject: possibility of a reply to an anonymous message In-Reply-To: <9211250508.AA01456@netcom.netcom.com> Message-ID: <9211250732.AA03979@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > (The following message arrive in my mailbox, with a request to repost > it anonymously. Sometimes these "manual" methods work pretty well! If the person is not on the mailing list, please forward this to him/her/it? > lots of other ways to get this function. But the problem is getting > an answer back with out unmasking. This is not difficult at all, it just costs bandwidth. The basic idea is to anonymously post or mail a message, and at the end attach a public key, and the name of a public forum such as a usenet newsgroup. Then whoever wants to reply, will encrypt the message with the public key, and posts to the appropriate newsgroup. No-one but the poster of the original message can decrypt the reply. since everyone receives all the articles in the newsgroup, it is not possible to trace back who decrypted the message. > conjure up a better scheme, but I see the backward security to be > simply a matter of tearing the connection (return path down) faster > than it can be backtraced. It would be nicer if some kind of I would NOT rely on this under any conditions. This could only provide enough security that someone who is NOT interested in you can not trace you. Hey, for that kind of security you could use something like rot13... Anyone that is in the least interested, will immediately investigate the recent traffic at nodes the message went through. > definitely work. With a large number of the forwaring nodes, and > multi-hop paths, it would become quickly very impractical to shake > down the originator, So the return path could be left "up" for Unless someone really wants to. > for a reasonable reply. Better yet of cource would be a completely > uncrackable return path that you could leave up long enough to use > institutional advertising. Eg: run a business from. What I described above can work indefinitely (at least until your private key is compromised) > Another way to leave up long lasting connections (return paths) > is to select one really HARD point node. This is the one they Again, I would not use this approach. Such a node would become the target of concentrated penetration efforts and would break down sooner or later, and probably would remain operational, while logging all data. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Wed, 25 Nov 92 09:08:00 PST To: cypherpunks@toad.com Subject: The Cypherpunks Mail Project In-Reply-To: <199211210833.AA19473@well.sf.ca.us> Message-ID: <9211251705.AA17774@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain I wrote: >[...] there is no one place to push on the mail system to add encryption. Let me explain. You can push on a standard, but that doesn't change any code. If everybody in the world read mail with /bin/mail, then you could rewrite that and add encryption. What certainly is the case, though, is that there are a lot of mail readers out there. It is also the case that the cypherpunks, of all people, should be using encrypted mailers. Otherwise we are hypocrites. Fen advocates MIME, and Ittai concurs. Ittai asks, relating to existing MIME development work: >Do we really want to give them an additional burden -- or do we want >to leverage off work that is already being done? It was my vision of this development that people here on the list would do the work of integration and publish the results. It is also my suspicion that simple PGP decryption support is fairly straightforward, being mostly the ability to run a command on a block and replace the block with the output of the pipe. This model works with regular mail and MIME, since it runs at the very top level of the application. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Wed, 25 Nov 92 06:08:48 PST To: Extropians@gnu.ai.mit.edu Subject: Re: Private E-mail (re: Ban on cash transactions) In-Reply-To: <9211251324.AA15058@wookumz.gnu.ai.mit.edu> Message-ID: <9211251408.AA13799@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > I'm interested, especially if you'd be receptive to adding some > capabilities beyond those you presently have in mind. For more info on Yes, I am open to any suggestions. > these, see October Dr. Dobb's Journal, "What if there is a silver I will definitely get it. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: miron@extropia.wimsey.com (Miron Cuperman) Date: Wed, 25 Nov 92 02:54:15 PST To: cypherpunks@toad.com Subject: Re: How far is to far? In-Reply-To: <199211211022.AA06269@well.sf.ca.us> Message-ID: <1992Nov25.101452.11440@extropia.wimsey.bc.ca> MIME-Version: 1.0 Content-Type: text/plain gg@well.sf.ca.us (George A. Gleason) writes: >Miron writes, >"Charge for the mix services with crypto money. The crypto money could be >some networking service..." >Only problem is, once we start anything like a formal barter system, it >comes under the IRS. The way to avoid that is to keep it a volunteer How do you think the IRS is going to trace those banks and customers behind all the anon mixes? -- Miron Cuperman | NeXTmail/mime ok | Public key avail AMIX: MCuperman | immortalcybercomputinglaissezfaire | From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eli Brandt Date: Wed, 25 Nov 92 10:30:40 PST To: cypherpunks@toad.com Subject: PGP on local machine (was Re: MacPGP) In-Reply-To: <199211251002.AA24840@well.sf.ca.us> Message-ID: <9211251830.AA13482@toad.com> MIME-Version: 1.0 Content-Type: text/plain > From: George A. Gleason > Seems to me we need it for encryption as well... For instance, telecom > software which allows you to back out into a screen editor where you write > something and then encrypt it, and then get back to telecom and transmit the > ciphertext directly. The following would require customization on both ends, but seems doable: You compose the message, using emacs or some other Turing-complete editor. You hit the "PGPify" key [sequence]. emacs echoes a special START string The local comm program recognizes it and goes into "capture" mode. emacs blats the plaintext to stdout, where it is captured. emacs echoes a STOP string. The comm program sees this, stops capturing, shells to DOS, and runs PGP. emacs kills the original text block. (emacs command ends) The comm program shoves the cyphertext into the upload stream. (comm macro reverts to lurk mode) You send the message. All of this, I think, could be implemented with available programs. Kermit won't hack it on the local end, so maybe I'll switch to Telemate. This protocol would require a clean line or EC modem; is this a problem? It might be a better move to write a [shell, Perl] script that's a drop-in replacement for Unix pgp: it goes through the whole protocol above, and looks to the outside world as if it had done the work itself. People have written emacs macros (I think) to make this work with mail; it could also be used as a unix-pgp replacement in other places. It might be nice if the plaintext were not echoed to the screen while being transferred, too. Eli ebrandt@jarthur.claremont.edu From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Wed, 25 Nov 92 11:08:14 PST To: Extropians@gnu.ai.mit.edu Subject: Re: Scenario for a Ban on Cash Transactions In-Reply-To: <9211251553.AA15780@wookumz.gnu.ai.mit.edu> Message-ID: <9211251903.AA05946@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain In his usual fashion, Duncan Frissell has cogently made some arguments as to why my scenario for a cashless society won't happen. I hope he's right, but I doubt it. Since many of his comments are relevant to the parallel discussion going on in the "Cypherpunks" list, I'm cc:ing that list. Duncan Frissell writes (from Britain): > Why we won't have a cashless society - > > 1) 60% of US personal transactions (by number not value) are still in cash. But here in the States nearly everyone has either a credit card or an ATM card. Most supermarkets now take plastic...ATM/credit card readers are installed in the checkout lanes. The clerks tell me they actually prefer the plastic, as so little work is needed. (Much faster than checks, which most people not using plastic use). This installed base of card readers already covers about 80% of all common transactions, I would estimate. > 2) Bribe income of the rulers would be affected. A good point, also made by Keith Henson (in e-mail). Politicians want cash for off-the-record transactions, their sexual liaisons, etc. Maybe the corruption of politicians will be our salvation! (More likely: exemptions...Congress exempts itself from many laws. Also, the various onerous financial disclosure laws directly affect politicians, and they made it into law.) > 3) The illiterate, the retarded, and those with poor management skills depend > on a cash accounting system to run their lives. They would not be able > to survive in a card-based economy. 20% of the US pop. have no checking > accounts and 40% have no plastic. I notice plenty of semi-literate folks handing their plastic to the cashier! Those without checking accounts tend to use "money orders," though, so mandating a conversion would be possible. Many of those without checking or plastic accounts simply don't "qualify." (Trend: qualification standards have been dropping every year) A government-run credit/debit card program would ensure that everyone got a card. Illiteracy is no problem, as there is virtually nothing to read or write when using plastic. (Adding voice synthesis to some of the card readers would even be seen as a selling point with the blind or physically disabled.) > 4) The destruction of the Underground Economy would be socially regressive > since it would fall most heavily on the poor. Poor households spend twice > their reported income. Possibly true, but this won't cut the mustard when it comes to passing the laws. The laws will be presented as a way to "close the loopholes" on the rich, not to soak the poor. The talk of a "welfare credit card" to deal with the theft of welfare and social security checks (a big problem in the U.S., obviously affecting mostly the poor) will likely result in some form of government-mandated card system in the next couple of years. > 5) The destruction of the Underground Economy would hurt the Gross Domestic > Product and cause recession. Probably not a concern to the planners, but perhaps. It is not politically correct to talk about this. > 6) Foreigners need to be able to participate in the system. Unless *all* > nations jointly go to an electronic payments system, there will be loopholes > that domestic residents can exploit. But foreigners already have to comply with U.S. banking laws (though of course they often don't, but that's another story). Foreigners planning to convert pounds or francs to cash dollars would simply convert them to electronic dollars, "charging" up their debit/credit/etc. card. (As a parallel, the law from 1933 to 1976 or so was that Americans could not possess gold in any form except jewelry or rare coins. Other countries had no such laws. Did we see British visitors flouting the laws by spending gold guineas?) > 7) As long as foreign practices differ, domestic residents could get overseas > Visa debit cards and ATM cards and avoid the domestic social controls. This could be a real stopper. Perhaps the U.S. and its New World Order will push for a nearly simultaneous conversion, as part of the GATT talks, the various monetary talks, etc. Also, using foreign-based cards could simply be declared illegal. Tie-ins to Immigration and Passport control could allow foreign visitors to use their foreing cards for, say, 90 days, or whatever....this would also be a way to control illegal immigrants who overstay their temporary visa. The cleanest solution would be to tie a "tempory visa" to a "temporary VISA" (pun intended), in which a visitor would receive a card upon arrival, just as he now changes his francs and marks for dollars. > 8) The vast majority of the world's population is still in a cash or barter > economy and could not be converted to plastic. This would leave overseas > cash that would be a system loophole. See above. > 9) There is now no central financial authority. Electronic payments are > transmitted to the payor banks by various networks and the banks themselves > authorize payment. A central authority would be expensive and technically > challenging. Ah, but these clearinghouses are becoming more tightly integrated. A VISA transactions costs about $0.10, and this is dropping yearly. A typical transaction can be sent out over phone lines in seconds and over high-speed ISDN lines in fractions of a second. Fiber optic lines make it ridiculously easy. Besides, it it not necessarily the case that there would be one central authority which would validate transactions (that would be too vulnerable to single-point failures and sabotage). Transactions would mostly be similar to today's transactions, with records sent periodically to the government(s). > 10)A central financial authority would exceed the institutional abilities of > current international arrangements, would be opposed by the banks (cost and > independence), would constrain the growth of the financial services industry > and would run counter to the trend of financial deregulation. Here in the U.S. the banks have acquiesced to nearly all of the onerous new reporting regulations (cash transactions over $10,000--soon to be less--and disclosure laws) resulting from the War on Drugs. Banks are now creatures of the government, jumping when told to. Also, when the various laws are seen as _profit sources_ (as in the FBI's Digital Telephony Bill, which would compensate phone companies for tapping customers) then banks will be happy to add a service charge to cover their expenses. Furthermore, and this goes to your point below as well, banks will push for legislation that forces theri competitors to do exactly the same as they are doing. There are virtually no new banks appearing in the U.S....they want a nice, safe, profitable world, not competition. Forcing all transactions to go through them would fit their fondest desires. > 11)The Iron Law of Regulation. Regulations create profits for their avoidance > and eventually break down as people take advantage of those profit > opportunities. Financial deregulation throughout the world in '80s was > *not* caused by a decision of governments to give up power. Deregulation > was an acknowledgment that old controls were dead. Banks are suffering as new alternatives have appeared. Hence the talk fo repealing the Glass-Steagall Act. Banks may see a cashless system as their way to get back into the center of things. > 12)Networks were originally thought to be centralizing. In practice they have > proven to be decentralizing. How many machines/people access Internet? Who > has central control over Internet? The Internet may be physically decentralized, but logically it is very centralized, in the sense that all messages to newgroups appear in one very large feed, albeit sent out in pieces. That is, everybody in the world is basically seeing the same "sci.crypt" group. More to the point, the credit card clearinghouses are amazing centralized (logically, if not physically...and a friend of mine who consults for VISA headquarters--located in the Bay Area--says nearly all VISA transactions flow into their facilities). I can access my credit card balances nearly anyplace in the world. How's that for centralization? > 13)An encrypted, anonymous, zero-knowledge-proof-credentialed market could be > conducted without reference to an external government-controlled payment > system. Here we agree, completely. This is my hope. If we can deploy our ideas quickly enough, the scenario I describe may be headed off. > These are just a few of the problems to be overcome. A change that massive > would upset so many apple carts in the US and abroad that I don't think it is > much of a risk. > > Duncan Frissell Thank you, Duncan, for your incisive comments, even though I disputed most of them. This is an important debate, a lot more important, I think, than debates on the rights of Martians and owls. (No offense to Extropians intended!) Our future is at stake. --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Hal <74076.1041@CompuServe.COM> Date: Wed, 25 Nov 92 09:17:58 PST Subject: Remailers... Message-ID: <921125165126_74076.1041_DHJ12-1@CompuServe.COM> MIME-Version: 1.0 Content-Type: text/plain I think the remailing idea expressed via Tim (from David?) had some nice features. It would be very easy to do replies to someone whom you didn't know but from whom you'd received some anonymous mail. As I understand it, if I send mail anonymously to David, he won't (of course) know who sent it. If he replies, the mail will bounce back to the forwarder. And the forwarder has remembered my forwarding request so that it can send the reply back to me. After that it deletes the remembered forwarding request for security. I wouldn't object to this that much on security grounds; as David pointed out, even a full implementation of Chaum's "mix" remailer would fall to infiltration. Instead, I think there are some issues involving usability. For one thing, it sounds like this system is use-once as far as the anonymous return address. If David replied to me, then thought of something he wanted to add, his second message wouldn't get through to me. Another problem is, what if two people send anonymous mail to David via the same forwarder. Then, when he replies, how does the forwarder know which of the two to forward the reply to? It's also asymmetric, in that it will only work if one of the two communicants knows the true address of the other. A lot of the interesting features of Tim's "crypto anarchy" only arise if people can communicate without either one knowing the other's true address. Let me mention a couple of other ideas which I've heard of for anonymous return addresses. One idea was posted several months ago on the Extropians list by Eric Messick. (Is he on this list?) It used a "pseudonym-based post office box". You would send a message to a remailing server saying, "Please save mail addressed to pseudonym XYZ123. I will pick it up later. Here is the public key I will use to authorize the pick-up, and here is some digital cash to pay for your trouble. Thank you." Then you send mail anonymously giving XYZ123@remailer.com as your return address. This mail stacks up at the remailer which saves it for you. At some later date you send a signed message to the remailer saying, "OK, send XYZ123's mail to me@me.com." Eric Hughes had an idea which was somewhat like this but without the delay aspect. You would just set up an account with a remailer whereby all mail to XYZ123 would be forwarded to yourself. Then XYZ123@remailer.com would be your return address. This could include David's idea if you asked the server to delete your pseudonym after using it once. All of these anonymous return address proposals can be enhanced by using a cascade or chain of remailers for your A.R.A. Chaum's "mix" remailer would save up a batch of cryptographically protected messages, decrypt them, rearrange their order randomly, then send them out. This way if the remailer itself is secure but the network connections to it are being monitored, the correspondance between incoming and outgoing messages is lost. The other ARA suggestions could also benefit from this enhancement. Chaum's idea for an anonymous return address was a somewhat more complicated form of the ARA I've implemented for my remailer. My ARA is simply a forwarding instruction, encrypted with the public key of the remailer. The advantage of this system is that you don't have to "register" with the remailer(s) in advance. It's less convenient than the other proposals, though, and there is the danger that the public key(s) of the remailer(s) involved would be revealed at some time in the future, which would then reveal that that old ARA really was you. Hal 74076.1041@compuserve.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: ghsvax!hal@uunet.UU.NET (Hal Finney) Date: Wed, 25 Nov 92 13:04:57 PST To: cypherpunks@toad.com Subject: Electronic Banking Message-ID: <9211251953.AA01487@nano.noname> MIME-Version: 1.0 Content-Type: text/plain Some time back Tim May suggested that we should do some experiments with electronic cash. He offered to do some Xeroxing if people would "pay" him. There are lots of proposals for electronic cash in the literature, mostly very complex. I think one of Chaum's simpler proposals would be adequate for email "banking". This proposal, from the beginning of his paper "Untraceable Electronic Cash" in Crypto 88(?), goes like this: 1. Alice chooses a random x and r, and supplies the bank with B=r^3*f(x) mod n, where f is a one-way function (like MD5), and n is the modulus for the bank's public key. 2. The bank takes the third root of B (e.g. via an RSA decryption) and sends it back to Alice: D = r * f(x)^(1/3), and withdraws one dollar from her account. 3. Alice extracts C = f(x)^(1/3) by dividing D by r. (Note that division can be done mod n without knowing the factors of n, but it's rather complicated.) 4. To pay Bob one dollar, Alice gives him (x, C). 5. Bob can verify that C = f(x)^(1/3), but he still has to send (x, C) to the bank in order to make sure that x hasn't been used before. Otherwise Alice could spend (x, C) twice. The bank increases Bob's account by one dollar. This scheme is pretty simple and provides untraceability - the bank saw B and D but not C, so although it can verify that (x, C) is legit, it can't correlate that with Alice's withdrawal. The main disadvantage of this approach is that Bob has to send (x, C) to the bank right away (or at least before sending Alice anything in return for her cash) to verify that the cash hasn't been used before. But in email, where turnarounds of a day or more aren't unusual, this should be tolerable. Alice and Bob could be pseudonyms, using anonymous addresses to communicate with each other and with the bank. Different denominations of cash could correspond to different exponents than "3" in the example above. (That is, $1 would use C=f(x)^(1/3), $2 would use C=f(x)^(1/5), $4 would use C=f(x)^(1/7), and so on.) Technically, this would be quite easy to implement, using the code in PGP for the arithmetic, and MD5 for the one-way function. We'd need to define a few message formats. The RFC1113 ascii encoding from PGP could be used as well. The "social" problems are more challenging, it seems to me. What is the backing for this electronic money? Why do people care what their bank balances are? Is this stuff really worth anything? One possibility is to base digital cash on real money. People would open a pseudonymous account via email, then postal-mail dollars to the bank, enclosing their account number so the bank would know whom to credit with the deposit. Later, if someone wanted to withdraw "real money" from their account they would have to give a real postal address where it could be mailed. Now the electronic money is worth real dollars. Even if people didn't deposit or withdraw very often, it still has value because of the backing. Unfortunately, this approach would currently be illegal (at least, unless you actually were a real bank!). If there were some way the bank itself could be anonymous, it might survive, but I don't see how to mail it money while keeping the anonymity. Still, we could consider experimenting with this on a small scale with accounts of no more than a few dollars. As long as it was clearly an experiment I doubt that any prosecutions would result even if it attracted government attention, because the expense involved in court costs would be so disproportionate to the few dollars involved in this technically illegal act. Another approach would be not to try backing the digital cash at all, or rather backing it implicitly by the determination of various people to accept it and perform services or supply goods in return for it. Tim's offer to Xerox papers in return for digital cash would be one example. Perhaps others could provide some other services. It would be great if some shareware author would accept digital cash as a symbol of support for crypto anonymity. One problem that I see with this approach is how you determine the size of the money supply. Or, in other words, how does new digital cash get started circulating? How do people get new accounts, and how much money is in them? If these problems can be solved, a big advantage of this approach is that the banker can be anonymous. He would be known only by his anonymous address and his public key(s). This would provide some safety in the event that even a small-scale experiment like this was targetted for a crackdown. Another issue is the prospect of multiple "banks", each issuing their own (incompatible) cash. How would they compete? Perhaps in terms of rapid turnaround? Some might choose to be anonymous, others would go public. The latter would have the advantage that people might trust them more, but OTOH there is more chance of your bank account disappearing after a crackdown for a public bank than an anonymous one. Lots to think about here! Hal 74076.1041@compuserve.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Peter Shipley Date: Wed, 25 Nov 92 12:30:56 PST To: cypherpunks@toad.com Subject: Re: An easy-to-reply anonymous mail scheme In-Reply-To: <9211251835.AA23411@novavax.nova.edu> Message-ID: <9211252030.AA24576@edev0.TFS> MIME-Version: 1.0 Content-Type: text/plain > >So to use this, you would generate a public/private key pair, and compute the >hash function of the public part. Anonymously post the public key to >alt.key.announce, and then send your message by whatever means you like (anon >mail, anon post to a regular newsgroup, anything) using reply.HASH@remailer.com >as your return address. Then watch alt.w.a.s.t.e for replies and decrypt >as received... one problem is that pgp labels public/private key pairs with strings (thus I have to create a public/private key pair with a unique label string that has nothing to do with my name) the problem still exists that every message posted to alt.w.a.s.t.e with have my pgp key label string. pgp does not support unlabeled crypted test (eg: I can had it random cyphertext and have it figure out public/private key pair to use (by trying every key in my rings)( From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: fnerd@smds.com (FutureNerd Steve Witham) Date: Wed, 25 Nov 92 09:17:33 PST To: cypherpunks@toad.com Subject: Re: Random Numbers Boxes and Cypher Processers Message-ID: <9211251629.AB05506@smds.com> MIME-Version: 1.0 Content-Type: text/plain >Why do encryption in the modem instead of the host cpu? A point that hasn't been made painfully clear yet: "DSP--Digital Signal Processor" chips are really just fast processors for repetitious arithmetic--just what RSA needs. Maybe some experience in programming them for that sort of purpose would be useful. -fnerd fnerd@smds.com (FutureNerd Steve Witham) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: rfm@Eng.Sun.COM (Richard McAllister) Date: Wed, 25 Nov 92 13:09:10 PST To: libernet@dartmouth.edu Subject: Re: SF Bay Area Parties Message-ID: <9211252108.AA05130@urth.Eng.Sun.COM> MIME-Version: 1.0 Content-Type: text/plain Edgar Swank wrote: > Cypherpunks, > Extropians Libernet > Since all the above groups, of which I am a member, are not known > for sponsoring social functions, I suggest we co-opt the Pen SFA > parties. Their latest "Winnie" newsletter is attached. Please note > and follow "rules". I especially recommend the 12/26 party. ... Interested people are definitely invited to attend PenSFA parties (though not to "co-opt" them..), but we prefer not to post the meeting notices to random mailing lists since they include hosts' addresses and phones. [Edgar didn't know this because I failed to tell him; my fault, not his.] But please don't forward the whole Winnie on to other lists. (Especially, don't post it to USENET...) If you'd like more information on PenSFA, email me, I have a information handout to give you; also email me to get on the list for more announcements. Rich (rfm@eng.sun.com) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Wed, 25 Nov 92 10:36:01 PST To: anon.list@pax.tpa.com.AU Subject: An easy-to-reply anonymous mail scheme In-Reply-To: <199211251815.AA16797@buila.NSD.3Com.COM> Message-ID: <9211251835.AA23411@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > >is this: Just include a public key in your post. And ask any repliers to > >post to the newsgroup, encrypted with that key. No-one else but you can > >decrypt the reply, and no-one can know that you did, since everyone receives > > all of my own and everybody elses schemes is that it requires an INVOLVED > replier. I need some way that I can send out an anonymous email, and have > the receiver of that email just hit "r" to reply to me. If they have Ok, if that is what you want, then the following procedure will let you do exactly that: post anonymously, with a reply address that people can just 'r' to. And no-one (not even the host that is handling the replies) has to know who you are. There exists a site, lets call it remailer.com. It watches the newsgroup alt.key.announce for messages with the "Subject: remailer public key notice" that contain a public key. It takes each public key, and perofmrs some sort of hash function on it, tcreate a short "key id". (note: the hash function must be cryptographically strong, i.e. it should be very difficult to construct another key with the same hash value). It stores hash and the key in a database. Then whenever it receives a mail message to reply.HASH (where HASH is the key id), it encrypts the message with the associated public key, destroys the plaintext message, and posts the ciphertext to alt.w.a.s.t.e. So to use this, you would generate a public/private key pair, and compute the hash function of the public part. Anonymously post the public key to alt.key.announce, and then send your message by whatever means you like (anon mail, anon post to a regular newsgroup, anything) using reply.HASH@remailer.com as your return address. Then watch alt.w.a.s.t.e for replies and decrypt as received... All the recipient(s) have to do is press 'r' key and type the answer. You are guaranteed anonymity because no-one can find out who decrypted the alt.w.a.s.t.e message, since everyone received it. All you need is a good way to anonymously post to a newsgroup. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Wed, 25 Nov 92 10:41:46 PST To: anon.list@pax.tpa.com.AU Subject: Re: anonymous reply In-Reply-To: <199211251829.AA27022@johanna4.hsr.no> Message-ID: <9211251841.AA23551@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > > replier. I need some way that I can send out an anonymous email, and have > > the receiver of that email just hit "r" to reply to me. If they have > Here is an example of how to use the cryptographic remailer at > to implement an anonymous return address. > But the again do you trust hal@alumni.caltech.edu... With conventional remailer schemes such as this one, you are announcing your True Name (or at least your True Internet Mailbox) to someone you must trust. With my scheme (posted earlier today) you don't need to trust anybody except yourself (to not make a dumb mistake like including a signature). -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Wed, 25 Nov 92 14:23:18 PST To: cypherpunks@toad.com Subject: Re: Electronic Banking In-Reply-To: <9211251953.AA01487@nano.noname> Message-ID: <9211252219.AA00550@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Hal Finney makes some very good points about anonymous banking and some experiments we may try in the near future. (First let me dispose of a minor item.) > Some time back Tim May suggested that we should do some experiments > with electronic cash. He offered to do some Xeroxing if people would > "pay" him. (A minor note: I ended up doing the Xeroxing for free, which hasn't yet been declared illegal...though I presume you'll all carefully note this on your tax returns, as such "barter exchanges" are reportable income. In theory, which shows how hopeless tax collection is becoming, all of our "mutual consulting" on this list, and on the Net in general, is _taxable income_--just as if we were plumbers and carpenters getting together to work on each other's houses. A crazy system.) Back to the important stuff. Hal continues: > There are lots of proposals for electronic cash in the literature, > mostly very complex. I think one of Chaum's simpler proposals would be > adequate for email "banking". This proposal, from the beginning of > his paper "Untraceable Electronic Cash" in Crypto 88(?), goes like > this: (Hal's excellent summary of Chaum's system elided) > Technically, this would be quite easy to implement, using the code in > PGP for the arithmetic, and MD5 for the one-way function. We'd need > to define a few message formats. The RFC1113 ascii encoding from PGP > could be used as well. This sounds great! (But I worry that the handful of you already doing the programming of PGP, new versions, MacPGP, remailers, etc., will get overloaded and/or burned out. I'd offer to help, but my programming these days is limited to fiddling with Mathematica and a little bit of Smalltalk and Scheme/LISP.) > The "social" problems are more challenging, it seems to me. What is > the backing for this electronic money? Why do people care what their > bank balances are? Is this stuff really worth anything? And the lesson we learned from PGP 2.0 is that actually getting _something_ out there for people to play around with is crucial. Getting "PGDC" ("Pretty Good Digital Cash") in use will be a harder sell than PGP deployment was, because most people don't understand the ideas, see no real pressing need, and can't do much in any case without an "economy" of users. I've long thought that a "Black Market AMIX" would be one such use, but I won't get into that here. > One possibility is to base digital cash on real money. People would > open a pseudonymous account via email, then postal-mail dollars to the > bank, enclosing their account number so the bank would know whom to > credit with the deposit. Later, if someone wanted to withdraw "real > money" from their account they would have to give a real postal > address where it could be mailed. Now the electronic money is worth > real dollars. Even if people didn't deposit or withdraw very often, > it still has value because of the backing. > > Unfortunately, this approach would currently be illegal (at least, > unless you actually were a real bank!). If there were some way the > bank itself could be anonymous, it might survive, but I don't see how > to mail it money while keeping the anonymity. Still, we could > consider experimenting with this on a small scale with accounts of no > more than a few dollars. As long as it was clearly an experiment I > doubt that any prosecutions would result even if it attracted > government attention, because the expense involved in court costs > would be so disproportionate to the few dollars involved in this > technically illegal act. Warning! Recently, a bunch of bowlers (women, no less) were busted for illegal gambling because of their "pot" they were bowling for. After much public outcry and laughter at the authorities, the charges were either dropped or reduced. I mention this because casual bowlers evoke sympathy, hackers and cypherpunks do not. > One problem that I see with this approach is how you determine the > size of the money supply. Or, in other words, how does new digital > cash get started circulating? How do people get new accounts, and how > much money is in them? We're in new territory here. The start of a new kind of economy. Lots of experimentation and trial and error work will be needed. > If these problems can be solved, a big advantage of this approach is > that the banker can be anonymous. He would be known only by his > anonymous address and his public key(s). This would provide some > safety in the event that even a small-scale experiment like this > was targetted for a crackdown. Yes. And also anonymous "escrow services" which are like banks but which serve other functions, such as holding the money in a transaction so that Alice cannot take the money from Bob and refuse to deliver on her side of the deal. All of these entities must be "pseudonymous" (a clumsy word), in that digital pseudonyms are supported (a la the work of Hughes, Finney, and Janek Martinson) and True Names cannot be traced. > Another issue is the prospect of multiple "banks", each issuing their > own (incompatible) cash. How would they compete? Perhaps in terms of > rapid turnaround? Some might choose to be anonymous, others would go > public. The latter would have the advantage that people might trust > them more, but OTOH there is more chance of your bank account > disappearing after a crackdown for a public bank than an anonymous > one. Banks, escrow services, etc. will all have "reputations" and credit ratings (from crypto versions of Standard and Poors, themselves operating only as a pseudonym!). All of this will evolve over time. > Lots to think about here! > > Hal That's for sure. Incredibly good points being made by everyone! --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: karn@qualcomm.com (Phil Karn) Date: Wed, 25 Nov 92 15:38:09 PST To: yanek@novavax.nova.edu Subject: Re: RS232 Crypto Dongle (idea for widely accessible crypto technology) Message-ID: <9211252337.AA01494@servo> MIME-Version: 1.0 Content-Type: text/plain I've also been thinking about the risks of running crypto software on hackable PCs and ways of protecting against this with external special purpose devices. My thinking is to limit the external "dongle" to the one function that is truly sensitive and worthy of special protection: RSA secret key operations. It seems to me that whenever you use a PC to encrypt or decrypt something, you have to accept the risk that it might have been hacked, and whatever you do on it might be secretly recorded. But when I now run PGP (or any similar package) on a machine, I must risk much more than this every single time I type in my pass phrase, namely *everything* that ever was or will ever be encrypted with this same RSA key pair. This may well be an unacceptable risk, especially if I'm temporarily borrowing somebody else's machine or using one in a public area. I see this as THE major obstacle to our goal of routinely encrypting all communications, sensitive or otherwise, as a way of "desensitizing" the world to the use of cryptography. The way around this risk is to move the RSA secret key storage and processing operations to some external dongle. The device would have only one primary function -- the execution of an RSA secret key operation. It would not allow the secret key to be read out of the device, although it might have a "zeroize" function to destroy it. (It might also include a good random number generator for the convenience of the host computer.) Everything else (data compression and armoring, public key operations, symmetric cryptography, etc) can and should go in the PC where cycles and memory space are much more plentiful. If the dongle has a built-in keypad, then it could store your RSA secret key encrypted with a PIN that you'd have to enter to enable the device. This would protect you if the device were stolen. Of course, the best protection is to make the device so small that you can conveniently keep it with you at all times instead of having to store it someplace. I believe that "smart cards" are already available on the market that do these or similar functions, although they are much more widespread in Europe than in the US. Comments? Phil From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Wed, 25 Nov 92 12:44:36 PST To: shipley@tfs.COM (Peter Shipley) Subject: Re: An easy-to-reply anonymous mail scheme In-Reply-To: <9211252030.AA24576@edev0.TFS> Message-ID: <9211252044.AA28256@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > >as your return address. Then watch alt.w.a.s.t.e for replies and decrypt > > one problem is that pgp labels public/private key pairs with strings > (thus I have to create a public/private key pair with a unique label string > that has nothing to do with my name) the problem still exists that > every message posted to alt.w.a.s.t.e with have my pgp key label string. This is not a problem at all. For every anonymous "identity" you want to maintain, you would have a key pair (public/private). The "label" part could contain anything you want, or nothing at all (a space, or a dash, or the word "anonymous") but it would be more convenient if you assigned a pseudonym. > pgp does not support unlabeled crypted test Just because (current version of) pgp does not support something does not mean it can not be done. > (eg: I can had it random cyphertext and have it figure out public/private > key pair to use (by trying every key in my rings) This would be a waste of time, and possibly imprctical if you have any significant number of keys. You should not have to try each key, because the post would contain in the Subject field the hash value of the public key, and using that you could instantly identify which private key to use. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Wed, 25 Nov 92 15:49:42 PST To: cypherpunks@toad.com Subject: RS232 Crypto Dongle (idea for widely accessible crypto technology) In-Reply-To: <9211250712.AA03659@novavax.nova.edu> Message-ID: <9211252349.AA13510@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Yanek writes: >Also, it would not require ANY special software on the host or the >pc, nor any special terminal. [A magical kingdom of compatibility is >described.] In practice, it will be impossible to make a device that does anything transparently. Software has to be rewritten and redesigned around crypto security. It is wise not to underestimate or overestimate the difficulty of doing this. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: ghsvax!hal@uunet.UU.NET (Hal Finney) Date: Wed, 25 Nov 92 16:07:41 PST To: cypherpunks@toad.com Subject: Re: An easy-to-reply anonymous mail scheme Message-ID: <9211252352.AA01919@nano.noname> MIME-Version: 1.0 Content-Type: text/plain The problem with the idea of posting anonymous mail to a newsgroup is sheer volume. Remember, we aim at a system where a large fraction of mail is potentially being done this way. Imagine if almost all email was done today by posting to newsgroups! There is probably thousands of times as much email traffic as news traffic now. It would totally swamp the system. You'd literally have to send every email message sent by any user in the world to _every_ user in the world, in effect. As Yanek says: > You are guaranteed anonymity because no-one can find out who decrypted > the alt.w.a.s.t.e message, since everyone received it. This really won't scale to large numbers of users. Yanek also writes: > > Here is an example of how to use the cryptographic remailer at > > to implement an anonymous return address. > > > But the again do you trust hal@alumni.caltech.edu... > > With conventional remailer schemes such as this one, you are announcing > your True Name (or at least your True Internet Mailbox) to someone you > must trust. With my scheme (posted earlier today) you don't need to trust > anybody except yourself (to not make a dumb mistake like including a > signature). This is why you would want to use a chain of remailers as your return address, what Chaum calls a "cascade". No single remailer sees the correspondance between your anonymous address and your real address. Only by breaking all of them can the bad guys find out who you are. Ideally, remailers would operate in a variety of countries with different laws, making it difficult to crack them all. Remailers could be designed to periodically flush themselves, deleting old keys and/or pseudonym maps. This way anonymous addresses would have a limited lifetime if desired, and the attackers would have only a finite time window to break all the remailers involved. (Different keys/pseudonyms could have different lifetimes as needed.) We could also imagine that there are lots of remailers - not just dozens, or hundreds, but millions of them. Maybe almost everyone runs a "cheap" remailer on the side, collecting a few cents in digital cash for each message they pass, enough to pay for their own messages. Putting all this together, you could have an anonymous address which passes through, say, 10 remailers which might be any of the millions of remailers in the world. It could have a limited lifetime of only a few hours for some ultra-sensitive applications, with the remailers involved flushing their databases after that time. To break this, the enemy would have to sequentially break into machines all over the world, one after another, defeat any physical barriers (locks, men with guns), overcome tamper-resistance in the computers, break the encrypted files, and find out what the next step is in the address cascade, all in a couple of hours. This doesn't seem possible. Hal 74076.1041@compuserve.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: gnu@cygnus.com Date: Wed, 25 Nov 92 15:55:15 PST To: submit@eff.org Subject: The age of the engineers... Message-ID: <9211252354.AA12510@cygnus.com> MIME-Version: 1.0 Content-Type: text/plain ------- Forwarded Message To: junk Subject: quotd Date: Wed, 25 Nov 92 14:12:06 -0800 From: ambar@cygnus.com - ------- Forwarded Message Date: Wed, 25 Nov 92 17:06:28 EST From: CyberBunny This is not the age of pamphleteers. It is the age of the engineers. The spark-gap is mightier than the pen. Democracy will not be salvaged by men who talk fluently, debate forcefully and quote aptly. Lancelot Hogben Science for the Citizen (1938) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Wed, 25 Nov 92 15:58:26 PST To: miron@extropia.wimsey.com Subject: How far is to far? In-Reply-To: <1992Nov25.101452.11440@extropia.wimsey.bc.ca> Message-ID: <9211252357.AA13991@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Miron writes: >How do you think the IRS is going to trace those banks and customers >behind all the anon mixes? Easy. This one, though, is not in the crypto literature to my knowledge. Attack by regulation. Not, mind you, that it will be enforceable without a bn on cryptography in general. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: gnu@cygnus.com Date: Wed, 25 Nov 92 15:58:50 PST To: gnu@cygnus.com Subject: Re: Electronic Banking In-Reply-To: <9211252219.AA00550@netcom.netcom.com> Message-ID: <9211252358.AA12549@cygnus.com> MIME-Version: 1.0 Content-Type: text/plain > > Unfortunately, this approach would currently be illegal (at least, > > unless you actually were a real bank!). Please point out the law(s) that make it illegal. Speculation is fine, but let's do some informed speculation. John From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: ghsvax!hal@uunet.UU.NET (Hal Finney) Date: Wed, 25 Nov 92 16:25:25 PST To: cypherpunks@toad.com Subject: Unlabelled PGP messages Message-ID: <9211260016.AA01923@nano.noname> MIME-Version: 1.0 Content-Type: text/plain Peter Shipley points out that PGP messages are labelled with an identifier of the person they are sent to. This hurts the anonymity of the messages somewhat. What PGP actually puts in the cleartext message header is the "Key ID" of the recipient. This is the low-order 64 bits of the RSA modulus "n" of his key. (PGP displays only the low-order 24 bits when it shows key ID's, but it keeps 64 bits internally.) I understand that there was some discussion during the development of PGP 2.0 of having a mode where this wouldn't be done. One possibility would be to output a key ID of all zeros for a message which wanted to hide who it was for. Then, as Peter suggests, it would either be trial-decrypted by all of the secret keys you have, or, more simply, it would just try your "default" secret key. Most people only have one secret key so both methods would be the same in most cases. Doing it the second way would be a pretty easy patch to PGP. I'm not so sure now that this feature is that helpful. First, you don't have to put your real name in the "user name" field. You could use a pseudonym. So you really don't have to give much information away about yourself the way it is now. Also, if someone is sending a message to you using encrypting remailers, they would encrypt it using your key, add remailing instructions for the last remailer in the chain, encrypt that using that remailer's keys, add remailing instructions for the next-to-last remailer, encrypt it again, and so on. (This would be done automatically by some future software - you wouldn't want to do this by hand!) The result is that the mail you send does not expose the key ID of your recipient. That information is only revealed when it comes out of the last remailer in the chain. And by that time, it's no secret, since that last remailer is using the true email address of the recipient anyway. So it's not giving anything away. For the other kind of anonymous messaging, where you just post to a newsgroup or use some other kind of "broadcast" system, the key ID is revealed and for this case it might be better to hide it. But, the key ID can be useful in this application by letting you know which messages you should decrypt. No one has to know that a particular key ID is "you". You can still download 1000 messages and only read yours without anyone knowing which ones you read. But with key ID hidden you would have to decrypt them all to see which are yours. Do you want to decrypt all 1000? This will take minutes, hours, or days, depending on your key size and computer speed. (Most of the decrypt time is spent doing the RSA step, at least for most messages, and you can't tell if it's for you without doing that step.) This still might be a good idea, but I'm not sure... Hal Finney 74076.1041@compuserve.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: "DrZaphod" Date: Wed, 25 Nov 92 17:59:06 PST To: cypherpunks@toad.com Subject: RE: PGP on local machine (was Re: MacPGP) Message-ID: <58809.drzaphod@ncselxsi> MIME-Version: 1.0 Content-Type: text/plain In Message Wed, 25 Nov 92 10:30:09 PST, Eli Brandt writes: >You compose the message, using emacs or some other Turing-complete editor. >You hit the "PGPify" key [sequence]. >emacs echoes a special START string >The local comm program recognizes it and goes into "capture" mode. >emacs blats the plaintext to stdout, where it is captured. >emacs echoes a STOP string. >The comm program sees this, stops capturing, shells to DOS, and runs PGP. >emacs kills the original text block. >(emacs command ends) >The comm program shoves the cyphertext into the uploadt editor to write your messages then you've just lost the whole reason for encryption. TTFN! DrZaphod [AC/DC] / [DnA][HP] [drzaphod@ncselxsi.uucp] Technicolorized From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Wed, 25 Nov 92 16:30:25 PST To: cypherpunks@toad.com Subject: RS232 Crypto Dongle (idea for widely accessible crypto technology) In-Reply-To: <9211252337.AA01494@servo> Message-ID: <9211260030.AA17523@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Phil K. writes: >My thinking is to limit the external "dongle" to the one function that >is truly sensitive and worthy of special protection: RSA secret key >operations. Phil's comment are right on. There is a need for you secret keys to be easily and physically relocatable. Re: key compromise >I see this as THE major obstacle to our goal of routinely >encrypting all communications, sensitive or otherwise, as a way of >"desensitizing" the world to the use of cryptography. It is my own opinion that there will be a market for personal protection devices only when data is worth money. Data will be worth money when some data _is_ money. >only one primary function -- the execution of an RSA secret key >operation. [...] >it might have a "zeroize" function to destroy it. I refer to this as WEEM: Write, Erase, Encrypt Memory >Everything else (data compression and armoring, public key operations, >symmetric cryptography, etc) can and should go in the PC where cycles >and memory space are much more plentiful. Depending on the silicon size and production volume, you could probably use this device for all modular exponentiation operations. Or a cheap version could use a DSP module from a cell library and do all the arithmetic more slowly. >If the dongle has a built-in keypad, then it could store your RSA >secret key encrypted with a PIN that you'd have to enter to enable the >device. Not only a keypad, but a full 4-function calculator with an LCD display as well! :-) >I believe that "smart cards" are already available on the market that >do these or similar functions, although they are much more widespread >in Europe than in the US. Smart cards have the disadvantage that their die size is pretty severely limited. They have to fit within the thickness of a credit card and withstand repeated flexure. Much better for this application is the PCMCIA standard, which has plenty of room for circuitry. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Wed, 25 Nov 92 16:36:39 PST To: cypherpunks@toad.com Subject: The Cypherpunks Mail Project In-Reply-To: <775@morgan.demon.co.uk> Message-ID: <9211260036.AA18162@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Tony writes: >I access the net >through a dial up from a MS-Dos machine running KA9Q software. My >PGP is of the stand alone sort. I myself read my own mail on an MSDOS machine acting as a terminal over a dialin. The unix host is not overly secure, and I'm not about to go putting keys on it. I've been thinking about how to solve my own encryption problem, you can be sure. But most of the people on the list are reading mail on Unix machines, and a simple piping interface is the first thing to implement. I myself may not use it at first, but it is a start. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: karn@qualcomm.com (Phil Karn) Date: Wed, 25 Nov 92 16:47:49 PST To: hughes@soda.berkeley.edu Subject: Re: RS232 Crypto Dongle (idea for widely accessible crypto technology) Message-ID: <9211260047.AA01958@servo> MIME-Version: 1.0 Content-Type: text/plain >Much better for this application is the PCMCIA standard, which has >plenty of room for circuitry. I had this in mind too. But there's a problem -- if we have to depend on commercial manufacturers to build these things, how will we know if we can really trust them? I'm not impugning the manufacturers themselves, as it's entirely possible that the FBI and/or NSA wouldn't even let them build and sell a device like this if it's "too" secure. That's the paradox of freely-available crypto software like PGP. The software, including source, is open for inspection by all. But because it runs on general purpose computer hardware, it's vulnerable to all of the usual computer security attacks (viruses, modifications to secretly record or transmit keys, keystroke monitors, etc). Going to small, dedicated pieces of hardware removes these vulnerabilities, but then we're right back where we started -- with an opaque piece of commercial hardware whose secure operation we can't verify. Unless, of course, we can get the technology to build PCMCIA cards ourselves out of readily available parts... Phil From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: bwebster@pages.com (Bruce F. Webster) Date: Wed, 25 Nov 92 17:47:35 PST To: cypherpunks@toad.com Subject: News item Message-ID: <9211260049.AA05336@pages.com> MIME-Version: 1.0 Content-Type: text/plain Is this sudden flood of cypherpunk mail this afternoon mean we're all avoiding doing any work before taking off for Thanksgiving? ;-) AP news item in today's San Diego Union: Headline: "CIA chief hints change needed in ban on probing Americans" Excerpts: WASHINGTON--CIA Director Robert Gates says changes might be needed in the U.S. law that forbids the agency from collecting information about Americans or U.S. companies. Such changes might enable the CIA to better support the Justice Department and other law enforcement agencies, he said in an interview with the Associated Press. The idea grew out of a recent storm of accusations by Democrats in Congress, Justice Department officials and a federal judge that the CIA withheld information in the case of $5.5 billion lending scheme to Iraq by an Atlanta bank. ... [Gates said] the case of the Iraqi loans raises a broader issue of what the CIA is expected to do to aid law enforcement in such fields as financial crimes. Under current law, the CIA is strictly forbidden to collect information on Americans or American companies. "At some point it seems to me, very early on, we and Justice...and the Congress are going to have to...have some sort of serious discussion about whether there are changes in the law that are needed that will clarify some of the ambiguities and what we can and cannot do in support to law enforcement," Gates said. He did not elaborate. ... ---------------- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Wed, 25 Nov 92 17:23:22 PST To: cypherpunks@toad.com Subject: Crypto Dongles and Tamper-Resistant Modules In-Reply-To: <9211260047.AA01958@servo> Message-ID: <9211260119.AA02600@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Some points about the security of "crypto dongles" and other personal security devices. Phil Karn writes: > >Much better for this application is the PCMCIA standard, which has > >plenty of room for circuitry. > > I had this in mind too. But there's a problem -- if we have to depend > on commercial manufacturers to build these things, how will we know if > we can really trust them? I'm not impugning the manufacturers > themselves, as it's entirely possible that the FBI and/or NSA wouldn't > even let them build and sell a device like this if it's "too" secure. The crucial chips could be built under "open inspection" conditions, much like having source code for inspection prior to compilation on one's own--presumably trustworthy--machines. Several such vendors could be used, with independent auditors observing the processing steps throughout. (Merely the threat of a surprise inspection is probably enough to head off obvious attempts to insert hardware trapdoors and the like.) This seems like a solvable problem. The issue of whether the NSA will let such devices be built is interesting. There was the story of the "PhasorPhone," or somesuch, from some years back, with the story that the inventor, in Seattle, filed a patent application and got back a statement that the device was now classified and could not be talked about (let alone marketed). However, I've heard of no such cases recently. Other countries have excellent wafer fab facilities and could of course build the chips and the complete units. Whether Americans could buy them.... Tamper-Responding Modules (TRMs) Robert Brooks mentions using e-beam probers to read the bits out, and various etches, etc. TRMs came up several weeks ago on this list, and are mentioned in the Glossary posted a few days ago. Even if the TRMs can eventually be gotten into, probably at high cost, they will in most cases leave signs of having been opened, analyzed, probed, etc. (that's the "responding" part of TRM). The nuclear weapons people at Sandia and elsewhere (Russia, one now hopes) have been dealing with the problem for several decades. Some of their work has filtered out to the public literature. Smartcards often have basic TRM methods applied to them. If there's interest, I can summarize. --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: gnu@cygnus.com Date: Wed, 25 Nov 92 18:04:11 PST To: karn@qualcomm.com (Phil Karn) Subject: Re: RS232 Crypto Dongle (idea for widely accessible crypto technology) In-Reply-To: <9211260047.AA01958@servo> Message-ID: <9211260203.AA15805@cygnus.com> MIME-Version: 1.0 Content-Type: text/plain > I had this in mind too. But there's a problem -- if we have to depend > on commercial manufacturers to build these things, how will we know if > we can really trust them? ... > Unless, of course, we can get the technology to build PCMCIA cards > ourselves out of readily available parts... There's an implied assumption in the above that "we" and "commercial manufacturers" are not the same people, and that if "we" could build the cards "ourselves", then "we" could trust them. But any of "us" builds PCMCIA cards and offers them to "us" for sale, they will have to satisfy "us" that "we" truly understand its level of security. Enough pronouns? The point is that we can't trust ourselves any more than faceless manufacturers. It's more likely the manufacturers won't make some bonehead mistake that renders the system easy to break. And, as dramatized in "Sneakers", even the best people can be pressured by the government if they or their loved ones are vulnerable. John Draper was proposing to manufacture rs232 random number generators -- would you buy a used random number from this man? If you could see its design, you might. If not, probably not. There's a tradition that security software has to be made available in source form because the customers insist on it. Let's continue this trend and make sure it applies to hardware, too. John From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Richard Childers Date: Wed, 25 Nov 92 18:07:42 PST To: cypherpunks@toad.com Subject: chip verification ( Was: Tollhouse Cookies :-) Message-ID: <9211260206.AA08221@rchilder.us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain "The crucial chips could be built under "open inspection" conditions, much like having source code for inspection prior to compilation on one's own--presumably trustworthy--machines. Several such vendors could be used, with independent auditors observing the processing steps throughout. (Merely the threat of a surprise inspection is probably enough to head off obvious attempts to insert hardware trapdoors and the like.) This seems like a solvable problem." It seems to me that an ostensibly digital device with a fixed number of pins could be regarded as a finite state system, and systematically analyzed accordingly, IE, traverse the set of possible combinations of pins and signal levels and verify that it behaves in accord with pub- -lically available specifications. I'm no circuit designer ( yet ), but it seems to me that the microchip might be subject to design to make it conform to such tests, yet still contain additional circuitry which is undocumented. It might also have analog circuitry, I suppose, although I cannot immediately conceive of a use for such a thing. ( Of course, nanotech rears its ugly head, but that sword cuts both ways and, until it manifests, is irrelevant. ) Perhaps a chip could be tested, at the cost of additional time, by a systematic profiling of the finite boundaries of the device as repre- -sented by the combination of pins being stimulated, the combination of pin input voltage levels, and the resulting pin output voltages. If you want to be fanatical, you can also profile the resulting fields. It seems to me that it would be difficult to defy such a systematic profiling. ( I guess one could also test the I:E:R ratios at each of the states to further detect bogus circuitry, as well as borderline products. ) Why quality assurance lines don't do this on a chip-by-chip level now is beyond me. I'll bet the Japanese do now, or are working on it ... -- richard ===== -- richard childers rchilder@us.oracle.com 1 415 506 2411 oracle data center -- unix systems & network administration Klein flask for rent. Inquire within. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Wed, 25 Nov 92 15:31:10 PST To: gg@well.sf.ca.us (George A. Gleason) Subject: ease of use of encryption In-Reply-To: <199211251002.AA24840@well.sf.ca.us> Message-ID: <9211252330.AA04789@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > re Tai's item about more user-friendly decryption on the Mac version.... > > Seems to me we need it for encryption as well... For instance, > Having to go offline, go into WP, compose, go to crypto and encrypt, > then go back to telecom, link up again, and transmit.... This is where my little Crypto-Dongle would help. To encrypt, just flip a switch and type. Same thing for decryption... flip a switch and everything received is decrypted... -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: dclunie@pax.tpa.com.AU (David Clunie) Date: Wed, 25 Nov 92 00:03:49 PST To: cypherpunks@toad.com Subject: Re: CypherPunks Mailing list Message-ID: <9211250803.AA01586@britt> MIME-Version: 1.0 Content-Type: text/plain > From yanek@novavax.nova.edu Wed Nov 25 18:20:16 1992 > There always remains the issue of trust. How can I know that your system > has not been compromised, and is logging all in/out messages, and forwarding > them to FBI. This could be happening even without you knowing, for example > if "they" tap your network connection. Absolutely. This is a problem with any system that involves forwarding. For instance the currently proposed scheme advocates encrypting the address to be forwarded too, the remailer server still could have its mail tapped and the same correlation made. Of course my system seems much weaker in the sense that if the server is compromised the database is there for all to see. Of course the other system is just as weak in that if its server is compromised then someone can get the secret key that decrypts the addresses using the pass key from the automated software that does the decryption My objective was not to provide a high grade of anonymity, rather to enhance the functionality provided by existing anonymous services with privacy enhanced mail. Specifically to avoid sysadmins reading your anonymous replies which are often unsolicited and somewhat dubious or compromising. I think it achieves the objective but is clearly not going to sustain a concerted attack on the server by a knowledgeable assailant like the NSA or FBI or their equivalents in this country. To my knowledge, being very naive when it comes to encryption, the provision of anonymity which does not depend on a particular site to do the remailing (and is hence vulnerable as described) is much less straightforward, not to mention inconvenient. Perhaps I am overlooking something obvious to someone more knowledgeable. david From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eli Brandt Date: Wed, 25 Nov 92 19:32:58 PST To: cypherpunks@toad.com Subject: RE: PGP on local machine In-Reply-To: <58809.drzaphod@ncselxsi> Message-ID: <9211260332.AA23057@toad.com> MIME-Version: 1.0 Content-Type: text/plain > From: "DrZaphod" > >The comm program shoves the cyphertext into the uploadt editor to write your messages then > you've just lost the whole reason for encryption. I think what you're trying to say is that writing the message on an insecure machine gives it away. This is entirely true, but it sure beats giving away your secret key and passphrase. People were saying that they were unable to do their message editing locally -- if this is an insurmountable limitation, you'd do well to limit your disclosure to the one message rather than every secret you posess. If you *can* edit and encrypt locally, do it, of course. > [drzaphod@ncselxsi.uucp] Eli ebrandt@jarthur.claremont.edu From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: gnu Date: Wed, 25 Nov 92 19:38:08 PST To: cypherpunks Subject: Steve Kent on certification trust paths Message-ID: <9211260338.AA23180@toad.com> MIME-Version: 1.0 Content-Type: text/plain Steve is one of the key folks in the Internet PEM project. He sent this message last month during a discussion of why PEM uses top-down key certification rather than the "mesh" style that PGP uses. I hope that our (cypherpunks) experience with mesh key exchange will teach us a lot about whether and how it works. Nobody has ever tried this before, so we are doing research! John Gilmore ------- Forwarded Message Message-Id: <9210212125.AA27956@TIS.COM> To: Peter Williams Cc: pem-dev@TIS.COM Subject: Re: Perhaps OSI security is not possible in a liberal community! Date: Wed, 21 Oct 92 17:24:42 -0400 From: Steve Kent Peter, You have receibved replies from a couple of folks (via pem-dev) who have expressed views on why a strictly hierarchic certification system is not required. As the author of the words you cited in raising your question, and as an advocate of a strict certification hierarchy, let me respond. It is clear that one can construct a certification system which is not a tree, but rather is a mesh. The PGP approach is an example of such a scheme and X.509 permits this. However, there are a number of advantages to a hierarchy which have motivated its use in the Internet: In a pure certification mesh, one acquires certification paths by following chins of implied trust. It is not at all obvious that this approach scales well. The PGP folks do not yet have significant experience in this regard, so it will be interesting to see how the mesh develops over time. Most folks who have spent considerable time exploring this issue believe that unbounded transitive certification, with no required name relationships, is a bad idea. The rationale is that whatever trust one might accord to an entity may not apply transitively. I may give a house key to my neighbor to be able to open my house under certain circumstances, but that does not suggest that I would give the key to whomever that neighbor provides his key. It seems difficult to characterize the nature of trust in these "lateral" arrangements and applying trust transitively is even more difficult. From a user interface standpoint, it is generally agreed that most users are not capable of evaluating a certification path. In PEM we feel that a user should know the distinguished name (or an alias assigned by the user locally) of a message originator/recipient, and some indication of the policy under which the user was certified, e.g., a short-hand name for the PCA. This is about all we expect a user to be able to deal with. The though of a user really paying attention to (much less applying meaningful value judgements to) all of the DNs in a certification path boggles the mind. I won't clain to understand all the details of what PGP provides for managing key rings. However, if one were to provide a management tool for mesh certification in general, I think it ought to permit a user to construct a trust graph expressing the relationships implied by certification paths he acquires. The user might be able to express a degree of trust and a level of allowed transitive certification for each entity in the graph. Disply of this info, to allow a user to manage the graph, would be necessary. All in all, it seems to be pretty complex and it is highly questionable if most (many?) users could make use of this facility without getting confused. But, this analysis is based on reasoned speculation, not actual experience. The naming issues is a related, but somewhat indepedent topic. DNs provide many good features for use with a certification system. One wants the names to be globally unique and manageable in a distributed fashion. Being able to express a through, rich name is important if this technology is ever to expand beyond casual use in R&D environments. Note that DNS names are not great choices. Although there are close to a million DNS host names, that represents a very small portion of the population that one wants to serve with a system like PEM. Most DNS names are very short and will eventually reuslt in collisions as more individual and organizations are registered. The problem is worst in the U.S. where we have adopted a parochial scheme with GOV, EDU, COM, ORG, and MIL at the top, vs. other countries which prefix their DNS names with a country code. What's worse is that many DNS indivdiual names are not very mnemonic and thus don't offer much in the way of indentification outside of a very narrow context. There is sometimes confusion about the role of certificates. X.509 makes it clear that they serve only for identification, not authorization. This is improtant because it is difficult enough to manage them for identification purposes without overloading authorization info on them. Also, the entities who grant authorization may often be different from those who vouch for the identity of an individual (or organization) and thus this independent is appropriate. Often there seems to be a desire to bind more info into a certificate in support of authorization, but I (and many others) believe this to be a mistake. One can construct other certificates (like the PACs EMCA has defined) to use public key technology for authorization, leveraging off of certificates used for identification. Finally, there is revocation. We have adopted both a push and a pull facility for CRLs in PEM and the PEM CRL format differs slightly from that in X.509. Many folks fail to appreciate the subtleties of CRLs at first. Hot listing on a CRL says that either a key has been compromised OR a name has changed. If we have fine-grained, organizationally-related names, then these names will change with some frequency and thus CRL entries will arise. Because a certificate establishes a binding between a name and a key, it seems appropriate that only the entity which vouches for this binding (a CA of some tyep) should be able to revoke it. That is the model we use in PEM and we add the important feature of having each CA advertise when it will issue its next CRL, so that user's know when each CRL they hold is obsolete. Peter, I hope this note helps explain the very terse words I put in the PEM key management document. Steve ------- End of Forwarded Message From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Wed, 25 Nov 92 20:07:06 PST To: cypherpunks@toad.com Subject: Sharp Wizard as a Crypto Dongle? Message-ID: <9211260402.AA12908@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain All the interesting discussion of building RS-232 crypto dongles, notably the proposal of Yanek Martinson, remind me of the idea kicking around of simply programming a Sharp Wizard (or Casio B.O.S.S., etc.) to do the same function. (And eventually much of our critical encryption will likely be done on more powerful devices like the Apple Newton, General Magic gizmo, and Eo thingamajig.) These devices have several advantages: 1. Cheap. $150 or less. 2. No construction required. 3. Not likely to have trapdoors or other limits, at least not in the hardware, or in the units you buy today at your local electronics superstore. 4. RS-232 connections for PCs, Macs, etc. (used to be as an add-on, now often bundled with the units). 5. LCD display, keypad, etc. (some of the features Yanek was envisioning in later models of his dongle). 6. A fairly slow CPU, but one which is well-integrated with the other features (and which saves us the effort of designing and debugging). 7. Some have PCMCIA capabilities. 8. They can be used for other thingss when not being used as a dongle. 9. New versions of the software (e.g., PGP 3.21) can be added more easily, I suspect, than in a custom-built RS-232 dongle. 10. It is unlikely the NSA, FBI, or Patent Office could "ban" such devices, as they are already widely deployed. Only the specific programs that make them act as crypto dongles would be "bannable," and I doubt this could be enforced. By the way, the same arguments could be applied to using cellular telephones as the base for building/programming portable, personal crypto devices. (An exciting talk at Hackers on mods to Oki 900 cellphones was an eye-opener.) I don't think an easy interface to RS-232 ports exists, but I know some cellphones interface to computers (the Oki 900 above sure did). --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tony@morgan.demon.co.uk (Tony Kidson) Date: Wed, 25 Nov 92 15:47:31 PST To: cypherpunks@toad.com Subject: Re: The Cypherpunks Mail Project Message-ID: <775@morgan.demon.co.uk> MIME-Version: 1.0 Content-Type: text/plain In message <9211251705.AA17774@soda.berkeley.edu> you write: > > It is also my suspicion that simple PGP decryption support is fairly > straightforward, being mostly the ability to run a command on a block > and replace the block with the output of the pipe. I'd like to chip in here, in my _very_ newbie way, that not everybody is running a unix system with the ability to pipe things between processes in so facile a manner. I access the net through a dial up from a MS-Dos machine running KA9Q software. My PGP is of the stand alone sort. I cannot easily get a new mailer to run on this system. Whatever protocol is decided upon, it would be useful if it were not too host-system specific. [FX Crawls back under stone] Tony ------------------+-------------------------------+--------------------------+ | Tony Kidson |`morgan' is an 8MB 486/33 Cat-| Voice +44 81 466 5127 | | Morgan Towers, |Warmer with a 670 MB Hard Disk.| E-Mail | | Morgan Road, |It resides at Morgan Towers in| tony@morgan.demon.co.uk | | Bromley, |Beautiful Down Town Bromley. | tny@cix.compulink.co.uk | | England BR1 3QE | -=<*>=- | 100024.301@compuserve.com| +=================+===============================+==========================+ From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: fen@genmagic.com (Fen Labalme) Date: Wed, 25 Nov 92 21:41:23 PST To: cypherpunks@toad.com Subject: No Subject Message-ID: <9211260518.AA01581@> MIME-Version: 1.0 Content-Type: text/plain On the issue of digital cash and remailers tcmay writes: >Banks, escrow services, etc. will all have "reputations"... Note that a good reputation is good as gold. Now, when I get my remailer up and running, I'll run it for a while in "free mode" (while I get the bugs out) and then I'll put it into "reputation sharing mode" which works as follows: Every time I get a message to be re-mailed, I remember the sender's site name. Later, when I desire to mail something, I may choose to send it through that site. If operating in free mode, it passes through. If it is not a remailer or doesn't accept my message (via a bounce) I take it off my list of friendly mailers and and begin bouncing messages that it sends to me. This should, of course, all happen automagically. I realize that I am describing this somewhat poorly (it's late and I'm tired) but the basic concept is to get everuyone who wants to send mail through a re-mailer to become a remailer, or perhaps buy "friendship" with one through external means. This propogates remailers. The simplest form of barter is one for one. Fen From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tribble@xanadu.com (E. Dean Tribble) Date: Wed, 25 Nov 92 22:23:39 PST To: uunet!ghsvax!hal@uunet.UU.NET Subject: An easy-to-reply anonymous mail scheme In-Reply-To: <9211252352.AA01919@nano.noname> Message-ID: <9211260605.AA04591@xanadu.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain The only solution (and I think I mean ONLY) is positive filtering. When pseudonyms proliferate, the only way to cut down on trash is by filtering based on reputation. Since negative reputation can be avoided simply by creating another pseudonym, the only reputation that will make a difference is positive reputation: credibility. An example system would be one in which I give credibility and transitive credibility ratings to all the names whose posts I want to see. The transitive part lets me discover new people (who know people I respect who know people they respect...). Then anyone credible can introduce someone else around simply by deciding to read their mail (assuming their taste is good enough that people want to read what they're reading). This grows in several directions: AI, reputation services (magazines), etc. A public system with pseudonyms will require this very quickly. Reputation systems only work if things are digitally signed, of course (so readers and filters can't be spoofed). I will be talking about this more at the next cypherpunks meeting. dean From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tribble@xanadu.com (E. Dean Tribble) Date: Wed, 25 Nov 92 22:38:29 PST To: uunet!netcom.com!tcmay@uunet.UU.NET Subject: Electronic Banking In-Reply-To: <9211252219.AA00550@netcom.netcom.com> Message-ID: <9211260619.AA04606@xanadu.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain Currencies will almost certainly have to be backed by goods in order to be astablished. Would you want to keep your money in something that could collapse easily? There's been a lot of thought put into using things like mutual fund shares as the currency. dean From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Wed, 25 Nov 92 19:29:33 PST To: cypherpunks@toad.com Subject: advantages of RS-232 based crypto device Message-ID: <9211260329.AA12665@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain A number of people responded, both privately and publicly to my RS-232 dongle idea. Several offered help with the hardware/schematics design. Some thought that PCMCIA cards would be better for this. Theoretically, yes. They could contain more memory and processing power in a smaller space. There are several problems with PCMCIA. First, not nearly as many devices have PCMCIA interface as RS232. Second, you can not make a PCMCIA card yourself, nor can you easily open it and look what's inside. My proposed design would consist of only off-the-shelf parts, the schematic would be published, so anybody could build the device for himself. I might distribute it in the kit form, which would include all the parts and the PCboard, and a case. This way, you can test each component in any way you want, and then put the thing together by yourself. Even if you got the complete unit from me, you could open it up, and look inside. You could see if it actually corresponds to the schematic. Some people doubted the possibility of its second greatest advantage, the ability to work with any computer or terminal regardless of operating system, mail software, comm software, etc. Also it could be used between an ASCII terminal and a (non-trusted) host. Here is an example of a design that I think will work with any software/host/terminal/etc combination. If I am wrong, please let me know. NOTE: this is not the final design of the device, just an example. ===================================================================== Since the device needs to have a processor anyway, it may as well have a built-in simple line-mode editor that is good enough for composing mail messages. So to use the device to send mail, you would: 1. Give the mail command to your host (or BBS) using whatever command or menu selection you normally use to send mail. Then if the mail program puts you into a mode-based editor like vi, enter insert mode (press i or a). 2. Push the "encrypt" button on the device (or send a magic sequence from your terminal). 3. Type your message in a simple BBS style (in case you have not used a BBS, this is the kind of editor they usually use: You simply type text. Every line has a number. When you press return, the next line number appears. At the beginning of a line, you can issue commands for example with a slash or a dot. commands include things like DONE, ABORT, DEL LINE, INSERT, etc.) If you had the text prepared on the local machine, you could simply transfer the text, and then type the "DONE" command. All this while, the text is only stored in the memory of the crypto device, the remote host is still waiting for input. So plaintext never crosses the line or network. 4. When you are done, the text would be encrypted (you would select a public key from the keyring, or it could be automatically determined from preceding text (such as the e-mail address). You would have the option of signing the text. The device transfers the encrypted text to the host and becomes transparent. You then type the command to tell the host that you are finished typing the message, and off it goes! ========================================================================== Now, if you see any reason why the above would not work, please let me know. A number of people wondered if the tamper-proof memory for private key storage was necessary. Some other people wondered if it was in any way effective (i.e. if someone gets the device, they can just use it to decrypt/sign stuff; so what if they don't get they actual key out of it). I tend to agree. I will have to think some more about this. It would certainly make the design much simpler (and cheaper, and consistent with the desire for off-the-shelf parts) if I avoid use of such exotic hardware. The private key may be protected from use by un-authorized users by encrypting it with a key, and requiring it to be entered on a keypad on the device. Someone suggested that the key must be typed in periodically (every x minutes). The only case I could see a problems with this approach is if "they" get you while you are using the device. For the next x minutes they can decrypt any old messages they may have stored. I believe this addresses all the concerns that have been voiced about this device. If you have any other concerns, questions, or comments, please let me know. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Wed, 25 Nov 92 19:36:50 PST To: cypherpunks@toad.com Subject: neat features that could be added to the crypto dongle Message-ID: <9211260336.AA12812@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain Here are some neat ideas: If you and me both had one of these devices, we could connect them, and exchange our public keys. We could also exchange other public keys on our keyrings. Another useful thing it could do: watch the incoming rs-232 traffic for anything that looks like a public key. When one is detected, you would have the option of storing it on your keyring. It could have an LCD display, and then it could calculate a hash function of someone's public key and display it. This would make it easy to verify keys by phone or any other means. Instead of spelling out the 130-character alphanumeric sequence you would only need to verify a short (maybe about 8 to 12 digits) number. As someone mentioned, if something has a keypad and an LCD display, it can also be a calculator. And, if it has two RS-232 ports it could be a break-out box or a line analyzer. But I think this is creeping featurism. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nobody@alumni.cco.caltech.edu Date: Wed, 25 Nov 92 23:12:31 PST To: cypherpunks@toad.com Subject: No Subject Message-ID: <9211260713.AA01656@alumni.cco.caltech.edu> MIME-Version: 1.0 Content-Type: text/plain This entire business may be pretty simple. If we have anonymity both ways, (where one or neither party knows the others physical location), then who cares about the content of the message? You might as well send it in plain text, Except you need RSA just for the signitures so you know you aren't being spoofed. *RSA signatures ARE money.* Unless money (accouting, proof) is needed, you don't need RSA. What you do need is anonymity. {Of course throwing RSA on top of it with RSA encoded regular keys is a nice touch (no sense in giving anything away.)} ---- Now listen up kiddies, what you are playing with is sedition, conspiricy, and the like. In other words plain old politics. Adding mumbo-jumbo (crypto) technology doesn't change a thing. If you want to do this, it is a simple matter of building a large enough cooperative group. How big? Well bigger than the Hells Angels, Maybe a thousand people. I don't know. Depends on how rough it gets. But the proceedure is just mutual backscratching. We all accept and forward anonymous mail for each other. So long as it is coded, we can deny knowledge of the contents. That can go a long way as long as the basic activity (of forwarding) itself is not proscribed. There have been several suggestions here how this would be done. You send mail to a cooperative site, who forwards it. That same site will receive replies. You collect your mail with specific commands to dump the accumulated contents to some other node. It would be moderately tough to bug one node. A quick second skip would make it almost impossible to track, 3 quick skips to eternity. But the trick is to have a large net of standardized, cooperating sites. There have been suggestions to throw cypher-money into this equation to pay for the operation of the "MIXes" or the operators of the servicing nodes. But that won't work. In a hostile environment money won't buy civil disobedience. It's like you can't pay somebody else to go to war for you. We all have to shoulder part of the risk. We should evolve some standard "remailer/replier daemon" and run them as a common service. It is just our civic duty. The list of cooperating, volunteer sites would be published in a plain text group. You are either on the list or you aren't. Just the presence of such a cypher mob should stop the forces of darkness. -Gilbert From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Wed, 25 Nov 92 20:47:27 PST To: cypherpunks@toad.com Subject: using personal organizers or palmtops for crypto Message-ID: <9211260447.AA14645@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > notably the proposal of Yanek Martinson, remind me of the idea kicking > around of simply programming a Sharp Wizard (or Casio B.O.S.S., etc.) > to do the same function. I have thought of that before. Actually, I was thinking of using a notebook computer with 2 serial ports as a prototype/proof of concept. > These devices have several advantages: True. But there are also disadvantages: They generally don't have two serial ports. This may not seem like much, but is actually a serius problem. Since they tend to have small screens, weak keyboards, and not the greatest comm software, you might not like using it as your window into the cyberspace. The advantage of a standalone device with two rs232 ports is that you can continue to use your existing terminal, pc or a mac, along with all its conveniences. > 1. Cheap. $150 or less. I hope to make my device in this price range or less. I can not be sure yet because I don't have a definite hardware design completed, but that is the range I am aiming for. I don't know, maybe I am unrealistic, but I think that in kit form it could be significantly under $100. > 2. No construction required. If this idea ever takes off in a big way (about a hundred orders or so) then I have an electronics company that could build them for me. > 3. Not likely to have trapdoors or other limits, at least not in the > hardware, or in the units you buy today at your local electronics While they may not have any intentional trapdoors, since you don't have the full design specs, you can never be sure of everything that is going on within the machine. For example, if in my device I have a section of memory that holds the private key, and I clear it (overwrite with nulls) then I can be reasonably sure that if someone was to get the device they would not be able to retrieve the private key from anywhere. In a machine such as a Wizard, you never know where the number may end up, for example in some area of memory used for the auto-resume feature or some kind of cache. If a device was not designed with security in mind it is likely to be insecure. > 6. A fairly slow CPU, Might severely limit the length of keys you can handle, therefore the level of your security. > 7. Some have PCMCIA capabilities. See my previous post on why PCMCIA is not a very good choice of technology for this purpose. > 9. New versions of the software (e.g., PGP 3.21) can be added more > easily, I suspect, than in a custom-built RS-232 dongle. I plan to build it as a generic processor with two RS-232 ports. All the crypto stuff would be handled in software. So to cope with new formats, etc. all you would need to do is reprogram the EPROM. This is completely unrelated to the topic at hand, but: > By the way, the same arguments could be applied to using cellular > telephones as the base for building/programming portable, personal > crypto devices. (An exciting talk at Hackers on mods to Oki 900 > cellphones was an eye-opener.) I don't think an easy interface to > RS-232 ports exists, but I know some cellphones interface to computers > (the Oki 900 above sure did). What interfaced to the computer was the control functions (dial, signaling, etc.) It sure was fun and useful, but not nearly enough to make a secure telephone. The actual speech (that which you are trying to encrypt) is never actually digitized.... -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tony@morgan.demon.co.uk (Tony Kidson) Date: Thu, 26 Nov 92 01:30:46 PST To: cypherpunks@toad.com Subject: Re: Electronic Banking Message-ID: <782@morgan.demon.co.uk> MIME-Version: 1.0 Content-Type: text/plain In message <9211252219.AA00550@netcom.netcom.com> you write: > > Warning! Recently, a bunch of bowlers (women, no less) were busted for > illegal gambling because of their "pot" they were bowling for. After > much public outcry and laughter at the authorities, the charges were > either dropped or reduced. I mention this because casual bowlers evoke > sympathy, hackers and cypherpunks do not. Using the net, the 'banker' could easily be 'offshore' and not subject to US law in these matters. After all the internet reaches into Canada and obviously (from my point of view) to the UK. I think a more real problem with anonymous banking, is not one of 'trust' in the 'banker' but in his net access. What do you do when your banker, for whatever reason, becomes unreachable? Regards Tony ------------------+-------------------------------+--------------------------+ | Tony Kidson |`morgan' is an 8MB 486/33 Cat-| Voice +44 81 466 5127 | | Morgan Towers, |Warmer with a 670 MB Hard Disk.| E-Mail | | Morgan Road, |It resides at Morgan Towers in| tony@morgan.demon.co.uk | | Bromley, |Beautiful Down Town Bromley. | tny@cix.compulink.co.uk | | England BR1 3QE | -=<*>=- | 100024.301@compuserve.com| +=================+===============================+==========================+ From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Bill Sommerfeld Date: Wed, 25 Nov 92 21:38:50 PST To: tcmay@netcom.com Subject: Sharp Wizard as a Crypto Dongle? In-Reply-To: <9211260402.AA12908@netcom2.netcom.com> Message-ID: <9211260511.AA00154@orchard.medford.ma.us> MIME-Version: 1.0 Content-Type: text/plain I had the same idea, only with an HP48SX (I work for HP); the 48 is a little pricier, but cheaper than say the 95LX or similar pocket PC's. (I got as far as a DES implementation in user RPL -- I "ported" the Ferguson DES in a day or so; I haven't gotten around to slogging through converting it into system RPL or machine code). Progammable consumer products would be pretty good as *prototypes*, but not good enough for "production" use in the presence of a determined attacker due to lack of tamper-resistance. [my apologies if this came up before; I'm new to the list]. - Bill From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: mark@coombs.anu.edu.au (Mark) Date: Wed, 25 Nov 92 05:24:15 PST To: cypherpunks@toad.com Subject: Secure PK swapping.. what are the methods? Message-ID: <9211251323.AA27604@coombs.anu.edu.au> MIME-Version: 1.0 Content-Type: text/plain Below is a letter Ive sent to a person designing a communications system similar to IRC but designed with the ability to be anonymous and as secure as possible. Further details will be announced soon when it's stable. --------------------Begin letter----------Begin letter------------------- Before you get too involved with the client in the comm system I was thinking of a way of having secure privmsgs, two forms depending on how open one chose to be: Messages are exchanged via UDP to hide from the netstat junkies... When someone does a msg the first time and the client doesnt know about that user it queries the server to either get a hostname/port pair for that user and/or a public key. The data is then stored in an internal attribute bank. Format of a private message: ._________________________________________________________. | Nickname Plaintext | dest IP | dest udp port | | =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= | | =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= | | =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= | `---------------------------------------------------------' [Return host/port/public key are encrypted into the PGP? message] The above message is then sent to the delivery module of the client. The above host and port are either the recipeints or the server's depending on what type of message is being sent. Thus the same message can go to the server or the recipient direct per se: 1) Using the hostname/port + public key for that user the sender's client encrypts the message and udp transmits a message to that port on the other users host. That remote client has set up a socket to listen on that udp port for messages. The remote client unpacks the message with it's private key and extracts the message, a reply host and port and the senders public key. He can then reply to the sender and they both can talk without loading down the server. Plus, unless someone is logging the ethernet, no one can ascetain wether they are talking. There is only the initial request of the users public key from the server which each client sends in automatically when it connects. You might also have an option in the client to auto download a block/all of the users nicks and their keys so no-one can detect the initial query of a user. 2) The other, differently secure :), form is because the server has been told to hide the users username + hostname from the /who information. All there exists for that person is a nickname and a public key. The senders client gets individually/block downloads the key he wants and proceeds to udp a message to the server which has the udp port and hostname of the recipient as normal from the client connect. It acts as IRC does now, as a middle man for messages. Less secure because the server admin can ascetain that there is a message being sent between the two people and also he can slip in his *OWN* keys to basically grab and decipher messages between the two parties. i.e he sends his own key to the sender and decrypts the incoming message and then sends the message out to the recipient using their encryption key. neither user could tell there was a switch in between. (There are schemes to get past this however). Both ways have their flaws because you are relying on the non-hackedness of the server to give you the right keys and hostnames and ports. A bad admin could easily, knowing enough about coding, disrupt the entire process if we didnt from the start ensure the right protocols were used. It has to be done right the first time or not at all. I'll echo this letter to a cryptography mailing list to ask for details of schemes that will allow each user to know they have a valid, secure public key of the other. One possible solution would be to do a mass query of all the online servers at once and if they didnt report the same keys sound a Real Big Alarm (tm). Maybe an automatom could sit there randomly checking keys :) (Can hear the cries of "No Bots.. No Bots" now :). (Note this allows *someone* to know your doing a query for a user... that may or may not bother the sender/recipient. Doing a block transfer from all the servers at once isnt net.nice) Comments? ------------------End of Letter----------------End of Letter---------------- Now what Im curious about is any other methods of secure key exchange where the exchange mid point may be lying about the keys, the hosts and the ports. Assume each person knows the others 'style' etc. How does one get the real keys to each other with an unreliable "medium"? (It might slip in it's PK). Assume that they havent previously organised a key exchange. Replies to me or the list.. (but not both please.. my mbox is busy enuff :) Mark mark@coombs.anu.edu.au From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: rebma!rebma!wmo@kksys.mn.org Date: Thu, 26 Nov 92 00:22:10 PST To: cypherpunks@toad.com Subject: Remailer at rebma Message-ID: MIME-Version: 1.0 Content-Type: text/plain I've got Hal's PGP mods to the remailer code installed on rebma. The remailer is remailer@rebma.mn.org, and the PGP key to use is: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAisUI2QAAAEEAKgm07Hsje5KpmXYd5azk0R6AES+qK7LcofnVGojUs7GBghD WbwrmW8oOEOhRorlShRALKeYspV4xYIw4WDkJcJxuf1B254scz1urF/Eem3zPW9b yPAx7W/cGwvs6SouZvFcSDq4v1zApvGE9hP4szPzHeGmVr0NVNeaDK0guoCpAAUR tCBSZW1haWxlciAocmVtYWlsZXJAcmVibWEubW4ub3JnKQ== =/qHx -----END PGP PUBLIC KEY BLOCK----- See Hal's previous messages for how to use the remailer, or write me, and I'll dig his messages up. I liked Fen's idea about bartering remailers. I'm all for it. -Bill -- Bill O'Hanlon wmo@rebma.mn.org From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: rebma!rebma!wmo@kksys.mn.org Date: Thu, 26 Nov 92 00:22:31 PST To: cypherpunks@toad.com Subject: MIME Message-ID: MIME-Version: 1.0 Content-Type: text/plain I got the metamail stuff running on my machine. I think it's a good way to get the multimedia mail job done. Does anyone on the list have a better .mailcap entry for pgp than the following....? application/pgp ; pgp < %s ; label="PGP encrypted text" ; compose="pgpcompose %s" where pgpcompose is a quick hack that looks like: #!/usr/bin/ksh rm /tmp/pgpcompose vi /tmp/pgpcompose echo What key? read key pgp -mae /tmp/pgpcompose $key mv /tmp/pgpcompose.asc $1 exit 0 I've just been fooling around with metamail for a couple days, and I don't know what the best way to include PGP is... This seems to work, but I'm guessing I'm missing something more elegant. -Bill -- Bill O'Hanlon wmo@rebma.mn.org From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: crunch@netcom.com (John Draper) Date: Thu, 26 Nov 92 01:37:40 PST To: cypherpunks@toad.com Subject: Mac PGP report and Rander progress Message-ID: <9211260933.AA04417@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Mac PGP effort: After talking with Phil Zimmerman, we decided to break the MacPGP effort into two teams. A short term team as it currently stands now, with the origional members, and a long term team to change PGP into a set of C Libraries that can be used with ANY platform or API. The short term team consists of its current members who are doing current work on the Mac implementation. Next week, perhaps on Wednesday Evening at 7 pm, we will be setting up a conference call to talk about all of the details, and introduce each other. My role in this currently will be that of Email coordinator between the Mac PGP effort and the other platforms. It is obviously clear that there is still a lot of mis-trust that people have in me. I guess it's still very hard to ditch that "Once a criminal- always a criminal" attitude. Phil Karn says: >John Draper was proposing to manufacture rs232 random number >generators -- would you buy a used random number from this man? This is EXACTLY my point. So I WILL be publishing the schematic and I expect the Rander box will be put through it's paces. I have simplified the circuit immensly, and even eliminated the AD converter, but not sure the design works, but want to run the design by a few other HW types before I "breadboard" it. I think I got it down to 3 chips including the UART. Two CMOS chips, a Latch and a gate I'm using as a comparitor, and the UART plus a noise source. Gack!! All these years I try and ELIMINATE noise, and now I am LOOKING for noise. By biasing one of the gates, into the linear mode, it doubles as the amplifier for the noise source. I've gone eligantly simple with the design, I just hope it works. Perhaps this circuit can be integrated into Yanek's Dongle. Phil K. writes: >>My thinking is to limit the external "dongle" to the one function that >>is truly sensitive and worthy of special protection: RSA secret key >>operations. Eric Hughes replies: >Phil's comment are right on. There is a need for you secret keys >to be easily and physically relocatable. The Obvious, cheapest, but perhaps not the best way, is to keep your key on a floppie. More later .... From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Thu, 26 Nov 92 02:43:35 PST To: miron@extropia.wimsey.com Subject: Re: How far is to far? Message-ID: <199211261042.AA23055@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Miron Cuperman responds to my concerns about the IRS's claims on barter systems by saying, "How do you think the IRS is going to trace those banks and customers behind all the anon mixes?" I must really disagree here. If we start sneaking around in the shadows of legality, we will eventually bring down some nasty attention which will not help us. Privacy itself is a mainstream issue. Dumping all forms of taxes is not a mainstream issue, in fact the mainstream regards tax resisters as fringies of the worst order. This is not to debate the merits of the substantive issues involved, just to recognise the major PR problem which exists and say I believe we should stick to the main issue. I for one don't want the Feds to have an excuse to lock up the whole net or our little fragments of it. We can minimise taxation and stay completely within the law by operating as a volunteer not-for-profit network. And then if the Feds come down on us for using unregistered crypto keys, we have a new issue that the public haven't become jaded over, which can be made much of in the media. And I would also say that it's not good to give potential adversaries an excuse for saying we're doing crypto simply in order to hide illegal activities such as "tax cheating" or whatever; next it will be dope and kiddie porn and bank robbery via ISDN, eh...? -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Thu, 26 Nov 92 02:55:00 PST To: ebrandt@jarthur.Claremont.EDU Subject: Re: PGP on local machine (was Re: MacPGP) Message-ID: <199211261053.AA23687@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Eli discussed some ideas regarding online encryption... it suddenly occurred to me that if you were connected to the phone line while doing your crypto processing, it's entirely possible that some signal would leak through and if your phone line was being monitored, the nastie-wasties would get the whole thing including your private key. Uh-oh, very bad. Thus the need for some kind of hardware device which isolates the line and all that. Perhaps a specifically cryptographic modem as has been proposed by others here. And perhaps a tweak in the software which requires that the user set these options manually at some point, where a warning message would occur to say, "don't do on-line crypto unless you have (one of the protected modems)." -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Thu, 26 Nov 92 03:17:22 PST To: tcmay@netcom.com Subject: Re: Electronic Banking Message-ID: <199211261116.AA24529@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Tim and others write with concern about the possible legal consequences of setting up a model digital economy. I would like to suggest that there may be very little to worry about here. This entire project constitutes a research exercise which will no doubt be written up for publication (at least online publication, which makes sense culturally given the nature of the community of interest). It's research and education. The amounts of "digital money" involved can be utterly miniscule: pennies. This is a "token economy" in the same sense as when psychiatric hospital inmates work on the ward for tokens they can trade in for snacks and so on, or a highschool economics class does a similar exercise using Monopoly-type play money. This is not illegal any more than any other social science project would be illegal if all the subjects were adults giving informed consent. Pennies are not a controlled substance nor are they a weapon (unless dropped on people from high places... :-). By analogy I'm thinking of the laws against bigamy/polygamy, and a group of adults getting together to study the question of the effects of different kinds of marital arrangements. So they have a group where they "pretend" to carry out different arrangements and then examine the social dynamics resulting from each. It's quite obvious we're all concerned about the larger social impacts of the possibility of a transition to a cashless economy; and we're hypothesising possible negative consequences and trying to work out solutions. That is entirely admirable, and can be presented as such to anyone who cares to listen to the case. If this needs any further work to develop research angles, I'll gladly come up with a bunch of surveys and other measures, and we can put them into use and harvest some nifty statistical results which might be publishable in the academic literature. -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Thu, 26 Nov 92 03:24:33 PST To: yanek@novavax.nova.edu Subject: Re: RS232 Crypto Dongle (idea for widely accessible crypto technology) Message-ID: <199211261123.AA24844@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Re Phil's items on the Crypto-Dongle. I'm in favor of a device having a keypad for PIN entry, with a fail --> destroy function. Making it small enough to be kept on one's person all the time, virtually guarantees other manufacturing compromises which would result in degraded reliability or increased potential for physical breakage. It should not be necessary to carry it on you; in any case, possession of one might raise eyebrows in some quarters. I believe that carrying out the entire crypto operation in the dongle is preferable to having it only do the secret key RSA processing; if for no other reason, compatibility problems that might result in creation of platform-specific dongles. Better to have one Universal Dongle that needs only a platform-specific user interface. The dongle (suggested brand name: Codepack) could also be sold as a sort of blank slate into which a user would load his preferred crypto software. Now we have a generic product which can be sold over the counter without prescription, as it were. -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Postmaster Date: Thu, 26 Nov 92 00:34:19 PST To: cypherpunks@toad.com Subject: Failed Fail Report Message-ID: MIME-Version: 1.0 Content-Type: text/plain The enclosed fail report failed to reach it's intended recipient because of the use of the unbracketed IP number. HOWEVER, surely there should be a -request address for cypherpunks to which should be in the Sender: field so that fail reports go back to the list maintainer and not the originator of the article. Tim Brooks Postmaster(@uk.ac.cam.ucs, @uk.ac.cam.phx, @uk.ac.cam.cus, @uk.ac.cam.ppsw) Postmaster(@ucs.cam.ac.uk, @phx.cam.ac.uk, @cus.cam.ac.uk, @ppsw.cam.ac.uk) University of Cambridge Computing Service Tel: 0223-334709, Int: +44 223 334709 New Museums Site Fax: 0223-334678, Int: +44 223 334678 Pembroke Street Telex: 81240 CAMSPL G CAMBRIDGE E-Mail(JNT): T.Brooks@UK.AC.Cam.UCS CB2 3QG United Kingdom "(Internet): T.Brooks@UCS.Cam.AC.UK X.400: /I=T/S=Brooks/OU=Computing-Service/O=Cambridge/PRMD=UK.AC/ADMD= /C=GB/ > Accepted: 17:57:03 25 Nov 92 > Submitted: 17:29:12 25 Nov 92 > IPMessageId: <"ppsw1.cam..157:25.10.92.17.28.53"@ppsw.cam.ac.uk> > From: MAIL-DAEMON > To: FAILREPTER@uk.ac.cam.phx > Subject: Delivery Report (failure) for fnerd@192.9.200.3 > Received: from ppsw.cam.ac.uk by ppsw1.cam.ac.uk id <05165-0@ppsw1.cam.ac.uk>; > Wed, 25 Nov 1992 17:29:12 +0000 > Message-Type: Delivery Report > Content-Identifier: Fail Report > > ------------------------------ Start of body part 1 > > This report relates to your message: Subject: Fail Report, > Message-ID: , > To: fnerd@192.9.200.3 > of Wed, 25 Nov 1992 17:28:52 +0000 > > Your message was not delivered to fnerd@192.9.200.3 > for the following reason: > Unknown Address > Unknown domain '192.9.200.3' > > ***** The following information is directed towards the local administrator > ***** and is not intended for the end user > * > * DR generated by: mta ppsw1.cam.ac.uk > * in /PRMD=UK.AC/ADMD= /C=GB/ > * at Wed, 25 Nov 1992 17:28:53 +0000 > * > * Converted to RFC 822 at uk.ac.cam.ppsw1 > * at Wed, 25 Nov 1992 17:29:12 +0000 > * > * Delivery Report Contents: > * > * Subject-Submission-Identifier: [/PRMD=UK.AC/ADMD= /C=GB/; * Content-Identifier: Fail Report > * Subject-Intermediate-Trace-Information: /PRMD=UK.AC/ADMD= /C=GB/arrival Wed, 25 Nov 1992 17:28:52 +0000 action Relayed > * Subject-Intermediate-Trace-Information: /PRMD=UK.AC/ADMD= /C=GB/arrival Wed, 25 Nov 1992 17:28:40 +0000 action Relayed > * Content-Correlator: Subject: Fail Report, > * Message-ID: , > * To: fnerd@192.9.200.3* Recipient-Info: fnerd@192.9.200.3, > * /RFC-822=fnerd(a)192.9.200.3/OU=PP Switch/O=Cambridge University/PRMD=UK.AC/ADMD= /C=GB/; > * FAILURE reason Unable-To-Transfer (1); > * diagnostic Unrecognised-ORName (0); > * last trace (ia5 text (2)) Wed, 25 Nov 1992 17:28:40 +0000; > * converted eits ia5 text (2); > * supplementary info "Unknown domain '192.9.200.3'"; > ****** End of administration information > > ------------------------------ Start of forwarded message 1 > > Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk > with NIFTP (PP-6.0) Cambridge as ppsw.cam.ac.uk > id <05157-0@ppsw1.cam.ac.uk>; Wed, 25 Nov 1992 17:28:53 +0000 > Date: Wed, 25 Nov 92 17:28:40 GMT > To: fnerd@192.9.200.3 > From: Mail Server > Subject: Fail Report > Message-ID: > > Your message was not delivered to one or more of: > LI10000@uk.ac.cam.phx > > Recipient has too many outstanding messages in message store: 'LI10000@UK.AC.CAM.PHX' > No valid recipients in JNT header > > Failed message follows: > > Received: from relay2.UU.NET by ppsw1.cam.ac.uk > with SMTP (PP-6.0) International as ppsw.cam.ac.uk > id <05143-0@ppsw1.cam.ac.uk>; Wed, 25 Nov 1992 17:28:32 +0000 > Received: from toad.com by relay2.UU.NET > with SMTP (5.61/UUNET-internet-primary) id AA07054; > Wed, 25 Nov 92 12:20:09 -0500 > Received: from cygnus.com by toad.com id AA12348; Wed, 25 Nov 92 09:17:33 PST > Received: from relay2.UU.NET by cygnus.com (4.1/SMI-4.1) id AA26873; > Wed, 25 Nov 92 09:17:10 PST > Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET > with SMTP (5.61/UUNET-internet-primary) id AA05539; > Wed, 25 Nov 92 12:15:15 -0500 > Received: from smds.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) > id 121431.10955; Wed, 25 Nov 1992 12:14:31 EST > Received: from waldo by smds.com (4.1/SMI-4.1) id AB05506; > Wed, 25 Nov 92 11:29:04 EST > Message-Id: <9211251629.AB05506@smds.com> > Sender: fnerd@192.9.200.3 > Date: Wed, 25 Nov 1992 12:40:24 -0800 > To: cypherpunks@com.toad > From: fnerd@com.smds (FutureNerd Steve Witham) > Subject: Re: Random Numbers Boxes and Cypher Processers > > >Why do encryption in the modem instead of the host cpu? > > A point that hasn't been made painfully clear yet: "DSP--Digital > Signal Processor" chips are really just fast processors for repetitious > arithmetic--just what RSA needs. Maybe some experience in > programming them for that sort of purpose would be useful. > > - -fnerd > fnerd@smds.com (FutureNerd Steve Witham) > > > ------------------------------ End of forwarded message 1 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: richard_mezirka@askinc.ask.com (Rich Mezirka) Date: Thu, 26 Nov 92 09:24:21 PST To: gnu@cygnus.com Subject: Re: Electronic Banking Message-ID: <9211261718.AA28906@askinc.ask.COM> MIME-Version: 1.0 Content-Type: text/plain IRS regulations related to 1099-b and 1099-misc make it LEGAL providing all parties and the BANK file with the IRS. Bank MUST file when over 100 transactions per year are recirded. Individuals must file each transaction. Add some rules for mandatrory electronic filing when movre than 500 (I think that's the limit) transactions are posted. ZAdd another hassle with mandatory 20% of value must be withheld and filed with IRS inlieu of taxes... (reference 1992 IRS publication on 1099 processing, pages 10-12... pub number available on request)(I left my copy at the office). As I told Tim, this smack s of Al Capone like harassment... "We''' make it WORSE if we catch you" BUT I have personal experience with IRS in 1980, 81, 82 as they attacked barter (I designed and developed software for an electronic settlement system for Trade Systems Corporation in San Jose; we did about 4 million/year unitl the IRS audits startedf and then all big players got tax attacked). for those without experience with our IRS, remember they do not live within our regulary judiciary (innocent until proven guilty) system with open courts... they seize first and have a closed hearing system underwhich you get to negotiate a settlement to get YOUR stuff back, maybe. (references available upon request). They use local marshalls with large guns and IRS judical orededers to tsake what everthey thiink they are due. Again, as I told Tim, we should continue our public discussion of the principles we hold dear and continue our efforts at preventing further erosion. We should also be very careful about stepping on the dragons' tails until we are privacy protected... principlesa nd theorey public, practice and tactics private. spreading the sanity, quietly Rich From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Thu, 26 Nov 92 07:21:57 PST To: tribble@xanadu.com (E. Dean Tribble) Subject: Re: reputation In-Reply-To: <9211260605.AA04591@xanadu.xanadu.com> Message-ID: <9211261521.AA26207@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > filtering based on reputation. Since negative reputation can be > avoided simply by creating another pseudonym, the only reputation that > will make a difference is positive reputation: credibility. What's to stop you (once you have some "reputation") from creating 250 other pseudonyms or "identitites", giving them all a "reputation", and then create another identity, and have these 250 all give this one as much as possible, in effect creating an identity with a lot of "credibility" out of thin air? -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Thu, 26 Nov 92 07:54:44 PST To: cypherpunks@toad.com Subject: Re: PGP on a multiuser system In-Reply-To: Message-ID: <9211261554.AA26688@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > where pgpcompose is a quick hack that looks like: > #!/usr/bin/ksh > > rm /tmp/pgpcompose > vi /tmp/pgpcompose > echo What key? > read key > pgp -mae /tmp/pgpcompose $key > mv /tmp/pgpcompose.asc $1 > exit 0 This is not a very good way of doing this unless this is on a single-user linux system where youhave read all the source, and compiled it yourself. First, if on a multi-user system, what happens if two people run pgpcompose? At the very least, use code like "vi /tmp/pgpcompose.$$", which will append your process ID to the temp file name. It is NOT a good idea to keep the plain text in a disk file, even for a little while. It would be very easy for someone to set up a crontab entry which looks for files of the name /tmp/pgp*, and copies them to a hidden directory. You would never even know that it was happening. If you absolutely MUST do crypto on a multiuser machine, at least try not to keep plaintext or private keys in files. For example, you could instead rewrite the above script to call vi directly on what will become the output cyphertext file. Then the user types in plaintext, and does not save the file. The file (while still only in memory) is piped (!G) through pgp by the user. This is still not very secure, since it would be not too difficult for someone to have a version of vi that saves everything that is piped in a special file. Or pgp may be modified to do the same. Or if you compile pgp yourself every time, the C standard input routines may be modified to do the logging. You get the picture. There is no security on a multiuser system. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Thu, 26 Nov 92 08:04:46 PST To: tony@morgan.demon.co.uk Subject: Why electronic banks should be Redundant & Distributed In-Reply-To: <782@morgan.demon.co.uk> Message-ID: <9211261604.AA26880@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > UK. I think a more real problem with anonymous banking, is not > one of 'trust' in the 'banker' but in his net access. What do you > do when your banker, for whatever reason, becomes unreachable? The best banker deamon would run multiple copies on widely separated hosts/ networks, and keep each other up to date on accounts/balances. They would be logically one entity, by sharing crypto keys. So if one is cut off from the net, or even destroyed, you just send your messages to one of the others. When it comes back up, the others update it with current info. Somewhat similar (not exactly, since they do not communicate to each other) existing system is archie. Imagine that your life or work depended on constant access to archie. When there was only one archie@quiche.mcgill.ca you could have said "What do you do when the archie, for whatever reason, becomes unreachable?". Now that there are many archies, the simple answer is use one of: archie.sura.net (USA, Mexico, etc) archie.mcgill.ca (Canada) archie.funet.fi (Finland/Mainland Europe) archie.au (Australia/New Zealand) archie.doc.ic.ac.uk (Great Britain/Ireland) How likely do you think ALL of these widely separated entities could be simultaneously destroyed/disconnected? -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: mark@coombs.anu.edu.au (Mark) Date: Wed, 25 Nov 92 16:23:55 PST To: cypherpunks@toad.com Subject: Re: Electronic Banking Message-ID: <9211260023.AA11537@coombs.anu.edu.au> MIME-Version: 1.0 Content-Type: text/plain >(A minor note: I ended up doing the Xeroxing for free, which hasn't >yet been declared illegal...though I presume you'll all carefully note >this on your tax returns, as such "barter exchanges" are reportable >income. In theory, which shows how hopeless tax collection is >becoming, all of our "mutual consulting" on this list, and on the Net >in general, is _taxable income_--just as if we were plumbers and carpenters >getting together to work on each other's houses. A crazy system.) So *thats* why nnacct is there :)... Does the tax office get an email from each news admin every fiscal year? :) So they can charge us for services rendered by the net? With regard to digital cash, I have yet to read (or have forgotten the definition) the implementation. What I preceive it as is a form of IOU's that if someone does something for you then you send them an applicable amount of credits. To simplify it a bank could issue credits and people could trade in them, sending them back and forth, each digitally encrypted and based on the amount of credits in each persons bank account. I assume each transaction would be validated through a bank to ensure the credit is unique and the right value? E.g: Customer gets suppliers account number from the supplier encrypted with the banks public key. They send it and the amount of cash to transfer to the bank all encrypted with the public key of the bank. The bank decrypts, gets the amount and decrypts the destination account. It then sends a message to the supplier saying that amount has been deposited in their account and the transaction between the customer and supplier can be completed. Otherwise it tells the supplier (and customer) there is a problem with insufficient funds or incorrect data. The cash may be held in ether until both parties confirm the transaction has been completed. If the commodity is electronic data the supplier may send to the bank a transaction private key encrypted with the customers public key so that the customer cant cheat the supplier as he has to ask the bank for the information to access his/her data which has been encrypted with the other half of the transaction keypair. That way the bank knows the transaction has been completed and it finishes the transfer of funds and sends the transaction private key to the customer. Each commodity, especially if it was physical might be serialized so there could be proof that the customer purchased that item with that SN. If the merchant was a crook the audit trail would catch him... the customer wouldnt be able to cheat as the merchant wouldnt have to release the goods (as is the situation now in Real Life (tm)) until the funds were paid. Issues of Big Brother spying on your transactions apply here but I guess one could always use a psuedonym for the electronic commodities and a postal box paid for with digital anonymous cash for the physical stuff.. (assuming it was mail order... you wont have to give a name for store buying, just a bank public key and your encrypted account number.) Someone might even want to set up a physical forwarding company which merely acts as a buffer for people to increase their privacy. Paid for anonymously and digitally. I havent heard of any companies specialising in this type of service to date. This make any sense? Has it been said before? Mark mark@coombs.anu.edu.au From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Thu, 26 Nov 92 11:44:30 PST To: cypherpunks@toad.com Subject: Cypherpunks List (fwd) Message-ID: <9211261940.AA15763@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Cypherpunks, Happy Thanksgiving! I sent the following message to the "Extropians" list, a list centered around discussions of politics, technology, the future, "uploading," transhumanism, and the like. (As with our list, they can be subscribed to with the "-request" form. Several requests for more information about our list prompted me to write this summary piece. Inasmuch as our existence has been publicized in Mondo, on alt.hackers, and in various references in messages, I felt it appropriate to tell them a few things about what the list is about. Our address is at the very end of the article, so there's a minor obstacle for truly casual readers to overcome. I'm forwarding it to you folks because we've had a lot of new subscribers ourselves, and they may like to hear some of this stuff. I apologize to those who are getting this twice. -Tim May Forwarded message: To: Extropians@gnu.ai.mit.edu From: tcmay@netcom.com (Timothy C. May) Subject: Cypherpunks List Date: Thu, 26 Nov 92 10:51:01 PST The Cypherpunks List -- A Thanksgiving Message I guess it's time to say a few words about the "Cypherpunks" list, which I've referred to several times in the last few months. Eric Hughes, the list administrator and initial organizer of our first meeting, has also mentioned the group in several places, and the latest "Mondo 2000" actually gives the address, so the information's pretty much out by now. We've avoided the "cattle call" form of invitation, where public announcements are made and subscribers flood in. But we also haven't gone to the other extreme of requiring some puzzle to be solved (as with posting to "alt.hackers," which usually requires some hacking of the posting software to "get in.") Cracking a cypher is not a requirement, though some probably think it should be. A few points: * The name "Cypherpunks" started out as a pun by Jude Milhon, an editor at "Mondo 2000," when she said "You guys are just a bunch of cypherpunks!" We initially debated calling our informal group something more staid like "The Cryptography Research Society," partly to protect ourselves by emphasizing the "research" aspects, but the joke name stuck. So, like it or not, it's "Cypherpunks." It turns off some, turns on others. C'est la vie. * Note that we have very little to do with the Gibsonesque vision of punked-out outlaws and virtual reality escapades, though in fact some of our members are active in Bay Area start-up companies doing VR. I would say Vernor Vinge's "True Names" is more descriptive of what we're doing. * About a hundred or so folks are on the list, including some journalists (gulp!), and even some "*.mil" sites (!!). But since what we're doing is strictly "research," we are of course safe. * The focus is on cryptology, anonymous remailers, hardware support, PGP, digital cash, "dining cryptographers" nets, and so on. Too much to recapitulate here. * By focussing on "research" into these areas, we feel we are safe against attack by government agencies. Time will tell. These issues of security, privacy, remailers, digital pseudonyms, etc., are hot topics in the crypto community, and all we are really doing is applying these ideas and doing experiments, the better to learn. (Some of the work on "webs" of trust in PGP systems, on issues with anonymous remailers, and on the development of "digital reputations" lies in uncharted territory, that is, we're doing true research.) * Several Extropians are active on the list, as you may have gathered from cross-posts and comments. * Because many of the early members live in the Bay Area (Northern California, Silicon Valley), we've had three physical meetings so far. John Gilmore, a founder of Cygnus Support, has graciously offered his facilities for our meetings, which typically happen on Saturday afternoons. The schedule gets posted on the list, of course. * Some exciting progress has already been made. Eric Hughes and Hal Finney have implemented a PERL-scripted remailer which provides anonymous forwarding (though the security is only "manual"), and 2-way remailers with digital pseudonyms seem imminent. Integrating PGP into mailers remains a problem, as those of you who use PGP already know, and several of our members are working with the PGP and MacPGP teams. * "Crypto dongles" to attach to RS-232 ports are being pursued by Yanek Martinson (an Extropian as well), George Gleason, John Draper ("Cap'n Crunch"), and others. Lots of enthusiastic debate. * FIDONet users are also involved, including Tom Jennings, the founder of FIDONet, in 1984. This brings an exciting new flavor for most Internetters. * Like the Extropians list, the Cypherpunks list is relatively free from flames and personal attacks. We all realize we're interested in roughly the same goal, even though some are Libertarians (naturally) while others are Socialist, Marxists, and Act Up! activists. (Interestingly, we've never had any real flames on politics. We almost never argue political views. This may of course be alien to readers of the Extropians list! :-} ) * So why isn't the list sent out in encrypted form? A little thought will reveal the uselessness of encrypting a widely distributed list that's essentially open to anyone who sends in a request! Still, there is some talk of encrypting in the future, partly to weed out the casual readers (for whatever reason) and partly to just get the volume of encrypted messages up. If you've read this far, and are really interested in joining the list, send a request to "cypherpunks-request@toad.com". This is standard list procedure, of course. But please don't then complain about the list volume! --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: jdugger@reed.edu (Jay Dugger) Date: Thu, 26 Nov 92 13:06:13 PST To: cypherpunks@toad.com Subject: Subscription Message-ID: MIME-Version: 1.0 Content-Type: text/plain Sorry about the bandwidth waste, but please subscribe me. ------------------------ Jay Dugger jdugger@reed.edu ------------------------ PGP Public Key available From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: gnu Date: Thu, 26 Nov 92 13:40:36 PST To: Richard Childers Subject: Re: chip verification ( Was: Tollhouse Cookies :-) In-Reply-To: <9211260206.AA08221@rchilder.us.oracle.com> Message-ID: <9211262140.AA12038@toad.com> MIME-Version: 1.0 Content-Type: text/plain > It seems to me that an ostensibly digital device with a fixed number > of pins could be regarded as a finite state system, and systematically > analyzed accordingly, IE, traverse the set of possible combinations of > pins and signal levels and verify that it behaves in accord with pub- > -lically available specifications. This is not useful, because devices can have internal state. For example, a device could do the same thing in response to an input for 1000 times, and then do something different when a counter reaches 1001. I've been employed writing test vectors for chips. It *is* possible to write a set of tests that will verify that a piece of hardware matches its design (which, BTW, is software, stored on a disk in a database). Every chip vendor does this on every chip they make, to detect manufacturing defects. These tests will not detect hardware that has been deliberately modified to pass the tests, but to do something different in actual operation. This is an obvious risk when the tests are necessarily publicly available. Of course, if a particular form of modification is suspected, people can write new tests that look for it. But it becomes like the virus protection game: looking for the signatures of known viruses doesn't protect you from unknown ones. There's no proven way to detect all modifications. John Gilmore PS: See also Ken Thompson's paper, "reflections on trusting trust", which was published as an ACM Turing Award lecture among other places. Your CAD software could have been modified so that it inserts a mod into your chip that doesn't appear in the chip's source code. The compiler used to build the CAD software could've been modified to insert the above mod into your CAD software binaries as they are compiled. A compiler binary used to build the *compiler* sources into binaries could have been modified to insert the compiler mod described above. Even if you have full sources, you can't trust the system -- you have to trust the people who bootstrapped it, and all the people who wrote the tools *they* used. "Proving" anything becomes very slippery here. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Thu, 26 Nov 92 11:57:16 PST To: nobody@alumni.cco.caltech.edu Subject: Re: your mail In-Reply-To: <9211260713.AA01656@alumni.cco.caltech.edu> Message-ID: <9211261956.AA02380@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > If you want to do this, it is a simple matter of building a large > enough cooperative group. > > How big? Well bigger than the Hells Angels, Maybe a thousand > people. I don't know. Depends on how rough it gets. Right now the list has 168 individual subscribers. Plus, there are 6 gateways to local redistribution lists. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Thu, 26 Nov 92 15:08:58 PST To: rchilder@us.oracle.com Subject: Re: chip verification ( Was: Tollhouse Cookies :-) Message-ID: <199211262305.AA20384@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain John Gilmore points out that in hardware, "proving anything becomes very slippery..." Seems to me that we can establish degrees of confidence, in much the same way as pertains to social sciences research: probabilities that a given result is accurate. So for instance, we could say that a device made with parts purchased randomly for cash over the counter at a number of different suppliers, might have a lower probability of compromise than one made with parts mail-ordered from the same large supplier to the producer's workshop every time. Over time it may be possible to quantify the measure of confidence. -gg. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: phr@napa.Telebit.COM (Paul Rubin) Date: Thu, 26 Nov 92 16:04:18 PST To: crunch@netcom.com Subject: Mac PGP report and Rander progress In-Reply-To: <9211260933.AA04417@netcom2.netcom.com> Message-ID: <9211270003.AA20577@napa.TELEBIT.COM> MIME-Version: 1.0 Content-Type: text/plain Has anyone given any thought to generating random numbers by counting particle emissions from a radioactive source? This might be more reliably random than using purely electronic means. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: karn@qualcomm.com (Phil Karn) Date: Thu, 26 Nov 92 23:06:08 PST To: cypherpunks@toad.com Subject: The NSA Backs Down!! Message-ID: <9211270705.AA06258@servo> MIME-Version: 1.0 Content-Type: text/plain r a AM-DeclassifiedCodes 11-26 0287 ^AM-Declassified Codes,0266< ^Government Reverses Itself, Declassifies Studies On Secret Codes< SAN FRANCISCO (AP) _ The National Security Agency has reversed itself and declassified two cryptography texts it previously had insisted were secret even though they were available in public libraries. The announcement Wednesday came as a result of a lawsuit filed under the Freedom of Information Act by a Silicon Valley computer scientist who believes private companies should have more access to secret code technology. The analyst, John Gilmore, asked the spy agency to declassify the 50-year-old studies on encryption _ the science of designing codes. The U.S. Department of Justice recently had threatened to prosecute Gilmore under a 1950s espionage law if he distributed copies of the texts. In court papers, an NSA official said disclosure of the information could seriously damage national security. The agency is in charge of protecting U.S. codes and cracking foreign ones. Gilmore is a board member of the Electronic Frontier Foundation of Cambridge, Mass. The organization believes now-secret encryption technology is necessary for private companies to make modern computer and telephone systems secure from tampering. ``Why shouldn't an American citizen be able to go to the library and teach himself about encryption?'' asked Michael Godwin, a staff counsel at the foundation. Gilmore said he found copies of the once-declassified studies, made secret again by the Reagan administration, in public libraries. They presently are used as texts in military classes. He said he plans to distribute 20 or 30 copies to other libraries. The studies are about 1,000 pages long. AP-DS-11-26-92 1837EST< From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Fri, 27 Nov 92 00:30:10 PST To: cypherpunks@toad.com Subject: (fwd) 8052-Based Crypto Engine Message-ID: <9211270825.AA03153@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain I just found this is sci.crypt. It may be useful for the "crypto dongle" folks. --Tim May Newsgroups: sci.crypt,comp.arch Subject: 8052-Based Crypto Engine From: mmm@cup.portal.com (Mark Robert Thorson) Date: 27 Nov 92 06:50:33 GMT Here is the text from a press release which landed on my desk yesterday: A new microcontroller from Philips Semiconductors-Signetics designed for use in smart-card applications is the first to incorporate an on-chip arithmetic unit optimized to calculate public-key cryptography algorithms widely used in commercial transactions. The 83C852 CMOS microcontroller can be embedded in plastic smart cards and provides 2K bytes of on-chip EEPROM for program and data storage accessed under control of the unit's CPU. "The new microcontroller removes the barrier to smart-card use in applications where data security is a concern," said Thomas Brenner, product manager. "There is strong interest in using smart cards, for example, in medical insurance or remote banking transactions. But in such applications a high level of data security is indispensable," he said. "Likewise the need for secure access codes is a primary consideration for customer-card use in the Pay TV and cellular phone markets." The on-chip arithmetic unit running in parallel with the CPU can complete a 512-byte calculation in less than 1.5 seconds versus more than a minute to do the calculation in software. This high-speed performance makes it feasible to use highly secure and complex public-key cryptography algorithms in everyday transactions. Asymmetric, public-key cryptography uses one key to encrypt and another to decrypt so that only one of the keys need be kept secret. The other can be freely distributed. The method is thus highly applicable to commercial transactions. The 83C852 microcontroller is based on the industry-standard 8-bit 80C51 processor core and uses the same instruction set. The circuit incorporates 6 Kbytes of ROM and 256 bytes of RAM in addition to the 2 Kbytes of EEPROM. The EEPROM provides automatic hardware error correction for single-bit errors in any of the stored data bytes. After customer software is loaded, electronic fuses in the array can be blown to limit access to processor fetch commands. The address bus is mixed to provide further protection against fraudulent access and optical scanning, and a low-frequency detection circuit can guard against external tampering. The new processor operates from a single 5-volt supply at clock frequencies up to 6 MHz (1 microsecond instruction cycle). All voltages required during programming or erasure of the EEPROM are generated on chip. Nonvolatile data retention is for ten years and the circuit offers an infinite number of read cycles. The microcontroller includes a power-on/off reset circuit, and idle and power-down modes. The microcontrollers can be ordered as a wafer, die on foil or in SO-28 small-outline packages. The SO package is available for smart-card readers and can function as an embedded security module in systems such as restricted access computers. Wafer and die-on-foil versions of the 83C852 smart card microcontroller are available now at a unit price of $5.10 and $5.20 respectively in 10,000 quantites. Units in SO-28 packages will be available in first quarter 1993 priced at $6.85 in the same quantities. CONTACT: Thomas Brenner (408) 991-3552 He's with Philips-Signetics. I have no affiliation with them, so don't contact me about this part. If you call Tom, be sure to tell him you heard about the chip from MARK THORSON on USENET. If enough people do this, maybe they'll give me a free development system. (On the other hand maybe they'll tell me "Please don't post any more of our press releases on Usenet." :-) -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: efrem@informix.com (Efrem Lipkin) Date: Fri, 27 Nov 92 01:57:06 PST To: cypherpunks@toad.com Subject: credibility & pseudonyms Message-ID: <9211270916.AA25959@godzilla.informix.com> MIME-Version: 1.0 Content-Type: text/plain I have this persistent image of what a great boon all these encrypted networks will be for undercover work. Currently when some species of cop or spy goes undercover they take on a nearly full time acting job. They have to work for a long time to establish their credentials and throughout the process are usually in significant physical danger. I vaguely remember (the details are probably wrong) some Isreali spy got as far as the position of Minister of Defense in Jordan before he got hung. With digital signatures a dozen secretaries could run a hundred or more pseudoagents, build a solid reputation for each over years. The same approach would work for a patient con man. Real credibility has to be tied to a physical body. Some thing at risk. --efrem From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: cordones@IMAGE.CS.NYU.EDU (Deus Ex Machina) Date: Thu, 26 Nov 92 23:21:34 PST To: cypherpunks@toad.com Subject: Re: Returned mail: User unknown Message-ID: <9211270719.AA20772@IMAGE.CS.NYU.EDU> MIME-Version: 1.0 Content-Type: text/plain So..any courageous Cypherpunk that can post those papers or tell us what to look for in a library? (anonymous post, whatever). ----------- El Zorro. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: donb@netcom.com (Don Bellenger) Date: Fri, 27 Nov 92 08:30:05 PST To: cypherpunks@toad.com Subject: Cypher Bank Message-ID: <9211271625.AA08403@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Does anyone know of a law, rule, regulation, or other restriction that would prohibit the establishment of a simple cypher based bank? I can think of 3 basic areas that would have to be satisfied: 1. Federal law and agencies, Federal Reserve, etc.. 2. State and local (California for me). 3. Internet "Appropriate Use" policy. If the bank is operated on a not-for-profit basis --as an experiment. Then that should satisfy the appropriate use requirement. I could use some comments if anyone can cite specific federal or California regulations. Please respond either to me directly, donb@netcom.com, or to this mail list. -------- The cypher bank would work like this: I would publish my physical address; and offer to accept deposits by cash, check, or what have you. With the deposit, write on it your PGP handle. Email me your public key corresponding to the handle on the deposit. I will maintain a public list showing handles vs. Amount received, in collection, and in escrow.(Set Subject = "BANK" to get the list) Funds will be paid out based on instructions encyphered with your private key. Comments would be appreciated. Don Bellenger donb@netcom.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tony@morgan.demon.co.uk (Tony Kidson) Date: Fri, 27 Nov 92 08:56:24 PST To: cypherpunks@toad.com Subject: Re: Mac PGP report and Rander progress Message-ID: <842@morgan.demon.co.uk> MIME-Version: 1.0 Content-Type: text/plain In message <9211270003.AA20577@napa.TELEBIT.COM> you write: > Has anyone given any thought to generating random numbers by counting > particle emissions from a radioactive source? This might be more > reliably random than using purely electronic means. > I don't think that for any given length of random bit string, you'd be practically happy carrying around a suitable source. Thermal noise, which is what you get from a diode, is just as good a random source as radioactive decay. Tony ------------------+-------------------------------+--------------------------+ | Tony Kidson |`morgan' is an 8MB 486/33 Cat-| Voice +44 81 466 5127 | | Morgan Towers, |Warmer with a 670 MB Hard Disk.| E-Mail | | Morgan Road, |It resides at Morgan Towers in| tony@morgan.demon.co.uk | | Bromley, |Beautiful Down Town Bromley. | tny@cix.compulink.co.uk | | England BR1 3QE | -=<*>=- | 100024.301@compuserve.com| +=================+===============================+==========================+ From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: donb@netcom.com (Don Bellenger) Date: Fri, 27 Nov 92 08:55:12 PST To: cypherpunks@toad.com Subject: ping Message-ID: <9211271651.AA09053@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain This is a test. I am seeing mail rejected due to mail spool full @ newschool. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: donb@netcom.com (Don Bellenger) Date: Fri, 27 Nov 92 09:20:12 PST To: cypherpunks@toad.com Subject: List is partially broken Message-ID: <9211271715.AA20966@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain The message below was received in response to a ping sent to this list. However I know that it got some distribution because Yanek answered it. donb@netcom.com Forwarded message: > From Mailer-Daemon Fri Nov 27 09:03:27 1992 > Message-Id: > From: Postmaster@newschool.edu > To: donb@netcom.com > Subject: Rejected Mail > Date: Fri Nov 27 12:05:03 1992 > > > Unable to deliver message because: > > @ : Insufficient Disk Space > > Returned Text follows > ------------------- > Received: From relay2.UU.NET by newschool.edu > via Charon 3.4 with SMTP id 102.921127120528.384; > 27 Nov 92 12:04:51 +0500 > Received: from toad.com by relay2.UU.NET with SMTP > (5.61/UUNET-internet-primary) id AA03427; Fri, 27 Nov 92 11:56:15 -0500 > Received: from netcom2.netcom.com ([192.100.81.108]) by toad.com id AA01076; Fri, 27 Nov 92 08:55:12 PST > Received: by netcom2.netcom.com (5.65/SMI-4.1/Netcom) > id AA09053; Fri, 27 Nov 92 08:51:00 -0800 > Date: Fri, 27 Nov 92 08:51:00 -0800 > From: donb@netcom.com (Don Bellenger) > Message-Id: <9211271651.AA09053@netcom2.netcom.com> > To: cypherpunks@toad.com > Subject: ping > > This is a test. I am seeing mail rejected due > to mail spool full @ newschool. > > -- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: hughes (Eric Hughes) Date: Fri, 27 Nov 92 10:48:33 PST To: cypherpunks Subject: Welcome message for cypherpunks-announce Message-ID: <9211271848.AA03598@toad.com> MIME-Version: 1.0 Content-Type: text/plain We've created a secondary list, cypherpunks-announce@toad.com. If you want to keep in touch, but don't want the volume of mail the full list produces, get yourself switched over. And remember not to post such requests to the whole list. Thanks. The welcome message follows. Eric ----------------------------------------------------------------------------- Date: Fri, 27 Nov 92 10:44:31 PST From: hughes@toad.com (Eric Hughes) To: cypherpunks-announce Subject: Welcome Welcome to the cypherpunks-announce list. This is a low-volume list for announcements, news, and meeting schedules. It is not a digest. It is moderated by Eric Hughes, also the maintainer of the full list. Each of you has at some point been on the full list and asked to be dropped for mail volume. If you really don't want to be even on the announce list, send mail to cypherpunks-announce-request@toad.com and ask to be removed from the announce list. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: daver@tfs.COM (Dave Robison) Date: Fri, 27 Nov 92 13:15:47 PST To: cypherpunks@toad.com Subject: ... Message-ID: <9211271916.AA18212@ts2.TFS.COM> MIME-Version: 1.0 Content-Type: text/plain please remove me from this list. as interesting and important as i think the discussions are, i cannot keep up with the volume of mail. thanks. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: cordones@IMAGE.CS.NYU.EDU (Deus Ex Machina) Date: Fri, 27 Nov 92 09:01:18 PST To: cypherpunks@toad.com Subject: Re: ping Message-ID: <9211271659.AA21574@IMAGE.CS.NYU.EDU> MIME-Version: 1.0 Content-Type: text/plain Me too. In fact, I am insecure my message ever got through because no one has said anything about it. It was regarding "The NSA backsdown". I was asking how could point me to thse so called "secret" documents that are available at some libraries. Did that get through Boys? Thanks From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Fri, 27 Nov 92 10:22:36 PST To: donb@netcom.com (Don Bellenger) Subject: Re: list broken (NOT!) In-Reply-To: <9211271715.AA20966@netcom.netcom.com> Message-ID: <9211271734.AA24635@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > The message below was received in response to a ping sent > > From: Postmaster@newschool.edu > > To: donb@netcom.com > > Subject: Rejected Mail > > > > Unable to deliver message because: @ : Insufficient Disk Space This does not mean that the list itself is broken, only one (or a few) recipients have problems. You would have a cause to worry if you received a rejection message from toad.com. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Fri, 27 Nov 92 10:25:55 PST To: donb@netcom.com (Don Bellenger) Subject: comments on Don's "Cypher Bank" In-Reply-To: <9211271625.AA08403@netcom2.netcom.com> Message-ID: <9211271825.AA25349@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > address; and offer to accept deposits by cash, check, or what have > you. With the deposit, write on it your PGP handle. Email me your > public key corresponding to the handle on the deposit. A better way would be to mail the public key itself, or a short hash of it along with your payment. That is all the information that would be required. A "handle" would be completely optional. If only the hash value is mailed, then the full key can be e-mailed or anonymously posted to a newsgroup that you montitor. If the full key is mailed, you should invest in a scanner and some simple OCR software. This way, someone may print out the public key and mail it to you. > I will maintain a public list showing handles vs. Amount received, > in collection, and in escrow.(Set Subject = "BANK" to get the list) You should not disclose someone's balance to anyone else, and certainly no to the public. Someone requesting their balance should send the request by any communications channel (anonymous mail, newsgroup, anything) and sign it with the private key corresponding to the public key used when making the deposit. Then you should encrypt your reply (the account balance & any other info) using the public key, and send it back through any channel. > Funds will be paid out based on instructions encyphered with your > private key. I would make it: funds will be transferred based on instructions _signed_ with the private key corresponding to the public key used for deposit. P.S. this would be equivalent to digital checking accounts. Do not confuse this scheme with the much more interesting Digital Cash ideas. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: donb@netcom.com (Don Bellenger) Date: Fri, 27 Nov 92 13:33:24 PST To: cypherpunks@toad.com Subject: More cypher bank Message-ID: <9211272129.AA26164@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain No one else's account would be disclosed except to the owner. Handle, hash, or the full key itself is all the same. The point is that some shortened identifer is needed. This is not a technical matter, the customer can cook up anything he wants, There is no relation to the mechanics of PGP, I don't want to bother scanning in and verifying long strings of codes, and I need some short I.D. so the owner can identify his balance for verification (checking balances). There are obviously plenty of fancy variations on this, and I would be happy to set up whatever any body wants. Maybe the easiest way is to setup mail addresses for each depositor of the form: handle_of_depositor@digibank.com. So send signed email to that address, and I will respond with your balance. A couple of other addressees would be used for overall bank status report, and current operating rules. The digital cash account is represented by the escrow balance. If Sam wants me to take his collected funds and turn them into digi-cash, I can sign a voucher that I have segregated X amount of Sam's money into an escrow account pending receipt of the digi-cash voucher and instructions to move the escrow amount elsewhere. This is all that any bank is going to do. Basically, this looks like a very good thing to do. If handled properly and within the banking regulations, it could be a great advance. Does anybody here remember pre-ATM days? Standing in line at the bank to get cash? In 3rd world countries they don't even have checking. This means you have to walk around every month and pay your bills in cash. I haven't been in a bank in years since the ATMs came in. And this is at another, much higher level of abstraction. > > > address; and offer to accept deposits by cash, check, or what have > > you. With the deposit, write on it your PGP handle. Email me your > > public key corresponding to the handle on the deposit. > > A better way would be to mail the public key itself, or a short > hash of it along with your payment. That is all the information that > would be required. A "handle" would be completely optional. > If only the hash value is mailed, then the full key can be e-mailed > or anonymously posted to a newsgroup that you montitor. If the full key > is mailed, you should invest in a scanner and some simple OCR software. > > This way, someone may print out the public key and mail it to you. > > > I will maintain a public list showing handles vs. Amount received, > > in collection, and in escrow.(Set Subject = "BANK" to get the list) > > You should not disclose someone's balance to anyone else, and certainly > no to the public. Someone requesting their balance should send the > request by any communications channel (anonymous mail, newsgroup, anything) > and sign it with the private key corresponding to the public key used > when making the deposit. Then you should encrypt your reply (the account > balance & any other info) using the public key, and send it back through > any channel. > > > Funds will be paid out based on instructions encyphered with your > > private key. > > I would make it: funds will be transferred based on instructions _signed_ > with the private key corresponding to the public key used for deposit. > > P.S. this would be equivalent to digital checking accounts. Do not confuse > this scheme with the much more interesting Digital Cash ideas. > > -- > Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek > this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred > Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood > (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 > > -- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Fri, 27 Nov 92 10:46:45 PST To: cordones@IMAGE.CS.NYU.EDU (Deus Ex Machina) Subject: Re: ping..mailing list integrity.. In-Reply-To: <9211271659.AA21574@IMAGE.CS.NYU.EDU> Message-ID: <9211271846.AA25768@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > Me too. In fact, I am insecure my message ever got through because no one > has said anything about it. It was regarding "The NSA backsdown". I was > asking how could point me to thse so called "secret" documents that are I have not received it. It may have just been a local network problem on your side. But it may also have been covert action (if you are paranoid enough to believe it). I have an idea how we could make it possible for eveyone to be SURE that their message to the list actually went out; and also they could be certain that they have not missed any list messages. This is very important for people with unreliable or untrusted e-mail connections. The idea is: whenever cypherpunks@toad.com receives a message, it would append the From:, Date:, and Subject: headers to a file, thus creating an index of messages passing through the list. At the end of each day, the file would be mailed out to the list. So if you posted a message, you could check in the evening if it got out or not. If you are not sure if you are receiving all the messages, you could maintain a simlar file yourself, and at the end of day compare your notes with what is received from the list. This should not be difficult to set up at all. This could be later improved in several ways. First, the message could be signed by the list administrator (in case you think your mailfeed is filtering what you receive, and is also removing these items from the index). These indexes could be kept for a week or so, and either only the lists, or maybe even any of the individual messages that may have been missed could be requested via a mailserver. This could work similarly to the CRYOMSG: facility of the Cryonix mailing list. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: karn@qualcomm.com (Phil Karn) Date: Fri, 27 Nov 92 15:05:14 PST To: cypherpunks@toad.com Subject: Re: How far is to far? Message-ID: <9211272304.AA09837@servo> MIME-Version: 1.0 Content-Type: text/plain I must concur with George Gleason's remarks about "sneaking around in the shadows of legality". I find myself getting a little uncomfortable with some of the more anarchistic ideas expounded in this and similar groups. My interest in cryptography is very simple. I'm not interested in overthrowing the government by force. Although I find "digital cash" to be an interesting concept worthy of pursuit at least as an academic exercise, I'm not trying to evade income taxes, establish an underground economy or conceal criminal activity. And although I do believe that drugs, gambling, prostitution and other vices ought to be legalized on both practical and philosphical grounds, I am not particularly interested in using cryptography to protect the lowlifes who inhabit these professions. I am *very* interested, however, in cryptography's enormous potential to protect individual privacy. With widely available strong cryptography, the average individual will finally have the technical means to draw a tight circle around the private aspects of his or her life. The individual need let no one, especially the government, enter without his or her permission. Until now, we have had to depend entirely on the goodwill of government to respect and obey those provisions of the Bill of Rights that deal with privacy. Often this "good will" has been sadly lacking. But now we can finally put some real teeth into the guarantees of the First, Fourth and Fifth Amendments. If you want to plot political strategy for an upcoming election, or if you want to talk to your attorney about some legal action, or even if you just want to discuss your sex life with your spouse or SO, cryptography can guarantee you an unprecedented degree of privacy. Just as good fences make good neighbors, we may well find that in the hands of the people, good cryptography will make for good government. That's why I find cryptography so interesting, and that's how we should sell it to the public. Phil From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: karn@qualcomm.com (Phil Karn) Date: Fri, 27 Nov 92 15:53:20 PST To: cypherpunks@toad.com Subject: More comments on dongles Message-ID: <9211272352.AA09880@servo> MIME-Version: 1.0 Content-Type: text/plain George Gleason says "I believe that carrying out the entire crypto operation in the dongle is preferable to having it only do the secret key RSA processing" and argues for this position mainly on the basis of host compatibility issues. I still disagree. Even if all the crypto operations were done in the dongle, it wouldn't be a "turnkey" device that could operate totally automatically. You'd still need a way for your host computer to turn it off and on, to select a public key for encryption or signature verification, to load new public keys, etc. I.e., you'd have to run special driver software on the host anyway. So why not limit the dongle to the specific purpose for which it was designed (protecting your RSA secret key) and do the less sensitive operations where memory and cycles are far more plentiful, i.e., on the host? Limiting the dongle's function to RSA secret key operations also minimizes the dongle's communication requirements. The only data you'd have to send to it in normal operation would be short blocks to be run through your RSA secret key operation, a heavily compute-bound process. If I want to decrypt a file, I'd send the dongle the IDEA (or DES) key that had been encrypted with my public key. Once the dongle responds with the decrypted IDEA key, I can perform the actual IDEA decryption on my host computer with no further dongle interaction. Regardless of the file size, this would go at host CPU and/or disk speed, not the speed of the port that's talking to the dongle. Similarly for signing -- the MD-5 hashing of the file would proceed at near disk speed (since MD-5 is so fast) and only the resulting hash code would have to be passed to the dongle for the RSA secret key step. A palmtop DOS machine like the HP-95 or Atari Portfolio would make a good platform for a prototype dongle. Most have serial ports (standard or optional), and you could just plug them into a spare serial port on a PC (again, speed is not critical). The palmtop's keypad would be used to control the dongle, e.g., by accepting a pass phrase to decrypt the stored copy of your RSA secret key, so you wouldn't have to type it into a possibly compromised PC. And they're small enough to carry around with you, thus making it harder for somebody to hack. The only drawback I can see to all of this is that palmtops are not exactly speed demons, and RSA secret key operations are pretty slow to being with (much slower than the public key operations, which are less sensitive). But secret key operations are the heart of RSA, so you don't have much choice if you want real security. Since it is a sensitive step, RSA key generation could also be done on the palmtop (although it would probably take hours) or it could be done on an external, trusted PC and loaded into the palmtop. If your main reason for using the dongle is to limit the trust you have to place in a borrowed PC (as opposed to protecting against your own home PC being hacked), this may be a reasonable thing to do. Another idea just occurred to me. If you have a trusted machine (e.g. your home PC) available to you over the net, you could use it as a "remote dongle". You'd send it data to be run through the RSA secret key operation and it would return it. Obviously, to be secure the network exchanges would have to be encrypted in both directions, otherwise anybody could either pick up the "remote dongle's" responses or worse, send it data of his own choosing. A simple symmetric cipher (IDEA, DES) would be adequate here since you control both ends of the link. The main drawback of this approach (other than the need for network connectivity) is the physical vulnerability of your unattended home PC. Phil From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: donb@netcom.com (Don Bellenger) Date: Fri, 27 Nov 92 17:11:14 PST To: cypherpunks@toad.com Subject: Re: Random numbers Message-ID: <9211280107.AA08614@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain > > > > It has lately been discussed different ways to construct pure > > random number generators by means of radiactive decay. I must admit > > that this is a very good way to produce such numbers, but for a > > number of reasons it is impractical to use such a device. (High > > radiation levels are needed too produce a significant amount of data.) > > > The way to make good random numbers is to take about 20 stages of flops > and feedback 2 or three terms. Clock the thing as fast as you can, Say > 50 mhz, and asychronously to your main processor clock. The shift register > needs its own crystal. The selection of feedback points is based on > Linear Congruential Method of Pseudo random numbers generated by most > machines. > > The numbers generated are very, very uniform. > > The way to test random number generators for randomness is to generate > the numbers in pairs and plot them on a scatter plot. This simple > cross check will show up many poor generators. Checking for uniform > density in higher dimensions will uncover even more subtle variations > from uniformity. There is an enormous literature on this topic. Obviously > you can screw it up, but it isnt that hard to get right either. There > is an excellent book just out on simulations that covers this. If > anyone wants the reference, I can dig it up. > > Bottom line is that you don't need anything exotic. But the 8 or simple 16 > bit methods on the small processors are no good. > > Don Bellenger > donb@netcom.com > > > > > > -- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Fri, 27 Nov 92 18:34:33 PST To: cypherpunks@toad.com Subject: Re: Random numbers Message-ID: <199211280233.AA21798@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Vanguard's posting about a friend of his in the Air Force telling him some things about Air Force crypto devices may be of some theoretical interest, but posting it here really gets me majorly uncomfortable. Current military crypto practices are probably very highly guarded secrets. Posting that kind of thing, even in a general way, could be very dangerous; if not to national security then at least to ours. I'd like to ask we have a general agreement to not post things which may be classified. No point giving the govt a good excuse to stop our R&D projects cold. -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: karn@qualcomm.com (Phil Karn) Date: Fri, 27 Nov 92 18:49:41 PST To: yanek@novavax.nova.edu Subject: Re: More comments on dongles Message-ID: <9211280249.AA10136@servo> MIME-Version: 1.0 Content-Type: text/plain >The way I envision it, the host must NOT have the ability to turn it on >or off or do any of the other things you mentioned. The assumption is >that you DON't trust the host. If you don't trust the host, then why are you running your plaintext through it? As I said earlier, my decision whether to trust a particular machine depends heavily on how much I would lose if that trust were abrogated. I might be willing to take the chance that this particular borrowed or public PC has been hacked if the worst that can happen is that the only slightly sensitive plaintext I'm working on at the moment is compromised. Heck, I might even be signing or decrypting totally public information, just to help raise the amount of encrypted traffic on the net. In this case I might not care at all if my plaintext is secretly recorded or sent somewhere. But I would probably NOT be willing to trust the same PC with my secret key, because it would compromise EVERYTHING I have ever protected (or will protect) with that secret key. Including THE most sensitive stuff I might have, the plaintext to which I might entrust only to a RAM disk on my own home PC. Do you understand the distinction here? >So if the host does not even need to know the dongle exists, it is >automatically independent of what type of computer, operating system, >communications program or terminal you are using. I seriously doubt this will be practical, even with constant interaction with the dongle's keyboard. Most palmtop keyboards are a real pain to use, so I would definitely prefer to limit my use of it to truly sensitive things, like typing in my pass phrase to decrypt my RSA secret key, or perhaps hitting a key to re-enable the device after every N secret key operation requests from the host, or to restart a timer that would otherwise exit the program and clear RAM after a timeout in the event the device is lost or stolen. >Again, you are trusting the host. What if the decryption program on >the host has been modified to quietly write the plaintext to a hidden >file. As I said earlier, your "fully-functional dongle" fails to prevent this attack. If it sits on a serial port between your possibly hacked PC and the outside world, then it clearly must pass decrypted plaintext to the PC where it could still be quietly written to disk. >Once the host decrypts the file (at a high speed, as you say), you want >to view the file, right? That means the plaintext is transmitted from >the host to you. Anywhere in the link (which could be a simple RS-232 >connection, or a chain of network links, modem connections, etc., >someone may be watching. With my design, the decryption takes place at >the very last step, just before showing up on your screen. Eh? The model I have is a local PC, possibly hacked, with a serial port connected to my personal dongle sitting right beside it. Obviously it would not do to have an insecure link between the PC and the dongle (unless you had encryption on that link, as I suggested in the case of using a remote machine in place of the dongle.) It should be fairly hard to inject your own traffic on my 1-foot RS-232 link, especially if I provide my own cable. >I have thought of that too. I would need one with two serial ports >though. If you know of a good, cheap (can something have these two >properties simultaneously? :-) notebook computer with (option of?) two >serial ports, please let me know. The "basic dongle" would only need one RS-232 port, and it would not have to be fast. This is a definite advantage. >That is just one of the reasons. The others are convenience, lack of >trust in the host or the network, use of a terminal (which can't run any ^^^^^^^^^^^^^^^^^ This is the one valid reason I can see for your approach. But dumb terminals are getting pretty rare these days, at least in the places I hang out. Phil From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Fri, 27 Nov 92 19:58:40 PST To: cypherpunks@toad.com Subject: re: Re: How far is to far? Message-ID: <3920.2B16E302@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain U> From: karn@qualcomm.com (Phil Karn) U> I must concur with George Gleason's remarks about U> "sneaking around in the shadows of legality". I find U> myself getting a little uncomfortable with some of the U> more anarchistic ideas expounded in this and similar U> groups. I agree, even though I'm interested in uses of encryption other than privacy, implementation of privacy systems is a baseline to a lot of it, and the other stuff drags us off topic... --- ReadMail * Origin: tomj@fidosw.fidonet.org / World Power Systems (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET - Tom.Jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: gnu (John Gilmore) Date: Fri, 27 Nov 92 20:15:40 PST To: cypherpunks@toad.com Subject: Keys & Signatures Message-ID: <9211280415.AA12997@toad.com> MIME-Version: 1.0 Content-Type: text/plain Here is the collection of keys and signatures from the last meeting. Feed this file into pgp to add them to your key ring. Please remember that posting "your" public key is not sufficient when you want people to believe that the key corresponds to a physical person (you). It's fine for communicating with people who you have't met or don't care to meet. But the way we can tell that the key matches the physical person who we met, is to have it signed by someone we trust. The signature indicates that "I certify that this key really does belong to the physical person identified in the name field". Don't sign someone's key unless you are sure you can make that statement (like, they're standing in the same room with you and they verify that they key ID matches their real key). Don't sign a key that you received by email or over a modem; it might be from someone impersonating your friend (when they left their keyboard unattended for a few minutes). PGP works on the model that you specify, for each person on your key ring, how much you trust them to introduce you to other people. For example, I trust Tom Jennings "most of the time", and I got Tom's key from him personally. So I know that if Tom's signature appears on someone's key, it probably really is that person. I've instructed PGP to know this, too. I also trust Phil Karn as an introducer, and got his key from him personally. PGP knows that if both Phil and Tom have signed someone's key, that I can believe it *really* is that person. The people you trust will be the people *you* trust; don't rely on trusting someone else's friends. We are trying to set up an interlocking web of trusted friends so that even if you don't know me, you will know and trust two other people who know me, and can thereby know my key is good. Making a key distribution system that works on a web of trust is research. It's never been done before. We'd like to give it a good try, among highly motivated people, to understand how it works and how to improve it. The alternative we're faced with (e.g. in PEM) is hierarchical systems in which some authority figure signs your key -- with all the attendant possibilities for misuse of power. Let's see if a looser, more flexible system can work as well or better. John Gilmore -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQBNAisOwBkAAAECAMw+W4OgXIO8E42bAT+fbwoo20aP5WBiBoLeiED3kBOSYa8F eLRU947sfn2VobobfSkg14TmPkMfDfdWhd2+DdUABRG0IkpvaG4gVC4gRHJhcGVy IDxjcnVuY2hAbmV0Y29tLmNvbT6JAFUCBRArDvZGVANHFAAi5S0BAWVRAgCidKO5 wvC9lQbMYfUZC9zOoqYbnRZF8JGDIRdHeELef78VpXydTLG09OHC0GA4zqfFrtCp kvCXKIEKsvDp5YmciQCVAgUQKw7yAa1SSlGFGX+1AQHObQP/dqMl0C4z0YxYjrAI ChV84C0pvaLVAShooyRI7c+rZO8RsmOIh44Stex+6vQcw2w2Ceh+NN7g7qGclCNf m8eHz3FKSZBUV1BFcMBKpb3+/1d/iZueaf5eqA22l5BBumy7KLJpATrM+vegMVFA MSdngyy6MMW9OhAZmN76OKuOJR+JAFUCBRArDtzezT/tLvUlcRcBAZonAfwI85gt tgoBtqZRUgVMJcXKZcERprMv8Isqcnw0oRhd/fbQBYBMJYK1cRCdfqGw+8jr4xTl dJoHm7WjvQkLzY8smQBNAisO4xwAAAECAKkyDQst9WhzHdko62Kd78+Ga8B3tLa3 Qr6zOXskoVaSYo9tLG2qo7bKs3W6SL7LgLRGaXqSC4Wyr7SLG737Hy0ABRG0IUdl b3JnZSBHbGVhc29uIDxnZ0B3ZWxsLnNmLmNhLnVzPokAVQIFECsO5fTNP+0u9SVx FwEBoOoB/17ngP0LwTFVGdxjbfB7BPz9kfYet/o2qkTfehc8WRvh/Xgx13ErY5kJ FBs8Qew75HCqBzDsGxiG8g44iHOxpDeJAJUCBRArDuPErVJKUYUZf7UBAfDmA/40 zI0SEtkE87LJJk4/d3Y2lLhBAv2YWXLckS/V/6G9n/MRILJR3s3x1staVEio3rHO bu+piG0uJm8kj2ShW1KFZrLAx5902BUM6ic+ZXDKjJ/SgCkVPr+RPc11HpqfWjpQ GiBSTmzRGjVfzDhcmbGneNq6O2oLJRlBqdaacK8DepkATQIrDsOwAAABAgDqJjAj dvu+tnRbDqmT02kwH9It43bqMd317SIGSnFQiU85b1RbfFYmA3fEOiA434Z/dASU AfFSUk4YBjePiYYxAAURtDBTY290dCBDb2xsaW5zICg1MTIpIDxTY290dF9Db2xs aW5zQGdlbm1hZ2ljLmNvbT6JAFUCBRArDvYKVANHFAAi5S0BAenEAf49x8d+g4dm 7qK3cLIPfjNngmPZqEXcQ8dD/gtPAYADx4VkuXAqhmFvg6sdfJCk9j9vUrg+ReVN LFJN2rm/hAQEiQBVAgUQKw7fJw33VoXdvg3VAQEttAH/UnzcdPIK6SopvlPVp6gS +pMGt8xkd4U7dI5XCtKNdlbczBKjSeHw/+OBBjZLoFqMrWUtyimwUCe3auLxRzup GokAVQIFECsO2arNP+0u9SVxFwEBhbEB/0QkJoNqPA8CRPnkp9yYdIcB8EiTD3qY JYKvP0fuf5gOWAyurEa6wCCxgZwFuBWA7s+lTHDJH0EkUWr/whNdZLmJAJUCBRAr DtZIrVJKUYUZf7UBAQ3CBACPs+6OSUG2GPudoyEz2ZgCU06WhitFADFTyLL2ADyw cznnt+u6/HBKTFjofC2CxFMoU1flYa927c8iRDEH5kwhbari3m68lWm82WQ41N7l nYuSV2L10elmtbpdVwtBYz/qlB+ONJma0ryahoVdRyCDXsDYnk1ch7sZd3hhvKH0 7pkATQIq1hAPAAABAf4nzLRuYjfdZYmgNbDw91ZfnS6numEF9zKHQhSPMdSgyEoV 2h/I/KAyonOvPgGrpbvySXRwfvHy2ZSNMq4JDJ1TAAURtCVFcmljIEhvbGxhbmRl ciA8aGhAc29kYS5iZXJrZWxleS5lZHU+iQBVAgUQKw72J1QDRxQAIuUtAQExNgIA pNqq5+d9cxdYphGVuZMGcHoNrxqvkMmzhgjKvFbC956m19lSF918/F+CisTNr6L/ sJkmyARrqZPivGPhYvgipYkAVQIFECsO31YN91aF3b4N1QEBtDoCAJvDbP1+ZbG/ RDXQexxvollsOBfkp5hrfY+KQ/2U4V7i8Kef3Vy5j+RzXcY7fRLjuWQLi+yykBLh mVkArKv5xvKJAFUCBRArDtn5zT/tLvUlcRcBASdWAgDaGqLltSctfJBz/cwgbAFe 7zEtZTfghFA3q8vEHsdHhFP5Vx0jHhwZozFEiLJHuoz9OKyuvxRKrKgnqlFVhSO5 iQCVAgUQKw6qUCmBKTQiZpaHAQH2pwQAsg59Mw1e9JxCD8VLOxLvtMuk4XJlHRNQ U3FW11z0zrlShLwFSqOt3h3ag/A3EFZLB1j213JbIUlUuYzJO1yC1sjV7Xryd6D7 HG2R7GbL8WOLTuoBO4XQTtKu0PulJgbiVc+4CHV2S1QSUaEeWbPRqciSAwfFSGb3 1Jqu1Xu1mV6ZAI0CKw6peAAAAQQAxAKQzN+3TQJtcn0KEKd3H2UP4mNLSvEekmNX kGxVmvEGW1yNp14cQiP+DHe7W0/ZL4mMs5+BsGmlatzIZm0lkZPPFP+mdxgmmH8y A6Qw0VttCYEAjoSEr6UZ4sPVoPktsitLUjrQMk5tWfx8JMxKV9XK8WASwVjkKYEp NCJmlocABRG0KlNjb3R0IENvbGxpbnMgPFNjb3R0X0NvbGxpbnNAZ2VubWFnaWMu Y29tPokAlQIFECsO7UatUkpRhRl/tQEBgswEAIN3cA/Wobk6EkktBBSr3ZybB8zv mA8Nze7jXLm6fgiMRGAhSB/79Q5tshc3pE7UtOzpHmTiZ/ppz2nRjkyr8CzIsEzs LVDM7ctOT7JN7MxEBUZ3D03Zs1AIA6nzn1MfKbFTol2jXm0LXXafMixdpcvfV3v1 hGagMTMtMjjumiytmQCNAirPdYEAAAEEAMoyYy8lL84DlFK4IRmYBwfSFY8IwWia 0J3cKPHKyQVligPKgUnfh+Ky6wN6eXAeZsbEjM6VMXY21mMaRec3IbzXok2UKQHy FNUnL74J4iH1+hGw0hO89bcDwFeFXvaFqcNTQRF0GJOSSIEiz970fqUOo+esZzKe azP+2tnMgvmhAAURtCFEclphcGhvZCA8ZHJ6YXBob2RAbmNzZWx4c2kudXVjcD6J AFUCBRAqz+Q0VANHFAAi5S0BAe2PAf9bKSOk76/vSFirkK/47CACCfDbkj1bvBVz fzPv8+sY6pwi7xjEneropY0i6enwBWOWSP7r9VoqF90Ib+vjEFbxmQCNAisOzWIA AAEEALLmQZNts5rAUk5NoTJcbpsNpCazDysVO89QP70nxTniGaPGx7ywfbJN3dWz CjQbpC8ZwALcI9hexxlxz0lUvnrPy1OT5+lNIU68uvDYWU7s+ZrnGLCA7vGgH3sS PQbmaOu7QUu9o/ynJc29NABMrNhAYdbZvY7HxOsAk+sCRcQ1AAURtCJEYXZlIEty aWVnZXIgPGRrcmllZ2VyQG5ldGNvbS5jb20+iQBVAgUQKw7141QDRxQAIuUtAQE/ SgH/epfSUEmghODhSeVUqdJVkpYpjZu7c5j+2LGG5CWU1jjavK7t8HpY5kcyDsUA BF56S5kQ3fiyNiWxTpKtoSjgiIkAVQIFECsO3vUN91aF3b4N1QEBn1UB/2DJjDCi jIwyjNODzLr1pjmb5UAaWFwzTyg0F+G7iQ7GgjfcuaEjd8NSaQloIaqawdRa482M LqKeFMeeSPcxrheJAJUCBRArDtegrVJKUYUZf7UBAX5sA/0ebDd2cPr3EN/RWC5/ 4Nie4275BmEo/07Ita2XytResauQLP9JcNuSxLLlNRylvzXVS0EiQL4heek140ug TSNZSp7eSvjdxWUKhNLN4/5OqIm9IkVK3usbIaC0HVSwwF9xx4BOnzwuOlbFLxT+ qKA3C72ZvqEvkEnR72svlsX5RokAVQIFECsO0ejNP+0u9SVxFwEBvGMB/jk538BE 2nV/QwBjEOXDJICNwbaZj0aLbT/kMdnW6ktGEdHUTmMHd8tyTGL4D3sauHWchUYH cGkoJXBd8ZtdyXmJAJUCBRArDs7sofVDpely8BEBAWVnBADckZz3+yOADrLxdYbE kWdl3aoc88717F7mpzi2BRCKUQPVMic6yANCvEbttb9jJ7hrLjf/J4Lhq/egY7n7 aVfYVJsgxVahtyrfXPTdVKbicrbRqctozpYoHXLEPGzl9m0YaV38EPONxLGTlgUS VFXR/SuxHe11fMxqnNx263Ydv5kAjQIrDsT9AAABBADdzlqPkaE5J9VSntGSJwPb 9XUmCUaSMOwvaxGCUdTiJjlOUVKfIoUoGgWvo2pS9II31HP3+YWBDyhYj4Cu1odb f9IrlLv6u5G5BOuYSewthAMp85n1VZLjWERKAr0883dgBJ0FE2QYWxppSSZrmtbW rSYCSXOcQX+h9UOl6XLwEQAFEbQkRS4gRGVhbiBUcmliYmxlIDx0cmliYmxlQHhh bmFkdS5jb20+iQBVAgUQKw71jlQDRxQAIuUtAQF3KwIAmVxMJUn023kdxA003HRC twXqZTY53zJbR/LdXVjgIgDDd2FUzf9vyvU7TQWKE5qJZoB4H/xbMIYozuAUuRDg m4kAVQIFECsO3n4N91aF3b4N1QEBHvQB/iGuaRAqESEPvygmwGP/a+L6MANN38nQ vZkqbbil6mKrTweplVlkWkEyC3xxj6mXQGrmuxo6dZD5mz1yMRGu9tSJAFUCBRAr DtWfThgGN4+JhjEBAc+mAgDg6eWttKQVvu7yvwdCHryImG8P4g468iCdPSIux24a PWsdtkH3v84FW6ZhDOaHe8skliFtn279HnXnR06DxtTUiQCVAgUQKw7FiK1SSlGF GX+1AQE36AP+MunJg8k3m7lwAWAiaCPQAJ7m970en78QuZq28wdubULfLkrNKE0f pXcW4RCLEP9HPgsxGHEwdUQ0uNHzQx++rdDkDUyX9n3gp8bNPI+qkFItXfwXgl/d 2y0lN9VaVAQ9F4yfn4AsMHX68qz/jfRtDEEemHXlE8JzyTapLpnsayuZAI0CKww6 ggAAAQQA1/vI2320Fw0uDvKpV6CtFAnx11BNwddQVdK4sKgA53dxAyFjZ08m7MsO 1nO0r7LyJHOB+uTMli1lOp9BDhBECoG5aSgKDsM5fxtawEv3Fi1/yv/Sfxda4uRR z8Jmelabg19dquTr8uVtfx9iyEKv1ANp24wfn1L5VmLN1FTnSD8ABRG0KlRpbW90 aHkgQy4gTWF5IDx0Y21heUBuZXRjb20uY29tPiAxMS0yMC05MokAVQIFECsO9bRU A0cUACLlLQEBbVECAI/wy6VsiYLrJTu7CYP7b7d0VGx/6tNlV428R8+4t6/TTLGl gaj4vwkqxxJvvfB/iC0mUz8R0cc8symHqyCFYCCJAFUCBRArDt6sDfdWhd2+DdUB ARdRAgDA2NCvsdWQ8un9vDO8RyUux/cRQRt8s3jbURoDfMQaxeRySiOZAfcikHlk jYv7xs/30exUdxhEM1ge/J6xkS09iQBVAgUQKw7VXk4YBjePiYYxAQEK5QIAjJ1v 7ZFDLjRHBnD5BbVmsEI771CjsvHOg7nLjpi5daB0S7mq2dIbxQP9N4N1Pktlyx4c QF5R6SjS3y9uyhNnCIkAlQIFECsOz4+h9UOl6XLwEQEBdG8D+wRPT3GD/RqlIZ4u TnbZADXZqvbv4N77YEh3h7SV8hj36E/BMY2ATNeSSlQszeMvw+Wf7qP4K8TmBNqR CynBlfGIAut2Mq2EGFXnnczpTznKO5AnuueA5B1V2LhzUnFYPQ1RYKQwI79CXE8A MHNuzj2XyhrZM7eSfSy02C7U8RkWiQBVAgUQKw7JjIxutC9MEx9XAQFbfAIArqvT ilFa/ivgvjX9yQLiMqsEYGd8JZlkQMxeDgPzEHifi7UGG6Eqqaf6jHK5uWlBX4ae OT22GOp0l+2IgI2ynIkAVQIFECsOwZTNP+0u9SVxFwEB1T8CAJH+YlhjFoSmUAmP 8QUXojTzrNJToYNpHgIhuYQ06ScrJXD9wokCNZKvD+xBGsruSZMNlOmfWdDDgoW7 gLGVuP6JAJUCBRArDsB6rVJKUYUZf7UBAUtcA/9deJQC4FhMrz/Y59gTXDRmFWwF ESxyMln2tbRnC0oJRle0cMgFDdC/CioiIpsBO1PVzJrIeH1sTCXU/DaQuf9b2X7s 3I7tQYw9/ZjR2OPkyYpv3rQn2Fp7POyhPy1Nv36yR4idrA/NUC7Ctt/+4jG68528 ksEvw9pbuVhNBcfn5JkATQIrCB+kAAABAgDEh5wtpV7xm0Owqgr8XYiLC+7JMot1 EaZO3nfjB/k+ckrtoZa/KHLuU7wKY69vt8RJ4exsuD0uU4xutC9MEx9XAAURtBlU aW0gT3JlbiA8b3JlbkBhcHBsZS5jb20+iQBVAgUQKw71XFQDRxQAIuUtAQGCLQH+ JVGk8iVvPLayNZWg6bSvRH3h4y3GLPFzVvA89ZMHb1xgiW29LyiscutGD8qWPpsb WzyZsqeDQ2hFJxqk3k5xm4kAVQIFECsO3kcN91aF3b4N1QEBjmkB/AvUlntcDgBp MjTm41ABJT9wVIs01v2jzDNIykcHiUURKEkYJgDyd+a+bdA4GawdaCnqechXNoLA KDplzZ/eL1SJAJUCBRArDs/9ofVDpely8BEBAas4A/9NRUFfg04khWbB7yR2HXlk W6hrPNE9ci7iVKumjV6KJ2FyyC7IwOyXbV7AUOPyo6LB1mChUY9jXjB5BpNIIR39 R5I4BhDMEPBOBwO/nNapGDiG2RYEGwOFBa40IL5KhuQR+v+5Otc0hnLaH1tS0vrA JHKM/s3n0kkMDQN8Qr0agIkAVQIFECsOwkbNP+0u9SVxFwEBK28CAJhatLqceA13 D6svwHB2XonVwzmkPt9L4zx6eIj4eAmpDqAf61KxAG9okz3BLwQa+vDZBztf6oNl pw5suRf4BPGJAJUCBRArDr/RrVJKUYUZf7UBARiRBACnY6NN4LGspnygnKd/cLjO Pu3cDxlaZRtLxoSrCduP7ANciUgYuobyInCP5qS94tBrK876mwR2KTohXxt6D1Tz qsoeyu72Yv6K2OUwF49kbcZZHj5ab4Wkd/eGEu5oYIHMAzpa7Nlu14BDE+AXKaIf dzT8qB2jEE5O10bD/8LA+pkAjQIq87YaAAABBADS19YljSbdxVnfyXLFxYTuMo+u QuDxyWux/8fq9PcKXOTdsI2d4slSQHqLauxCbZywji1Qv0f2HVvBGxbUcYfMD3DX edcRYL2LqtSOPIbvX5N2TScNkfaHnC4gYtVKCdiZfIldEY7VivXQCFAGjmpnOh7B FeQ/E6+aZmGKlWth/wAFEbQuVGltb3RoeSBKLiBXYWxscyA8dHdhbGxzQG5jYzE3 MDFkLmRlbW9uLmNvLnVrPokAlQIFECr5wtj/yyWVmRmdZwEBhSQEAIAuvgbU2XaU JTwWPCE/kMwgvL8O2PwzGMVpBT6b0pPfH9HmJizoAQgfpS2IzvT0JvMSVdd/AWis x29JKmPZwycsuL9YhC/wiS2M4kx2sTWB2qxr3qxc+nMQ6MpIgQSzxfTgfNjRFlRJ 1HKHLz61auLuaoFpSkXN/cR1dLajeWQBiQCVAgUQKvSxsG1tOFJzS5pZAQHoAwP+ L7jbSlXX9gXnC4U4nVZRWDO4uvydEWTcKNY8/IxnejhZ5FJWg2pEjzKbAyw7Ilnk 3SvdRBe322yRbstdunwoMH7pVllwoul9ubACq4j1jgCfC5GkJ3Zu3bg8fjsb6UrZ FUtpbaaCfp54I1qmsxhcPI3cppZxTENNw0hVXe36X5q0IVRpbSBXYWxscyA8Mjoy NTMvNTEzQGZpZG9uZXQub3JnPokAlQIFECr5z/T/yyWVmRmdZwEBNY8D/R0c6RN2 lX4iXO93r3h+XEnFfPHJATKlzgwY6thmAyyFoUZx/zpeg9tAcawv38KY7M8cI+MB DlmKg0wjs6vlbSGug+FlNtCyA58FgnerA4lCyKBa9vvQj1eJvXl97N/BKRrWnH0p 4+xPpITuyRszwBWjfspU+bFyluG4W46zAgAPmQCNAir42jMAAAEEAL8O8OQ1eDBh W4eiV1iF+TapS3dz3kIQE9jTArEPg+lhNRa98mm6O9ihGvue6tMmgxPxOczMllOh KlBOntvP3YdfeASz+z99kzk3wCo5o3eepUKxb7RPRtdq8AZKMHuDUhDOWeJbW6Nh itUzS80AdJdJXlkj2Sw6DTBkQouPDkHHAAURtCNKb2huIFlvdXJpbCA8MToyMDMv NDQ0QGZpZG9uZXQub3JnPpkAjQIq0o5XAAABA/4o1Wk45VOtpkHV8MY/mxDt8KnT CpGZUTbda0ovFTkpHkNBu+ymwXiDaFQkyItdmse+KuwDYSgoGvmZAcQFU530gUGV 3xYf+VzMc86pOzU9nyipWfx63+HA3fFWIEpelj4clTvhKb8mZ+R3sxiwW68hqQnJ aEpowXMHdoNaWFSIYwAFEbQsUy5FLiBCcm93biA8c2hhd25iQGNzY2locC5lY3N0 LmNzdWNoaWNvLmVkdT6ZAE0CKvQ7SAAAAQIAtwhdLpYOMc9jYuiP/HKciGbd5xf/ Ko6uE60qJpgkFrpor22K4MkaDGxnCPMNvWFRWyzlFMBLzZ+Zh6dZnnUf1QAFEbQn QXJ0aHVyIEEuIFdhcmQgPDE6MTA2Lzg4LjFARmlkb25ldC5Pcmc+iQCVAgUQKvRH b90U2ry4hanxAQH9UgP/a92Or1E/wmwL8IQ/KjaXOBK/ZZfCF+KZb8o1TAE/85am tZCI0djGdgmT/GWogiQcC+OV5kbvyJZystc7F5vck8AnVzjurVKydAlxjXTNG13g JLG7fIR4EEPu+Au+v3kOvZNXVL+RVPcGqppLb7acyJxxch60cK3Y+klSApZ17tiZ AE0CKv/a+AAAAQIAvvIzkJW7QJxSrajJ2/nbzs0cUzuRu6zlUgV1RlWbw2n3tVtq Z82m1uW3Y4xuJkAo94yGPt6ZaztFsaCuUW4XrQAFEbQ0SnVzdGluIFZhbGNvdXJ0 IDwxOjE2Ny8yMDh1c2VyQGZpZG9uZXQub3JnPiAoY2FzdWFsKZkATQIrArVNAAAB Af4zTmMzdQdmMzsZSv2W+msaDmhpT6uSOw1fRh94XBkTeTehYk+LES4Yud0nOa1H WA2vJhUHeLarxRuqx3E/C7Q3AAURtCpSZW1haWxpbmcgU2VydmljZSA8aGFsQGFs dW1uaS5jYWx0ZWNoLmVkdT6ZAI0CKukFCAAAAQQAyYMMahMpKeY7L7QkFL4t/YnM 6UgzXJR9D0CltEaVxwCaGzY5Vs8phOAZjl2b14AyQCUPj0xVlkZZG8brnUZs369f xtBpjfBTlp1b7MbWnZ+kgaDPvHot0muyZSQWGyRbTjTB4l9D+HBguAdms2aldP7E DEawR+xCZkJHNGc7GNEABRG0IURhdmUgTXVuaG9sbG9uIDwxOjEyOC84NkBmaWRv bmV0PokAlQIFECsBFxGbmjfV9XLGpwEBCTUD/0b+KIH7mflLLECq7rgGhJ9k9KYN iKhy0gN2p6QOJB4LzY4vu1Wantw5pu/VJdkCvSiWCEom0IFi0gIYWqR5aBk5LC3D eQVqEo6drJXIiY9C51rRj2P7jGh1QPjd3bK045UrOwWnFQ0ypIWLYQZkMDvXZKfJ 5XtblJ+xY7XlnidFmQCNAir6ffMAAAEEANIvssTzJGOUrwqqCwRn5RRRjMbAFovE I8wuwzHOKxqZKVWEOyshaVsDDO6dwAgtq7BOixvAKMhiGYjT1EjABdkveQmJ51pn nNkVADTW/LJg/xDG+dEbXdpoAPIsDmD52Qa4hQT73g+E3K+BxMWHSuROX0tUDugH HYrYMBOwiJinAAURtC1NaWNoZWxhbmdlbG8gSm9uZXMgPG1pa2VAcm9jaGd0ZS5m aWRvbmV0Lm9yZz6ZAE0CKv30TgAAAQIAsKjX0o394ucwqJwof00r25jeClo0Bne8 w+mIgA4fmxY5/Eq3Ru/9PQ2dQLSQav6QmxgDHt1MZzgL9HHetm47/wAFEbQmQnJh ZCBIdW50dGluZyA8aHVudHRpbmcuNTEyQGdsYXJwLmNvbT6JAEUCBRAq/fY+M2gm O1A7uw0BAdA8AX9MrWY70GmbQkK3Gpi8KKW8wRiiGUOYLqlOXpc/FWKKXxZc6zTi eSr6/Lbr5AKuB3iZAI0CKvxezQAAAQQAuyduclSPeeuo313MBAD3RWFNwoT357ZH 5PdUlzSwX9SOeOaRojkjyMuELhkzB71r38UlhzYcpmQtBPQQh0kXtpDg2fWD4pdp QQAQlR3K4KCxok/vux4Fq1qMxDoONMW0mLv5uzm3DfWxZI2PZ98gbO8+Z/c6A+PV 6jr803GUa98ABRG0HVBoaWwgS2FybiA8a2FybkBxdWFsY29tbS5jb20+iQCVAgUQ KwApU/LwEg8VF94FAQGYnAP6A+7xlUecA9TMy2yY77zNzh+Yh2qmaAADP605FzMq WpmgZfR3pC9vj4dpetpiOXpiQhPtrgWdKp9VQ8BV3ZGqSWEZqMQDQbmVNqo0zjxa dm+WbCJs+MuCmWhqwebNYB47WdStIWww91yqHfg8znUIfADjPmDkljxaaxbrXcdy SWmJAJUCBRAq/sW4JmxTO+Hhs4cBATzpA/4lNoC9awZwjAw1+LZnl6O0RIub8ngS Wkh/FO34/GbFKPWjU/boiKktzFX2pjVjLCUHhYjuTyDf9I8FkbGKVByu2RZCIe1x azjHsX6Vf8uAAkXmsVq/YZxS9rRxCqLRhdh1UCRLYy5CRpc2RnoAPLo62Se5J9uL aIFQOss2RrNR1okAVQIFECr9KbnNP+0u9SVxFwEBWEECAIiUfg2md9cLBA+SpMIV en5byuLWR7CSx3HJhQwid0IP7EjtZgA+bnmHG4XZTsHLH1kquO4mwrw4CmSxkgM7 kDKJAJUCBRAq/YGlrVJKUYUZf7UBAf4zA/4/wwJgR47BEd1k9FsAZtIjfqnqBQes Z2GgpzrbEddx13iur/qwwME2qHRwG3bM6YAmReVKDx08nccxyJ0XtS8aWdJLgy0G 163oF4olFg6pjI+eCnGvv3aLSn7ImvNQ1VRXS4wAq7ZFK+FG8XmvcEIq14esCx8+ QohKA1CmE5syJZkAjQIqwLQ/AAABA/4rPr0YYY2zZVg11tuwTcnv8Br7O0ybaaQL vFkyLR/sAHtO1bpnVK9Lrpa4ajWXrGgws3VjCKeiCEZTp+42AubMkv0mDf7aCWR/ f0doZfrRlAMWE6Y/Nrk86+57ZRETtIAu53rp6L+umiiCND/yUVjyZ34iqUwc/lmf ARRCVtnsiwAFEbQbRWQgRGVIYXJ0IDxkZWhhcnRAY2VydC5vcmc+mQBNAiquwMAA AAECALC76HwzAONUnaxlyj1TWJphHqDvZ5RB+EmFDJ7WSyEuj8tq0P8iZcRV5Ut1 W9tQO7I07DtJJq/BVQVm+k0MTuEABRG0IUplZmZyZXkgSS4gU2NoaWxsZXIgPGpp c0BtaXQuZWR1PokAVQIFECrPoHpVBWb6TQxO4QEBnZAB+wT9j331mWhg+NuLcMes EG9U1X1QZG0OTOr8tItwrA5CflpbQEIULavga6j5VJJuileTobU9Pof/LX6jpwh/ BgOJAG4CBRAqwm+lOHQrXMGwavEBAd54AsQJGC5ulF+heo2oqNCI0pF9AC9LGZCD n7EtEqzzq/6vNQndOin1yYlUJ5Bbv8rDwQ5ZtX+GrgBVgvm57eDwLtDVK7UGjS6M xAmOPOqxqb/vik85CvqjOv739pkAjQIrACgiAAABBAC/bz3yCNkLGb2BGkkuX3/j sOIrDZhkQru04o+9fnvlgsE1rpsl39d8FaM3slpzoWumLvXDEpnrtYyMQwdsei9O OybBk6F79HQ3qvFXo7GZSfLI9UArPhbxHgF4ASlOUj7wghaOYAqI16USrvGq/XbO fE8kczRRhxny8BIPFRfeBQAFEbQjSmVmZiBCZWNrbGV5IDxiZWNrbGV5QHF1YWxj b21tLmNvbT6JAJUCBRArACkN6jr803GUa98BAX79BACOgUTzwvG1eGQATSsKO7ob 8zOM5lzcQ6wFxe4RckXbySwvzwWYxuRsSpOvH6ZLf9YPDi2c3vGDSk9OYz7CPyU2 djVIMXJxy5ITuzu/Uu/wENEM9m7Zqkps0bltLpXIIch01NznTpy+YSM0aJy+i44L 5qAsuJ/vgKtsnZ8saMM1wpkATQIqu5q+AAABAgDPUfDi/la+bkvObQgiOnGjRJQX X6G1/f9AConX6f/g+zEc/OiLMn35mglqfxfMorUdRWM23u5A8R9bGnaOb/KNAAUR tC5QYXQgRmFycmVsbCAoUGF0cmljayBELikgPHBmYXJyZWxsQGNzLmdtdS5lZHU+ iQBVAgUQKuVXcxmDgsNS79YXAQEeDAH9HI0sBvKUHNcE2hyYmFFNmj/vkDHxh70Q PNNGeH9RrOXuzlsULrfB+1+XGTuWCt95CD5r2pNrjqD5OAz7sMMamokAVQIFECrd miSkkSFWWSDVNQEBH5MB/R74VxW6HxvNcR90m6n1BPW4PVRlF/XPMb+WkmMbxcC/ cy8AL//426liFpbGD0Qn5PE2UtLzsg5whuH2j9+gG5iZAI0CKrQ85QAAAQQAnyF7 QB+bkTWJ+PBTVNpa6QIP8Em1HW24UtyyHnc8cCRHV8IXab3OcPbTQzv/WcZDYogN AkzxrBwE0v81si0Ld2YikSuNCK7+K9GTWeP1k3xttQSpxSyDmK6gqM5LgpZfT8xQ LBJdt9yGCstanqWGoZYMI6VcDOOl2Mc2ZhtozJEABRG0J0pvaG4gQS4gTGltcGVy dCA8am9obmxAbjNkbWMuc3ZyLm1kLnVzPpkAjQIq85+JAAABA/42Cc61+viyUFYp 0TJfrTh7hZL9pFavKvlkQGeGML0P7QFfx9bn9mTkT0c6HuPeAOAlerjU/DIeixmt aSQkrXyduI01jCwcMXsRu2huAFZY1cbZRfgZGkV+72q3+EJYdo5H7RvDcMsobfJx r6j/i7bRrEDuF3OkDbcud4z0nEkG9wAFEbQmUGV0ZXIgSy4gQm91Y2hlciA8Ym91 Y2hlckBjc2wuc3JpLmNvbT6JAJUCBRAq+BwzXE2hr7Q1SWMBAbCgA/0bOeyDLHgD PCnPCSsPvwlLSybrlZHt9FYFxDzEK+fyyRDTn4LA3CNn0eNn6aLxqm9KwkeHcq8w JDPt65OS8yVmNQpHu/61PKbuSvuaE9UULNdiZOmSPzY0xvjaCqwVj83Yeg52Go+b xArNzisygYG6/hAoSnI1QjuswvJIKP/BU5kAjQIqwgaUAAABBAC/QxRn5G9merg0 FiL/PitJxqJoMKJDrlIzpZtKz9eKmOflIsn5N3zxBIzGgKcGDQgUCG0JEe5YppT9 PjwkMGxf6mxbrfNyQNA/eN9e2a3kdurijhg+8NfSrafZT1Zix9QIgEFaM8q5Yyy2 oYz1ShC5orOtiKsZaSKIhXGWu7M+ZQAFEbQmRGF2aWQgU3Rlcm5saWdodCA8c3Ry bmxnaHRAbmV0Y29tLmNvbT6ZAI0CKq+n3QAAAQQA7RUWyuadmGYAsM5kQbq8+VPA HmOozmzA6SEOokg4c63I26DZl8KmxBRhytUIqMazjNqK8SiJDGL7nfybA2Ev0ddA r4jcdHbERLOkkSguK/raQwhzBVsTD1AC7FjtnTUoeL5s1iFhC/MFzNpW208l05O8 2ltQLNYh4pcQz3lYg1sABRG0KFRlZCBXcmlnaHQgPHdyaWdodEBsaW1zMDEubGVy Yy5uYXNhLmdvdj6ZAE0CKrFhOQAAAQIAt94dinTILzSzVJwW8lKmPl5IIA76GKG2 d4Wuuf6+4RxJq+EABTCkhQbJXY3yf6UVM+ectzjYyz5zw8lQ9gpUjwAFEbQjTWFy YyBUaGliYXVsdCA8bWFyY0B0YW5kYS5pc2lzLm9yZz6ZAI0CKnXWfwAAAQP+NKBR j6NV8GA/na8KBlDFOSM/vbczlzPSj+0zmfk33b/Gz7fW4baamIAe0P84Xz6XqEOl WXjQQN2iueXmIp/9fR/xfJxe5LBelhRPazyNrVMD5/Hb1e93Bf8X3p0ZtkpfZnJt Mu+sSkkJzEAjYdudiNPmD8eNm7pSJmxTO+Hhs4cABRG0KFBlcnJ5IEUuIE1ldHpn ZXIgPHBtZXR6Z2VyQHNoZWFyc29uLmNvbT6JAJUCBRAq/rsN6jr803GUa98BAXPQ A/992sANN84YkupfvlynGI2R2NvVvb6tQAne0lg8CQjf6rdjTWvHE4hDJZW0mqoz G2CGmi1meXRXwqNMUaNYBQfxoAnFbaboPj0N6qdNgzhQRgppa72c73Ayj7uOOxWn wsDCsHxBgF55/E8Xo5F3m3U5r46pxsQSNn5Sos9lUPtfV4kAlQIFECp17mLidd4O /2f3CwEB85UD/0VJnzQ4JC+Kvn72XCxTVODFA4PjdnVRZQEtOR8qMKd7oixVjQQ3 DFpOYEi0ASx+Zpgf1Pja3URdtBXHpYBVxG6KlriJxFkfIUrZ4wSUoHA3cah9fm50 AT85KKRz3fwnkE4z9+nDpDW0lhfvDG+vg/KmvZJPyRSiwmM8RZQ1/Hb6iQCVAgUQ Kq5vTneU/RvzKz+ZAQGyDQP8DQo3C0Lo62K1YdMjgT1WK58qsfQS/jZnGEHyDjSY PYzb6UQ2JyWmbPsfx365Z5UrMByO0rrOiTtuHtL/4GuA2xCGRLHy7Ci4JRzTKIOi LFW19KSlo0gK3EZp0Y+I3RMK0Ne9nvkcRD3S4C6vGb3XUzANlZei8msyJjPBd44g WbyZAI0CKv2QnAAAAQQAu9hHRyLEDQrqpXhkP/uKLGRH7g/Bk0bSuxNPdTYN4c2P p+xUEYkvQ3JPX3Uhwh/QXlVFwarLPL87CfpbZcSAwWoR3x2z2yy5BXAzzS5iK5+S efBN+qd1FzEVPSwpJtlQODuSBwadH2dpQeH+HjjiHTej4ZMy/X6bhr7UV33/hTMA BRG0JXBldGVyIGhvbmV5bWFuIDxob25leUBjaXRpLnVtaWNoLmVkdT6JAJUCBRAq /ZHM6jr803GUa98BAdg/A/9a7IZVESRRqyZVNhTRQkWNiZStDWxFgH3wCzlyCHzt +H4uYFNzDMGmwCYRJ9HtOobicbPv8ZV150TkuUzmaHkAyGbnyTl4mNL05W5aVVYv FrKCaCjAHQ4+cYNfxr6PSPH83oUsb2l8cFRLov0v08tUHNGiEinzL1blfUQCb0C+ fJkAjQIq/SX4AAABBADD37Ztb6L9d7+rrxl4g60R3ggHwJT1gUK80FlEJz0AG5ac jZae6QqRrOpx83rlCIBwYabbzy3YKKo5DwENvrlPVvYhQUMoQW9xbJ+k+LXVKGWe /mp+eqt89YrKtXe8S/rvEEhljJQHl3icT7MTr4mgnSfgNOEHDEzC+a6J/vTBcQAF EbQoRnV0dXJlTmVyZCBTdGV2ZSBXaXRoYW0gPGZuZXJkQHNtZHMuY29tPokAVQIF ECr9J9HNP+0u9SVxFwEB++AB/1pymCaHy6JkUX0i4mzw0lTqDImc2L5TX6Inu77z QMHiF1u1Xx/2G4RaTbceMvozcsBKQY8KOM7ArLwODnsoEqmZAE0CKsyOTgAAAQIA q+wDIbTKjxexmByf5bjYOirUWO734ArD/8QW78yCXhgsuwE99xTL6y0nEGnJPynK zXj8SOsrhh5UA0cUACLlLQAFEbQmRXJpYyBIdWdoZXMgPGh1Z2hlc0Bzb2RhLmJl cmtlbGV5LmVkdT6JAJUCBRArDtcMrVJKUYUZf7UBAYIbA/9q13zMS22XrfMEpCpe Rv+c1ViCDcvSp+znkaKWSYY2LglUBpUvc8SlyGoeMwFtitkdoIG0RvYjL6+M7gba T+d6HkBqO4f7QOpH29ZLqnbdQi0aKIk+IrIkOEb16nsqy2ojbL86y/t4RdbVfnQf b8sFI4ormEuxUGr54wmP8eLQxokAVQIFECsO1QtOGAY3j4mGMQEBtuMB/27/Gkgl 54VwZnh6EPSoCUtDdlMFr0E1+CyaaVysmUiZtPgWyKlkdVF62L/1NlLQWNwdudWA 9pyGlN/PtPMG62iJAJUCBRArDs+5ofVDpely8BEBATCBA/4gn6k/zL1i/oeMExVu Ric4S6qRxCbVGqNEiuravaFRMtIST80yCXZmfStvXmbtOx4fMKSZyFP8bz+MImNx qN9KoJ9qa/BXNUCBcmoDpiwrTXGTIpG41Hp4oUt1PRbKgxfYO95amJZWqOK543wl sG6c8ECQ16r8k7LjFyiK7TLaNokAVQIFECsOzqWMbrQvTBMfVwEBMzMCAIfQHd9B QECckjVbLuqCjEQ4qMkTswvGxx3+r8HwPg7nXazNXouU0MuOyFMzVMxYq1HpEimK t7Yw1NxUfr3EV1mJAFUCBRAq/QWhzT/tLvUlcRcBAS+bAfoCJ09VmN3kQKTl0FiD gicnL4AdapE9Ae0PhzRicwrpsDgwRZpMWWJ3I8x45aAEIx4WbrE++635ZbsKNv09 /h/nmQBNAiq/U1cAAAECAMyx0/jdGADqY0GVjnTJU0/xVP39MH6H5PHcD7/xbmtb huvNOm+yejcX26z82kEHm5os+APY+2Reb7yMu4/P46cABRG0GEFydGh1ciBBYnJh aGFtIDxhMkB3ZWxsPokAVQIFECr9BUrNP+0u9SVxFwEBKVUCALSFLYzsX+JmonNe y88OIcfHVz6ofpwILDHNbF7aHRbI8xSsYENF46Xl3i0gX/81Yryq4EnP+45hUh3c 8+enppGJAFUCBRAqzdeLVANHFAAi5S0BAR81AgCjo9ianON2xHMtqh0CNtRX8Jlp wJkeWzHTYnZV8G3INAdCj1dxs81HeN+JhRFp2toN8zIFB+Sj8olN0bvGtF2kmQBN Air9A6oAAAECAMguSk+WTd4dFM/x2ujb61dxXacQp96qO4bzv1HakFjdntjYOsgQ dI/Q8BEBmvDKooQutKfJVwcOtFa98HfmaOsABRG0JE1pY2hhZWwgQS4gUGVycnkg PG1wZXJyeUBuZXRjb20uY29tPokAVQIFECr9BHbNP+0u9SVxFwEBRTsCAMkpIc7d QvPhEOJvIiqAeaEsv8c5GzwnF0dXzUA6yX45jRa1dp9Apb5rURSPkgKKLhCezeE1 Q5TAGlo86afa0SuZAI0CKtptOgAAAQQAz+NON0lqxUin3pW5MDURzQcJ/jOX/EYg gxprQ3iexD7A9gAj877+rlYd4k/iGU2BO4A7g7si2xOlEtxCRRIPI3i5BB4TOv69 qRoGUqvo1OxnYKeYNHqgTj1QlhX5Kxm3Bo46biqsrtbsbxJn9wD45t3SP5Y5Gn7c eBk/WAnAmfcABRG0HERhdmlkIEdvb2Rlbm91Z2ggPHBhbGxpbyFkZz60GzxkYXZp ZC5nb29kZW5vdWdoQDE6MTI1LzI4PrQcPGRnJXBhbGxpby51dWNwQGNzLnNmc3Uu ZWR1PpkATQIqxL8cAAABAgDFJCx68eiR+OQTHeG8WQzUDtx6y5oWUr7Bycyx/fvd AU27l9yr6NKUiwoffJtgG7vy7aBw4ICTisURnnvuTwxHAAURtClFZGdhciBXLiBT d2FuayA8ZWRnYXJAc3BlY3RyeC5zYWlnb24uY29tPokAlQIFECrbtYfidd4O/2f3 CwEBYJwEAI0ZSppkrwzGVFijNgUBZqahwYmgoOziyhBZ4PaWRsdqs2BwmTi/mvQN HsTfT0QLVemxJvfhfFaDhKVchd+OlycMBNXv9dyBExxYuyXfX247MPL6EBas+vV9 qfMaBC8WLakpcHzkN0uyTssseP6dOHxvyWbkSYnFWlCEZQyhyTydmQBNAirjBTwA AAECAJoHYggr0xjX0Dnxmjekwri89SlHgxvMjWHHF80xi5MXQNuL81TRDiAIsI62 /a6wfpRNXG+6vqJmq9iQOc4yVgMABRG0HEtlbiBUdWxleSA8MTozNzQvOThARmlk b25ldD6JAFUCBRAq6qj6zT/tLvUlcRcBAYRvAf0fpwQTqCmaLMcJ7x6Tlje03N/W NfFL1pBZrmyv6AppQ9/2Qxo2aGqyfaDlhwX575SLLBxxVTRJS8oBFfjdinfuiQCV AgUQKuTPZG1tOFJzS5pZAQFu+gP7BWMYR7lWYDRLf7tQCp9PAN3sixKV2mqBCAd+ cjkkS0KX2feu0MBc6vMtHxtznIvNJApMs5Vkj8ehJa+KS1mYqfxOT5u8pL2qW3X+ AqP8W80OPxvnshj5WhWc2yciSgG6FjCmJZju8u30cQjInLLi4WODDAc5ils/i7+K kLPgQOSZAI0CKtKJywAAAQQAtDyXWONtwBLEqR2UcAJ9oT56b2L33pKizyjHnQmO Fk2703qZ+3xXQCmnR5dNgAS6afP4JVUlePMxSCWgazVmfK+qRPdWFoXoLJRJQXBc jKb8hSRu6+zeqoRTnnIZOXWzaByOCKrIv/WOY4h1poxA2tDj/jHbyBo4VBgwldon 7DUABRG0LldlcyBQZXJraGlzZXIgPHdlcy5wZXJraGlzZXJAd2Vpc2Uub21haHVn Lm9yZz6JAJUCBRAq3itGbW04UnNLmlkBAW1uA/4pJo5bNCXahpE6paQ/co0mrOzX j2CzupEl0wDj6ylGJlLyc/DS5UhRqbRqk0kz+686K+1IfOwvUAG24iTZ9TIkur12 E9DaQ7K6qX5g6jvpmUuga8eheT8arfDo3WoFAOoim24Fe1z1KOR3H90R+yLLdZ5x 4kW0pecjRCl7+gnUbYkAlQIFECrUa2pKtkq8lXilFwEBheAD/iQ0GsKaQ5gLXkoS hegXtuDBqQcsWJyGEV8h6SjiHBseOUuxWTqEvphs1OFV0WBfa3h732Bp89Bho2fe tiubRSUkrqRe3HMQYpywNxGJbV/IiLn28i8KEugW9oJl+meZHw1XH375cPEalhQM MaMLOkFPFb2nS2uNAZhI71aswCIImQCNAirkL4AAAAEEANAomYnlPXopnms9RtU0 ln9CiLJljssOeflC9A+QIDujXhPTyApbL6VPqSUSoFF/e72xTJixyrwBQhw5lAvf vQPEiGIFQQYxviF+Qg/+6/JVvLCjvnGVFl9kKTEYVeONxBNGiaXuSE0VMQLx47iP 9AU+wYw62aXmTNtW1BUtX5BHAAURtDBKYW1lcyBBLiBDYW1wYmVsbCA8dWphY2Ft cGJlQG1lbXN0dngxLm1lbXN0LmVkdT6ZAI0CKuN2gAAAAQQAqsmezlzittexSL7T 2q3MtZzoGVHC6q2qShatJ3n3WxBy4mgfotY3k3UqFKnoTIt/mYgyAg8blResgagg 7K5d7TnfJiwtz3ugZFuIAouiiNl6yKW9QwinOBLHI81kpLthNJWIiwH5IeAU8M8X G06+mI/QiY1W9SSeOmAzDoV/mL0ABRO0K0RhcmluIENvd2FuIDxjb3dhbkBjZXJp YW50aHVzLnBpbmV0cmVlLm9yZz6ZAI0CKuAF9QAAAQQAzzFX9DWfy6FsVCV3/mt3 UxtMSB1vhQnym5+aLPWS8EE1f7ZaGBqJclUhKiI0uxIMbaBX4qsycjJDeaOHLcQl 7P8XASn8Iom+n3yz53M+YTSJ5MpYVLum/StGQ1eZH83aHk0dh/Eg09nt75/xjpQh qLDsyUtnKyn8J4rCvohckiEABRG0CVRlZCBSb2xsZbQTMjAxMDoxMDAvMS4wQFNE QW5ldLQSMToxMDUvMzYuMEBmaWRvbmV0mQCNAirX8PoAAAEEAMR3OWKIVB4xzN1B o/dXN/b7J7Rs0f/HB/ptEaJE+/xfxd81zXS07ph5Q/djiuIXQD1hKfsVQMoMiig6 fiwRSOCUz4cdojRC5srpuUrrCTH9RVvtpusyCv9IMzKoHdkA2+hrDLBasZQ3LZyK 8/bqmQibg9y3x47nMPUW0H0hLsVLAAUXtDpHdXkgTWFydGluIDE6MTQzLzI2OSAo Z3V5Lm1hcnRpbkBmMjY5Lm4xNDMuejEuZmlkb25ldC5vcmcpmQCNAirV5D4AAAEE ANrK4Za9zBHUPq3EL2rZy1+ZoWWrwlbsnOOBM4Z9RBv5HdL2n4Pd2ORCU6ZT68qz 3gAZrgu9kYSdpHRJ2Z7AMTvkpCc19/xZZ1cmrbu1VaLEdlnJeaS0DIWmM9GYUUaC L9RiKgJzJnA/0mwRQ6bkpM0w+DI5+0zxyaOpetHn8j2VAAURtCdNaWtlIExhc3Rl ciA8bGFzdGVybUBvaG0uZWUudXR1bHNhLmVkdT60H01pa2UgTGFzdGVyIDwxOjE3 MC8xMDlAZmlkb25ldD6ZAI0CKtz3+QAAAQQA06sFNgWhUfPlRJcrkO1V5Bp9iHFT 2WMR9aak0SOxvh05wYmmZdnU9uApEg+bju0zwD8RZdANYQ87dN3L90jHSJH2wMVs yNXcJ6NPlsuc/OKbn7WD42lwNPA3NS/KQImcw2LcfeTQQiqoq420xbjpewVAdh2K Y7/ivl6qbtuRADcABRG0MUJhcnJ5IEthcGtlIDxCYXJyeS5LYXBrZUBmMzMubjEy NS56MS5maWRvbmV0Lm9yZz6JAJUCBRAq3YSHzIbhwBREKj8BAQQeBAC79vQiqzvi lJEBuXLhC1JSukw8ky7R4uHOgv5GcmHiyYHs4hq6aKhpUzgybsmI+HClBO9hIT7h ajVjGYg15UyA7cGytDOo/QjLo3rsNLY5ad7CmCvGgA/0q+DvgmjIzNK5t0Mdgh57 QsV69BXwoH3nKeH41dX/UkKKvh9XkbzoL4kAVQIFECrtmPXNP+0u9SVxFwEBxp0B /jgy0D4FzaEMwO/yb2LYW2DMG+S0t1Gk7I3JQMmsSzGf6BWMv5h7EZRdk94yRDT/ 62ft3k5JsGUPvwa6VLEf6cWJAJUCBRAq3xMSbW04UnNLmlkBAVA+A/95zn/dHFOr D9JhL6tSsQbwKRV7kb6Itwmx3ECaJxuhH4uGVuDCwu9bkSLvILGsCu3t1yuw5Zrh ivtC5khq8MID7EuTSpcWCI125uSQRneTThuH6mJmOjj3dUWPzRZKLa1kbiPH4wca h8sMvUYNJjiPyXryLPv5s7N9VeVz7jcn+pkAjQIqwncSAAABBACvXC8GUY83UrGJ PzD2CG098ZiWfu9yMTPKz2ji+TK4e0KI5M13DWa+1bWPm+WWv0dYnJrKSmQ7sYbK K3owd/byvNIYC6QfN2Nl0C8RcNk4lduLlOlEWXzQuLKPaZhqx9uahtibSnHmf705 lDnXN4ijPAd5ooc30tf/+yHKJrNc0wAFE7QtSmFzb24gWWFub3dpdHogPGp5YW5v d2l0ekBoYW1wLmhhbXBzaGlyZS5lZHU+iQCVAgUQKtBLM//7Icoms1zTAQFkqQQA ndM0KgNy0hBQEI7QUrxMBE1nNzvg5hpoqBO0nCmlckhzB1JZfUATCU9zkNyZ9Vif FuGSnoj1HgPYl4lEDOtASZm8MUupbSb1T1JMdkM6C50t9WjPl6LIj0tldHLGefDq pOTantqCdyz8WuRqUJ7S/JKPTNQ0t5LidT1o4s3/M42ZAE0CKtrZngAAAQIA9UJP v2NsjfiajySZ3ihHPNNUA3J+pBkedcQ6JVpsB1/BS1NVx8KGKivpPXgFtYvtR4oB EZEVlLCZWKoJnH6ZvQAFEbQiUmljaCBWZXJhYSA8MToxMzUvOTA3QGZpZG9uZXQu b3JnPokAlQIFECrchQltbThSc0uaWQEB4uIEAKN+Cl7wUI/1tFckEfZc7WDbsN8F 3wP+mZVanZOeQi8KlViSsatQ7D9E1LfjNo/03BE7vDODpm3l/RHhQLwfDkMuS49E BDF0qhIn45X4v6ImUrF4Fs1MRPQE10lnoWQs2CjStPmSWhG2jvL7xMPSy1r8m4n6 dxGcyxCFML8ckyU8mQCNAiraG3wAAAEEAJuaF6NRnKvVEU3edX8OUxMdb+k3ZRfd 2KM3b7+7mahkMqTfKj/wiNpqbnnV/pKoD3jf35KjO0i+Oa5spGCc3I7VCDDcKhHV 6iZcYD0lpF2ySh5sUFsRGqWO4oo/jyzrNgzV0awrg2IYT5u7ClLXbpuZGcdIKbTN dZuaN9X1csanAAUTtDFKaW0gQ2FubmVsbCA8SmltLkNhbm5lbGxAZjIxLm4yMTYu ejEuZmlkb25ldC5vcmc+iQCVAgUQKtwvCB/LuW/nlgUBAQGbJQP9FE4TZ5Si7z/2 t9bcE46cSm6B3GmrCEO+YC6SNSfSSaVnFTLJFr4h/TgkIWj1giTXTC8+ebB3ulpf 6E4MrwyLrT4dZc3bgZ1bKHlq4w96JWnBcW7FdDxcEc/i4TUnBsZ5RgbJddt7UI/R axCOmlQJyKqtHHoMT4y9p6InZ3KUUrqJAJUCBRAq6MEy7LFLgVt3hU8BAcV7BACH N1PI9Ru5rVVIl53M7zbTpbkgE0neQEWzgiuy7THHS3+Od/aEkZqWxL5GSz9qd1TP TurvKcXXDtuF9frlWio3+z0MqNFRiU7ghex7zYBD/6sVrtRrJG+W0oekGyJ8/hJH iYSfIQuuSHJ6zvBIoIjLN9mMlYk7d8yE91aZhVttookAlQIFECrpIRgnisK+iFyS IQEBbiwEAI6YWLbWGcjUinUQ0D8Baz5te+nZG9eJSYRESrWCOBsdrP8NFj9TV3l3 FRxbSzWT1QGfaZx3u/3VIOpfnG04SrIG4RaEP/mn1PL19ShTQ1bVEQq7XKB+iXXK kInBu3DMaRXAi8Hfq3ifTz/oa6I+GxiDS8CXDda7utC2cQ1WgrSGiQCVAgUQKtpD RG1tOFJzS5pZAQHn0wP+LkupLVZYBbGPfXdkHaCxwRWEc5xBfIRO2SwpJZBBHclF uu0OxxOuilc6bAiswbPHoMSP0MnOChOa+g0BFxhRjfKVXiXhP2Oo1lqAZ41r7E9h 4oYs4YYo7fjM1lZZtezWNKIibuW57lhdyvLMbDx6oxCP55AG7zTWRzL0DQnYsjOZ AI0CKtHW8wAAAQQApMSslBzYEUQzIER/SRu3xXTdruTE0EQ4CZfa9ZNhVbTxe6jo VfUzLTSno6iwzjEJgSeL/yPIukK3hH2whUXLD87dcR+dhSuuK7ans2owRo+cCfH3 zKTyMleHZEAVoTSOaDPVVUfUaDpukr0ujXMBa8DAIuoJrsKPiJ6a6GXD6cEABRe0 JkppbSBHcnVicywgVzhHUlQgPDE6MjM0LzFARklET05FVC5PUkc+tB9KaW0gR3J1 YnMgPDE6MjM0LzFAZmlkb25ldC5vcmc+tBNKaW0gR3J1YnMgPDE6MjM0LzE+iQCV AgUQKtT1Lm1tOFJzS5pZAQEfUAQAjYXS5sbp/8ewlqx/TAa/S7n9DSgppoBEQrqp 4uFDInSWvyVz5VsGgbV7tP1Sxntvt9++xwfn2LdSPPDfBLElAiZ+Fd6yRwVd7wWV bmFml0xFxHwhR6sfovEZ9Mr0RjdeefZhTuN3jWV7EQBHxyFlUQehf7jG104Tn45S v0x7CIu0FkphbWVzIEMuIEdydWJzIDxXOEdSVD6ZAI0CKtW12AAAAQQArC5Odv3q YspAvcmybjWopLbXQJ2EINYd3xiTEnKqKkdyytTIDVIFdmd7sbaaAz9fuGZ4Gg66 Fp+Y3PeVYizkiGIMqpxqcXaLbAaO2A+ZCpmYjbB6s9ZzqcjHUsPF1gg7v1LlDPDG VA1eNxNqcjpAW1PAfN+mL1UhH8u5b+eWBQEABRG0JVBhdWwgU2NoZW5ja2UgPDE6 MTM1LzM0MEBmaWRvbmV0Lm9yZz6JAJUCBRAq1k5AbW04UnNLmlkBAS6nA/9BMkQ9 xoehzuOVyvBRqU7dIDiGR2TKp9q+XTe5tflTqfAhGDJeiUrxVt+FsflXJTQgHmu6 RLXNLyVdZv7N5EyfrQ+SRyxpmPLjsWWCk9CBQ9N0yvGOOgXJHJ/fNDRlW6Ce67qS 0czMyhVe5clvBnGg0dOWddUWOvNYN/u+9G3wxJkAjQIq0f0bAAABBADgjzogl/b8 dE3nct9bIGDrHyLFXMVvcVfK5DUsKvNrah9aGjMF2fPxu5Lujk6btTynY0IfAHuz z/7i7UMfDhLD8YBHBJJNJ28C2TogiIS9jZg+AOWtUvUA+yJ3s1r9CAWgXWFihTYW mu6f9FWBq3WnSKYqre6djqPZrd7oItiG4QAFEbQhVG9tIEFsbXkgPHRvbWFAc2Fp bC5sYWJzLnRlay5jb20+mQCNAirQwOsAAAEEAPELC7P7vLHK5hz9urWhk9BJ+2i9 U1Yzzm6MKM/SI+UAVcXsYTP5g9kGJLUpLVq7KxalB1Rqbvg9FjjIaoiQ+ze7JIPC 5X+e0uU43iLMHkgz2mCg56p9hpgkDxwM3R+cHQ1cr2qrSJb8sClbYtknbgecNM0J MusvUNwtSKqN9fslAAURtExNYXJpYW5uZSBDb3dsZXkgPDE6Mzc3LzNAZmlkb25l dC5vcmcsIG0ubG92ZUBiaXgsIDcxMzMwLjI3MjFAY29tcHVzZXJ2ZS5jb20+iQCV AgUQKtEZf21tOFJzS5pZAQHMqAP9EKg/17mW/gi0eWiUT/PpY+R+jBi0VtXAdq3H Zo+VAFEyARt/fqiOuotiC7OFtnsuTPVtarOSxRpz/5bWdIr7AGIdbnwD2dmZwvqW DBjvPDzQK1MwPPDpyqRtlEdU9LpwFkn9rVy77KShivrp4xHTVu4RjQUZ8EE58ilD yhDolZSJAJUCBRAq0MaYednIlhgdxdUBAaqkA/4gm475FKoXXM9X0/1KH7HRqAiu +VnrfvljT6GJt8c0BGtVsELLAGODAWCuzmP21IWlRznGvipnFXPoTrfi9bkjBijC KmdhB/atLi9FB+YO2B3PWtwmUnWbIa7CQO9vxe4t8jYbyDiICAv72dLJXTHgMxPJ AuFIO0ECqScYfb3ol5kAjQIq0LpgAAABBACUmiHr4bN1FBXm/zO/6Yt1bpyZrbcx Lv/0pFk7/FkaPghdXXyjMZWSnosbw/2dVMMv3R1vJB1mWGl6W+tOkqjeqteOAE5C f/iZHTGE4doS0pGdF8wa6e+mPFRZa/lV+3D9Rh0qDqoAlc0FShvd3aGUEI7eiIB7 cGF52ciWGB3F1QAFEbQ9V2VzIENvd2xleSA8MTozNzcvMTQsIDcxNDQxLjMxNTRA Y29tcHVzZXJ2ZS5jb20sIEJpeDp3Y293bGV5PokAlQIFECrQx1HcLUiqjfX7JQEB EoAD/0YzuJ4LMxKY3CunHyOHmGbAcOEXcG6jqH3GarymZgisy1s1OZB5V5ak4Czr GCj7Yj8k35KDjp+IcQHDM1JpUDUKB5p1iLblWOWmIa0Zb7SgS4gYDY042knkleCY pP39mrBC91SSFrGIWjM+wB9J1Izs8N5bWe0EEJonplR701/omQBtAirXWtcAAAED ALKH2cKuVzOuSo2NTQVwNtiysY+7piD8FZxzjvDGgOYGVJMagPP3ohPmlKVwmky6 ljqtDVaGKDNBmWQlYy4KINpcPI801PtTnqzvLGa3aVs1hMX7mt218hn/G1O2n+md CQAFEbQ5RGF2aWQgUG93ZXJzIChkdHApIDxkYXZpZC5wb3dlcnNAZjU0Lm4xMjUu ejEuZmlkb25ldC5vcmc+mQBNAirXO6sAAAECANunzqcH3SLKWFweZ3BAUXO3OuAI SoBxocBtjmgsvndahwdXFGkQzSPgf6uWt3HIksD0a6sKPOrQjUXODZuyxIMABRG0 OERhdmlkIFRyb3kgUG93ZXJzIDxkYXZpZC5wb3dlcnNAZjU0Lm4xMjUuejEuZmlk b25ldC5vcmc+mQBNAirXWbAAAAECAKOREYOarMoniJ492Q11sfFe5jNAwqb7p5Uy UCPJmcWXZ4mlHIWkmhqOXUM4VArnYKVIrddBDbkaEVBAW2UrY20ABRO0I0NodWNr IEhheW5lcyA8MTozMDgvNjBARklET05FVC5PUkc+mQCNAirUKygAAAEEALVQCans Isa6a+WfQiSOZDko678W7O4A/A7iUmJszodnQD+FVy+L2mcsL9pAjNwhAlHsBb35 FOVyD9XasQoyVFUZUrF7n6M5RruGGMrs5Pv2m1tVzkeZcSTWyPS7ovLQXRltBuS9 QbdZu5j8CzMM6g6GvvbqrK01TG5mb1FL1TGDAAURiQCVAgUgKtoRmW5mb1FL1TGD AQFOnwP+MD6LDlj4EPvT9r9ZsLMy/pYQxMa++JMnAc2Qx+cs+rw8lHU3luXbeLwk JZ2prh3YIdjHc682JGkUkFBSAWemsrAa387CNKU0K7Rsha9qCCXygswqUy1UjOIq cGwB7uP7DR6nM+hklibbMl5acEpmihCEQkjUilcfA0GdWb5yGna0C0ppbSBDYW5u ZWxsiQCVAgUQKt3s7x/LuW/nlgUBAQFOKQQAge7txev1ekLCmnBNuMcSI/r5uLJS vhocppOnvR3MeWXaFsfLw5flwIhiWk/JGiXZ9a28FSdoZZrdDsMsZCSrbqmv0YWx OGV9ojvy8UQkwdNNpJvUe8PJ6jPrHAeNheB0aWC3y5B1QFmK2efUNg9vgklVVv+E FDEC2NJXpp27VpKZAI0CKtCnhQAAAQQAu9vnkZyc27CIVPYL1xZE3Xb+PE0GNLUK AqPcWvWPKHGWmnpo0OLmam9R7tKYHEy3c9HzORS/WTjZyDSi5D/p3gB4YWNQlSwv 9cIuDaOFwlL6Fvpq1ndIDua2QhE4tfOuv6EDbZeVrbbDInJqfveeQf8uSy+epY9G lrv0AJ2yUt8ABRG0R1JpZGRsZSwgTWljaGFlbCBILiAgPG1pa2UucmlkZGxlQGlu bnMub21haHVnLm9yZyAgMToyODUvMjdAZmlkb25ldC5vcmc+iQCVAgUQKtRt1kq2 SryVeKUXAQEONQQAyiiv9L0KkmUXzWePJogB6zO4MDMZi0M53KhwuB9HYqN3Mea+ H67ZiC7W++Uv0WeXUxoZHMo/dBeGYuUvNBrz+y4EjjAK88PFsm0Fpm1okeeQ1Oic 0hBfCr190XvOVgsvJnlex8byyfWher46bXwmqamTxwDdqdABXiCSEUW9MK2ZAI0C Kqw2TAAAAQQAwpYznabkRaLShwri7VwLY8/IdPq1q+T08LdMHlcFgN6B/d2yV1Gm eMmPWv5o7TwUU75AsQj3C0Gq9/U88/mItfuwPa4hWUkfXgw+3JW2Ob1kpvwky0Jb vjTjkGC0cEL3JDdXu9c1XmMzp0TahycfgAj+kEWsYsk8qBMDr1ghTDcABRG0Jkhh bCBGaW5uZXkgPDc0MDc2LjEwNDFAY29tcHVzZXJ2ZS5jb20+iQCVAgUQKq4zVOJ1 3g7/Z/cLAQHKtQP/e6hXbL4W6Jyut3agNrCA7D0SNzHoT5PL09U+oq9+UuzTNjIZ 94VVKAFtNIM/df3U3cXryfJ2X0n1UDpBEIZ6UczVxlG6QInQBhsph+nBQ3TGMQYe wOt3aBPmJaUHe8Fm+L7phuzitKr6DJnNWbX/6hGsx6ffZ/PavQIuBS0eiTaZAD0C KtZoswAAAQGAyUkguJ/Gtcfx+QnAlt5IdcBjVD38DM/JsZXLQPH+rvQWvd0qEzpe hISBrDYTPOfZAAURtBZNYXJjIGRlIEdyb290IChjYXN1YWwptCNNYXJjIGRlIEdy b290IDxtYXJjQGtnNmtmLmFtcHIub3JnPpkAjQIq1lDiAAABBADMGAE/s57s7web wHZuIwfhCYinZ6ANRL8S/lmuC+FvUNp6dXIG5ahLx/Lje5w78vB1+eizA7uhc5Vk R5Taivc+F4EOwWCrnrzYXMch0BOfzcZSrSOaEhINdZiy1OZ0tBGfRFMBIUFjIWCO T4rb8U1TPbXCon6lvwTMhuHAFEQqPwAFEbQiU3RldmUgQ2xpZmZvcmQgPDE6MTI1 LzIwOUBmaWRvbmV0PokAlQIFECsDlf6+Xqpu25EANwEBIxED/22n8dscoVytUdSj O6MBG2tr/Cg0vBkNAuzx+b811IpDb82d9qei4znX+BBXZvaXKO2RCyZ8ECdL3Ejg DvoZ9riZYdumLaWyuzjCXqBIbMPyrHwo/DN0NVxFAUr066c2fdz0uXyoflYp4pCt FSAipfQEdPN/cn0JRf5qXbi344LmiQCVAgUQKuSfsm1tOFJzS5pZAQGTAgP+IYD0 obZ4NDWk3OWIfcI6673UhHUdK786ojzhqeb35qUozy7Go3fpLqg/qMVl6miIjSRh oad4GGGl5N5XlzJ9tdSBa9vLxK4J0bD2eZoZhFIB4ERKoHQtyW/4j3l0mEpbLBFO 4tCSV+telId5XyH58jN+GYQHZB/efNivRD5EH3KJAHUCBRAq11yc/xtTtp/pnQkB AfRXAwCa0gG1V0oAC0znEWWH0979WL1M04/5+S0qJttcLVgiByANgPxCHOb/zVZX w7QISTZ6tUcKAckL7Lz8GGHJFn3tn/S6OF6sBYyaOJJpNemdMbliSyRgfZ9+Hk+o 6Jg5gMyZAE0CKtXavQAAAQH+LvwF92SYQioq3YSF2UUAlzjisHdkzMKF7PnNVwH2 NGlTPWgxjYzYae5wZFRy8xK9l4X9qoJUge6h0N+rIZhhOQAFEbQvU2VjcmV0X1Nx dWlycmVsIDxTZWNyZXRfU3F1aXJyZWxAVHJlZWhvdXNlLkNPTT6ZAD0CKtTNtQAA AQF+MLenkI4RQwnfHOuriwkJNpTkyC/ML3i2nzLHEEl4pQajvHGAxKEEKchmn7GU WLLFAAUTtBhQZXRlciBNIFNoaXBsZXkgKGNhc3VhbCm0JlBldGVyIE0gU2hpcGxl eSA8c2hpcGxleUBiZXJrZWxleS5lZHU+mQCNAirRDBIAAAEEANSxRNwbmOKiEs2J zwsBfn3KRA3y8X0JScH8FCrlq7tKGFVgp8C4bO2UCQ+TT8p1V5cbsB7594ykIAdi 9lCefxXP0j/Id3NBV6Q1CQ4bYnFPcLalBZ6zlGIB9TIdwKxeglqlUxVcPBGpv8YZ OYJJuOxl6x7GD20IzJ1vNJwmRP/PAAURtClNYXJjb3MgUi4gRGVsbGEgPG1hcmNv c0B6aXBweS5zb25vbWEuZWR1PokAVQIFECreDGbNP+0u9SVxFwEBXToB/i/9KOQm rGOZLBDvVOeBOxIkQRyFdFsZ2AdzbZ5m6WcjUFerZj4gaklHUiRAM71qJrXuzH9t aLppjrSVEp7g3NmZAI0CKrCDXQAAAQQAxU0wjvrqWN65bTXGpcphhXmWYM+9v7p0 JArebWIFB1qfSeimbfmPUMhGndQlmiAB7l6KaxCDVMAsOFOrfXQ5mz34voH8fF5f f7gFp0gNp3iD7EiW9oVjVS3+Ex1k2TDS3M1k51Q+I7iNgjKKtF4BSIwKbqNfORNE hOPv+/HFa08ABRG0M1J1c3NlbGwgRS4gV2hpdGFrZXIgPHdoaXRha2VyQGV0ZXJu aXR5LmRlbW9uLmNvLnVrPpkATQIqu2UwAAABAgDAKv0Wo7mBFugi6yOIABpejWBv 96td5+bZzO8q9abOboBFmA6vFxYKvqhRV3l0URshsk8VrPc4mRj8NL7MGZAJAAUT tCpCcmFkIEMuIE1jQ2FydHkgPGY2MTcubjEyNS56MS5maWRvbmV0Lm9yZz6ZAI0C KraubwAAAQQAy5m8cJl3gIaF0Nx9V8mPHof9wHlQUnQWGTNqW4NnfsUruef0FeFw QJUDajdNBY+MiH/vzuzaveAVIRFojgeUVpeNa8gn/cFiCQoLFtKbM308isD9A+81 fK/+sTZcEQWhH2LFbPxb0kQSSTCNK5HejX9bzSIz+wayU4mYQzmyV98ABRG0KlNo YXduIEsuIFF1aW5uIDxmNzU1MC5uMTA2LnoxQGZpZG9uZXQub3JnPokAlQIFECrQ 19ltbThSc0uaWQEBrHMD/0a8m9ZX9jVREbX3RMDV6knJQbZFGu2KL9syqAFcofqQ RWEzOcnQz7+G4XjbXedy1kTTxHKcIGyClXFD7LqgEL8bHD1i5yLU8AHTff41kBtz twlo7GCZlfs9Lqj3qzX9GGXZEeWEOxwl30qBfXXWEsUkFrK84Uh/L0CKa3vpYW6W mQCNAirNLf4AAAEEALMyyNvisb1TJVHyhgvta9npDwFoJIOpJqrv8cr5OpeCOhkT hxhWD/dYmSZEzxlu47BUDj1KyDRemP0og0Lp2xsxJLmAiGWKd4zYlHqKhXAgJJuz KWK8O6BOfZUbFYwCCKGonbPtPPdUPp5KCluSpLBdT2BQsk0okW1tOFJzS5pZAAUR tChDaHJpc3RvcGhlciBCYWtlciA8MTozNzQvMTRAZmlkb25ldC5vcmc+iQCVAgUQ KtDGbNwtSKqN9fslAQH8/gP7B7p7z5BUmfJhZJYdMoSRSAZkVP3LvvpCZGZDdGye 6lxj+WF2X2rCXohAd2jnQJdGCFE+6Q8zP6tTbTikoIksQ0hbP5xFIfKp3Lyeyy06 Mzh2CipYHyHRByGU1q+bQsCYotMIqAntaWcYXEdj6eB6pUxselvFH9RQAV/cPJgu JOmJAJUCBRAq0LwEednIlhgdxdUBAWo3A/9yS1zOQuRHCVx77hzuvC+fue+64jmA 9WWw50Yumq2cnpwSA49iDMepby1CtN5x9RObVNO1UqSfAQ/lgPEJgNyOW8zfWf9L t+vgF5BL+5q0LEOqGj/yQUVs5bhzp961XeVqDSlE7FdaUIZghgn13NFWJK++VLhQ IeY9s3CZR1cbWIkAlQIFECrNY8oYV+Tdsba4IwEBIo4D/jWI/JWxluKBsTTjdNBz Y79dMx16rLLs/o7t/AT9D6HlC2GXSl3VJ47eSvGqNpcuCNnTukixv/7qeFTxSR8I S4V1b1gTu5w4hgfZNKcBK+/RYDnvFs2W49Vu6LyAFG2uqmgV32ojKc9uELG7Cyo4 3u2KfDBEDKCJ0TK8biVVV4SriQCVAgUQKs03K21tOFJzS5pZAQHQAAQAgT0DzRqH vx3lPvdmYe8eW5eMxgGL3o3TuLH3/A8ZrmagSgCtXVQvw5n86xVdMAsfnw+njybo D3oPPWsf656XomW703JFE1XPDiRe/l1gLz+i7sruG+AHrW6ADG1Ls/POMWui130h QN39uSY/3iVnRd4WQTfA+Uw3UmWSi3mTZfSZAI0CKsZlkQAAAQQAvpRxOtg8oVxC NOzW9NvEao3W3da8XbH03xms98grBOF88+mlReQKXobPRj+R+71ZuEOiIGcwoiu9 dO2xb6HR/YubwS31Gu0wFH0b4I2kg+z6Uk1n2Ozysi6Nfu5qcG39Ur9nSHB0ivMn xgERp9XoomDeUeZ+62d3GFfk3bG2uCMABRG0NEdLIFBhY2UgIFsxOjM3NC8yNiA8 Z2twYWNlQGYyNi5uMzc0LnoxLmZpZG9uZXQub3JnPl2JAFUCBRAqyEWZzT/tLvUl cRcBAVysAf9AzA28lwwpOWjQew7c7S2dCf1pZrsbVjvIH/NWMATysrUWE5u2Ptk9 tJYsOijH7cSy9uDIDXKcXHhSCJVWShxpiQCVAgUQKs3JC21tOFJzS5pZAQHyJAQA lMgaSBlNourM5deAGSrgqbinr/T/0nNKCfPpZ3SwKe27No+NEbFmHCpPPjrNSVJo GDN1p8ePSnZdvuqb94cJCGwkdHBWd2c0xAjU4zUY7G+ddogmXfE/7mGdWtXL7Xtg a0vpDZdQ2AubKKCRntaXGNzrqP/5e6csUAhUHd5VLLOZAI0CKrDAUAAAAQQAtjl8 7QTiBTb4jkruf5IgK7Ig01Saj/PZQu8ruZTbkJbXqkb9RN7q2bbG8RLYjJxcEzCR 6a9atG7NNteSuQf4/yu52MxmqIF0BikLD3vqtxMSLKYQpGdXjjAS3T4NhBj4Z7QS 3cijYnWpiMmhHb0egsVV1S3hOnIIZitHZ+yaIMEABRG0K0FyamVuIEcuIExlbnR6 IChMRU5UWiBTT0ZUV0FSRS1ERVZFTE9QTUVOVCmZAI0CKm3yLAAAAQQAsYqAtuUR AJ9xkSJD6MEWfDmDQH6jXoYw+yxgEojttaCMZsEOqeRCgwZqA0mlwbm1fZsqkl16 CLTVKnbZA4yllt2u/8pdFYen8mOs0sBken0H6eWixtGs8uEZlkD86DJToPYawacw NxNpw8PjfCjWD5FSkO/5SMyv4nXeDv9n9wsABRG0LFBoaWxpcCBSLiBaaW1tZXJt YW5uIDxwcnpAc2FnZS5jZ2QudWNhci5lZHU+iQCUAgUQKs04AW1tOFJzS5pZAQEr qQP4zrYEvXhV77y90m2Vew8ZbDD/pxSpVWwgM16uU7CBVlAvMqTs/24qT3qJ4Pcl 2K6P1gCVj0Y+m4PFO07UYEm5UX00BYEZxiFFT4w5CO/4BJfrIu3oIdaadSYxdBz1 uJYZouoE+kEvd35tIppVPXuGLRXdeojXuw/VOGUYgV9aU4kAlQIFECpvUjT0ygCB jeci2QEBOfsEAL90+6LOAaROuDLyKKvcG8yTSg/HbkRUrpYsX8ya2O9NRvr2sLx1 zehE5/nRUKI1Tk2pzp5J94qaS50mjlW+a7Kf5tMz9JVpDPeU8Y3k7+Pnb+DG4lhX BkyUvV3AiqK3x89ZW/jRozIHM+JdT7gyUQ3Vtf2P/4zTvlHyocusmGIgmQCNAips wZkAAAEEAMrcqvIwyKcvxWjFbUIq7/hhzWTrpeThdIxJl7T6P1sX9U6axBhSa1qE 8LxwzTZ7/fhqaUlcZbrho5WODDqge325k7c2DCiIGxG+awndQR7a6X28/U05aQXQ iMnS+IgDOLo6gCtGUFoLDoUob5AuljqHlOrQovmoIPTKAIGN5yLZAAURtCdCcmFu a28gTGFua2VzdGVyICA8bGFua2VzdGVAZndpLnV2YS5ubD6JAJUCBRAqbfKQ4nXe Dv9n9wsBAcIXA/9w7xBNQn8sTkmfBy6S6tFk7GFGHvQA/9eryxHlqjDDhBKQeSJJ GvPHmNQQ32CnVuv6M54qxT9iusopMv1RFS4ZXTB9u5KV4ajBGvkGfMsHLYgiAEcd UwndShAm6St/zRoJzQ3ae0mAFk9MYJKYcMuJYL3wCZjrrI5YNrrhSO52w5kAjQIq ezKiAAABBADWbUO71XAVqN9dlef3kGRtlsSA9gnOkoRCzVlo4hFvO792Ie/Y1p/c 5pz2YAyU+9C0beZHVWHwofAdUmdpF3iz2q+4viODLN2UbD2E7hoPjm3HLLjgiRCK y7lBjtEofLm0TU2mSuAZOR4zKaNcCRcRcSCYtAiJZA/6EarpnZl9RwAFEbQlUGV0 ZXIgR3V0bWFubiA8cGd1dDFAY3MuYXVrdW5pLmFjLm56PokAlQIFECqkeZfidd4O /2f3CwEBrsYD/AqgSbc7d3qYO5Gww2MxZX4gA04nzHbyx3XnX6xWUOU6w+Rx/X/0 0hP42og+P3Rf+pBg0y4KiIe7hY2TOb6neh3qpcpxkHQKtUkRQd6zYFNRuYoRNTge usTiiAv0cL6RYaZFWt44RzbOr3tJZrz3uPHLz2nvDvec4zPHvMoWyeVFmQBNAiqK PnYAAAECAM4DUPnxdjb43Il+yDkRUO8TgzOW/hjTs1/blllrVe8HDlABqHZMib0a NFhKRFYjvsNS3xk34N65vtlI/HoTNvUABRG0IUhhcnJ5IEJ1c2ggPEhhcnJ5QGNh c3RsZS5yaWdhLmx2PokAlQIFECqmFtb0ygCBjeci2QEBqVwD/A/8vnke2KFNyFLT OdYhiAZlbpPuo621TIYWVxPJ+D+TVkELdn7HWmDpDGQ8l/7XmuDEBrGjFiQj1Mv6 7+rnEqhA4ufKyKS57GuSZ90G99iLLimCiA9ytQyRz8Wi8GUzh2lpv7/478NvxEgy a3nVM6LwkXodv4OYPVxUnLoSNFGFmQBNAiqc8q0AAAEB/i6Q/XxMaNqWP1tY4D8v Hr5KiwFz1XvE9F5ltPVPeW2I0EORg6u7xSlreXo9OvRd0BbF+UdOAjH7Pwvhv9xi BCMABRG0IkplYW4tbG91cCBHYWlsbHkgPGpsb3VwQGNob3J1cy5mcj6JAJUCBRAq p3Bp9MoAgY3nItkBAegyA/sEwCWN7IU1T0NVNkcOcqe+lCn8P42UfX1RUKqCfErq T51BAPnSIz0naWFQII8ZE41FQQ6iuKnbfKpmIi4VelzcjzsEwdw15cdnyV8O9FXQ 25ysMe1C6LkodMU20XMjH7744n0NG15PWbNcmwNOQ2119tw+u9rRuuC6PFWFvX0w VZkATQIqxyFfAAABAgDhOocrwWVLJVToItdrune/+sjCF1+GiiEXH1d8Gv8rB5fr pXeGoAtWFvmIpmHgPv21zgcR/2Pykc0/7S71JXEXAAURtDFUb20gSmVubmluZ3Mg PHRvbWpAZmlkb3N3LmZpZG9uZXQub3JnLCAxOjEyNS8xMTE+iQBVAgUQKw7lYq+0 ixu9+x8tAQE8EQH/ekB1naYVMjS32UNxfoWzLs8Scm2mAOhTNPTdaXrFgiaLoP9Q bxLt7gS6JlU28uRU3PrzxleFl9ZlBaaoyqRdzIkAVQIFECsO3ggN91aF3b4N1QEB w5UB/3qPWHWzh9ktog9168XSPLVyKSDz5RCKfRc1Cnf2+iUUrG+kh9IFIMrOB14r AMdhOJR105MmsAzlfaYdXkwjIr+JAFUCBRArDtXmThgGN4+JhjEBAXbbAf9U8Wpa el26ikgjnHGwstsfaTUk59Lmu9K4q+hxTS9BovZnVq+Bbkmbx6dRtFhh8qR6bkT+ hAE8BrJ4BB8ZBaU9iQBVAgUQKw5c7VQDRxQAIuUtAQHk4QH7BmaPxtehZJOyQYjV aRyCtMkXdcTBk7tS8FdGK310DMCqr61mZQrVli7RmzAq8pQSJ3GjhvbYum3TEnl2 8P79GIkAlQIFECsOzyWh9UOl6XLwEQEBYCwEAJzTGLfan9mbFzNx1yubrHIofOdT LSaxyPHKd8eiYgWheIOnTTWS0en6JOSWsGfp83lTBBH5USCIxOtf+WzK0SbydKhT xbHPouryo6d1Ycmgty4rKwluEQjuytT5mz0nrlHXgrRo15WeumFNC9oPoLq/Tiu1 StGfqk/gwvntHQQBiQBVAgUQKw7JTIxutC9MEx9XAQG/kgH7Bh1HrIvqVgAWn2n0 3fpqOZTZKKQ0yJyWAtwn0fOaO6Yb7ze83IlqnylArrYB4MK/sgY09M9k7py4lAqg Xu3wdIkAlQIFECsOvwqtUkpRhRl/tQEBZPYD/j/kPMH9agh0dBP7oKUuFgAAt5Qo Wlu7KO7YHeRyDzAbwIncksQkIy+ZKA+X8EYJVNXESesdBile0/guom4d78FWQwJK mhz4JsNlfIkaz8pKrClSrmvLUh4cLThM8O8139slsQXCHoK9xoiDwOzwu/wdeD7d L9OFdWXkEvHQmPk3iQCVAgUQKv2NMuo6/NNxlGvfAQGuLgP9FaHSxeXSFv2P92ku EBCBg5Vxi044apXRITH3qaGNYMTlZ4uVrGrP3ycl/yQEwr1SJsTPGGEmXC250586 Gd59ZwAE0YS6I3HywaO7I/T/2DoJ6aN6op9r9MjfmATr0qCtAOh3iwLWH0249Wou n2pSVqlV6u9uwKW7U43M9Wan/MqJAJUCBRAq0OE2bW04UnNLmlkBAZGsA/49Wsio wQ96ICa38r2CNbbFY5VBqvlfu/74L/wGohiPyaaYZ129BrT3y17kLU7K6cxMrRe0 XPuQi9wMmF8rOan6t0jpN8ZRG9qyaKtEUA/E9336UlwhDIiceJEMBEW5vXEY5D5D Wd1expfV/Q73e/P+SNdjRKgLwhRFjQ4WE8XWlokAlQIFECrLhGIYV+Tdsba4IwEB of4D/1LcLzjP0Ir80uXVNzPPaHEbpHgLjWnA89Hj0tfXA0Np95zVHKENQ9U/fuRz 5G27rHFmy+wCTX2zsrDBgTlKn4hGwOTz5CDfnjnB8NVQ19Xt9KF/tlbe1ljbJtmn cY/dPMfwkWlCPFHLXPWw3IiFlJo1hRvxrAM364ya3zNTVJsPmQCNAir9fucAAAEE AMXg/uYJqIqJ8pr9B6QTh7NOgqSMpwJK2v2QfZ4Ur4jeCiz1vJoXsxlOwsLEqRJZ wT+8/atljTbVWepJZbgqzCJK2J5c0+p32mjUSQVZvF9CU4gPbCehUgoToHmheGQ+ kkzimXLi39XzqoyT3ORZ07cQT+1DgEBDVa1SSlGFGX+1AAURtB1Kb2huIEdpbG1v cmUgPGdudUBjeWdudXMuY29tPokAVQIFECsO9LdUA0cUACLlLQEB+PEB/2+N0xYQ Sfqepii8vJYDtAevhzkQyupPuNmhPUGi8148Dx7IckqX3qv9ZyWKdFBuWQqYAJoG 7Gnd+wEn6SVkztOJAFUCBRArDuRKr7SLG737Hy0BAbOpAgCWUETOCKU9fmj4n1Y7 WbnbSMT6w2ua8eSGIy7olVdL7r+LG82ZTOh3PhYkdZXBobwumoMzzmlJzbu+lQh7 7L+biQBVAgUQKw7dvg33VoXdvg3VAQFyKAH+KCRi9cjMCVAldkdTNW+gbXXkk0r8 55hQ4ewrP5ELRqwyvYJZDIKoxFOC61LaDNg9Xzu18jNFGmRpsCMC/LX9eIkAVQIF ECsO1LpOGAY3j4mGMQEBdj8CAMI7zD5bBXZtZ7mzikXo4/c5E6J6Jgyjwm7+FjMe zWiEEg2QWWTsqeyBCRTqE9xcG6YGJiJd/sSf0lBWM1RU9IiJAJUCBRArDs4v6wCT 6wJFxDUBAXLbA/9uz6/Ek1MH0iB2bgHELKBYH8mL0v1/WtPp13XKjFkLRkUepcsJ FqQUN5n9EVw7PxLPMkaQMsgC2o+JrLuGqAIkQd73kucr3iKHfB25ErRx0dMLrpQF A13/5P16VJNXBTW3juNl6oMq5z7Up7jfTB+RJoeUV/92DF+Qi20itrvWs4kAVQIF ECsOyK+MbrQvTBMfVwEBlE0CAMM6o1rAcb2UntVueGoBjGRYUApxhdSZD1LbQV21 B/jzbYtEDQ/cbf/b3kMv/rgZWEJQyoVL62xnTd0TXr8xwr6JAJUCBRArDsUxofVD pely8BEBAWg6A/9h8kODUzDaASOq0fdz386YKnPjId7hik1Nol66tMS0J2PdRLJr VuNyuYDwbH9iREeovQ4mow6/es7zY+Nx8/c6yNXMHQlj/OKJNJ9KrPfENkLMzd8J zkqUFVnqdEHpmZYxrysz9y72br7KTLmzAnumCERSWCNI/G8+SBMh4q+kbokAVQIF ECsOvpfNP+0u9SVxFwEBs44B/3UqcFw085h9KPigF39nI9U7MxhwdzsbLEdRL0OW XP4TQt6azApOhfKUvFHTo7dAoP3aQPVKirfA+zNIFIFC7ASJAJUCBRAq/YCy6jr8 03GUa98BATuWA/9KG5CXCoDPpthcfsbA2eYIhi7GduqSkFi2//ibeH5HTqtEUrlk PGPQuxSmMuQSaUhAGQrYpVMSpTdcv3BWf2jAUgMgoXwHkCIBqOaG0Gwjijnm8+ho x6v+9zr5KvylqreCWTWdFuxP379+gFEsN8t+gXIH9GiXHjeul4jnD+HgNw== =MUTM -----END PGP PUBLIC KEY BLOCK----- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Richard Childers Date: Fri, 27 Nov 92 20:28:30 PST To: cypherpunks@toad.com Subject: Re: Electronic Banking Message-ID: <9211280427.AA21844@rchilder.us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain "Using the net, the 'banker' could easily be 'offshore' and not subject to US law in these matters." Feds busted some folks doing just this with modems in Puerto Rico, I think it was, within the past year ... heard it on NPR, maybe it was BBC or CBC ... -- richard ===== -- richard childers rchilder@us.oracle.com 1 415 506 2411 oracle data center -- unix systems & network administration Klein flask for rent. Inquire within. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Richard Childers Date: Fri, 27 Nov 92 20:42:26 PST To: cypherpunks@toad.com Subject: Re: PGP on local machine (was Re: MacPGP) Message-ID: <9211280441.AA21906@rchilder.us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain " ... some kind of hardware device which isolates the line and all that." I believe part of the MIDI specification includes explicit decoupling of each device from the network via optical coupling. ( Ref: _MIDI systems and control_, Francis Rumsey ... "The interface incorporates an opto-iso- -lator between the MIDI IN and the device's microprocessor system. This is to assure that there is no direct electrical link between devices ..." ) Anyhow, such a component is commercially - and easily - available. -- richard ===== -- richard childers rchilder@us.oracle.com 1 415 506 2411 oracle data center -- unix systems & network administration Klein flask for rent. Inquire within. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: norm@xanadu.com (Norm Hardy) Date: Fri, 27 Nov 92 21:35:51 PST To: cypherpunks@toad.com Subject: PGP with license Message-ID: <9211280507.AA11162@xanadu.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain This was originally addressed to Phillip Zimmermann. Thank you for writting PGP. I have not run it on my Mac yet because my version of Stuffit is 2.0 which deems the PGP.sit file to advanced. I resist the incentives of compression program authors to produce frequent incompatible updates which cost money and delay for little apparent advantage. Compact pro is a shareware program that produces self expanding archives which presume no pre installed decompressor. It is available by ftp at sumex-aim.stanford.edu info-mac.util.compact-pro-133.hqx You may forward this to whomever does the Mac version or send me his email address. What I really am writting you about is to suggest that if you wrote "another" program compatible with PGP under a PFP license that I would pay at least $50 for it. I might pay more depending on my experience with the free version. I would accept delivery by email. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Fri, 27 Nov 92 18:16:47 PST To: karn@qualcomm.com (Phil Karn) Subject: Re: More comments on dongles In-Reply-To: <9211272352.AA09880@servo> Message-ID: <9211280216.AA05139@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > I still disagree. Even if all the crypto operations were done in the > dongle, it wouldn't be a "turnkey" device that could operate totally Maybe not "totally" (there are no absolutes) but if well designed, it could come VERY close. > automatically. You'd still need a way for your host computer to turn > it off and on, to select a public key for encryption or signature ... > ... I.e., you'd have to run special driver software on the host anyway. The way I envision it, the host must NOT have the ability to turn it on or off or do any of the other things you mentioned. The assumption is that you DON't trust the host. All these commands to the dongle will be given through the keypad and/or commands you type in from the terminal. So if the host does not even need to know the dongle exists, it is automatically independent of what type of computer, operating system, communications program or terminal you are using. > process. If I want to decrypt a file, I'd send the dongle the IDEA (or > DES) key that had been encrypted with my public key. Once the dongle > responds with the decrypted IDEA key, I can perform the actual IDEA > decryption on my host computer with no further dongle interaction. Again, you are trusting the host. What if the decryption program on the host has been modified to quietly write the plaintext to a hidden file. > speed, not the speed of the port that's talking to the dongle. Once the host decrypts the file (at a high speed, as you say), you want to view the file, right? That means the plaintext is transmitted from the host to you. Anywhere in the link (which could be a simple RS-232 connection, or a chain of network links, modem connections, etc., someone may be watching. With my design, the decryption takes place at the very last step, just before showing up on your screen. > A palmtop ... would make a good platform for a prototype dongle. > Most have serial ports (standard or optional) I have thought of that too. I would need one with two serial ports though. If you know of a good, cheap (can something have these two properties simultaneously? :-) notebook computer with (option of?) two serial ports, please let me know. > Since it is a sensitive step, RSA key generation could also be done on > the palmtop (although it would probably take hours) or it could be Since that is not something you do every day, I think you can tolerate it taking a while. How long it takes also depends on how much security you want (i.e. key length) > main reason for using the dongle is to limit the trust you have to > place in a borrowed PC (as opposed to protecting against your own home That is just one of the reasons. The others are convenience, lack of trust in the host or the network, use of a terminal (which can't run any software locally), use of various computers/terminals (at home, at work, any other place you happen to be) use of an environment for which no PGP implementation exists or on which you do not have the access to install any software, and I'm sure you (any of you) can think of other reasons if you take some time. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Richard Childers Date: Fri, 27 Nov 92 22:00:11 PST To: cypherpunks@toad.com Subject: Re: Mac PGP report and Rander progress Message-ID: <9211280559.AA22444@rchilder.us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain "Has anyone given any thought to generating random numbers by counting particle emissions from a radioactive source? This might be more reliably random than using purely electronic means." The Exploratorium has a display - a large set of charged plates by which one can see spark trails elicited by high-energy particles as they pass through the array - which has often intrigued me as a source of noise ... what is more unpredictable and harder to spoof than a cosmic ray detector ? Especially if you use not only the timing of the particle's arrival, but also its direction through the array of plates, as inputs to the random number generator ... Air pressure, temperature and other ambient factors in the environment could also be used as sources for unpredictable inputs ( measuring very small variations, IE, millions of a degree or some such ). -- richard ===== -- richard childers rchilder@us.oracle.com 1 415 506 2411 oracle data center -- unix systems & network administration Klein flask for rent. Inquire within. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Fri, 27 Nov 92 19:43:52 PST To: karn@qualcomm.com (Phil Karn) Subject: Re: More comments on dongles In-Reply-To: <9211280249.AA10136@servo> Message-ID: <9211280343.AA07573@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain I think we are using different terminologies, maybe even different paradigms of how e-mail and other internet functions are accessed by people. In my terminology, "host" is the remote multiuser computer that is on the internet, and provides access to users via dial-up modems, local RS-232 terminals, and PC-s running terminal emulation programs. The host could also be a BBS system (as in the case of FidoNet) which provides mail forwarding for you. It could be an on-line service such as GENIE or Compu$erve. Local equipment is the terminal, or Pc or Mac or whatever, that you use to connect to the host. It could also be the laptop that you connect to a cellular modem and connect to the host while mobile. You could always use the same local equipment. Or you may use different types at different times (a terminal at work, a PC connected through a modem from home, a firend's Mac, a borrowed laptop using a cellular modem, etc). The connection could be direct, as in the case of a terminal or a direct dial-up by modem. Or the connection could go through multiple channels. For example you could dial up a TYMNET POP, and then connect to your host. Or, you could call up a terminal server, log in to a guest account, and then telnet or rlogin to your host. In this scheme, the dongle sits right between the local equipment and the connection. > >The way I envision it, the host must NOT have the ability to turn it on > >or off or do any of the other things you mentioned. The assumption is > >that you DON't trust the host. > > If you don't trust the host, then why are you running your plaintext > through it? In view of what I have said above, I am NOT running the plaintext through the host. I am running it through local equipment, which I may or may not trust. The host (being the multiuser system, administered by someone else) is always less trustworthy. It is directly on the network/ It could be immediately transmitting everything you type to NSA for all you know. > ... if the worst that can happen is that the only slightly sensitive > plaintext I'm working on at the moment is compromised. ... > But I would probably NOT be willing to trust the same PC with my > secret key, because it would compromise EVERYTHING I have ever ... > Do you understand the distinction here? Yes, I certainly do. That is the reason for having a portable trusted device in the first place. But, in this sense our two approaches (my smart dongle that does all the crypto functions, and yours that only stores the private key) are absolutely equivalent. None of the two exposes the private key in any way. > >So if the host does not even need to know the dongle exists, it is > >automatically independent of what type of computer, operating system, > > I seriously doubt this will be practical, even with constant > interaction with the dongle's keyboard. See my next post "STORY: scenario of use of Crypto-Dongle" for my vision on how this would work. Then, if you see any problems with it, or suggestions for improvement, please let me know, so I can improve it. > to truly sensitive things, like typing in my pass phrase to decrypt my > RSA secret key, or perhaps hitting a key to re-enable the device after That is the kind of things I intend the keypad to be used for. > Most palmtop keyboards are a real pain to use ... The dongle will have a numeric keypad, somewhat like the touch-tone phone, with letters on the number keys, and a couple of extra keys such as * and # for functions. > >Again, you are trusting the host. What if the decryption program on > > As I said earlier, your "fully-functional dongle" fails to prevent This misunderstanding is due to our differing use of the word "host". When you said the host would send the rsa-encrypted key to the dongle, receive the decrypted session key, and then decrypt the file, I understood you as meaning that the remote multiuser machine is doing all this. Now I see that you meant for the local equipment to perform the decryption. The problem with this is that you are depending on every piece of local equioment to have a copy of the decryption program, and every version of that program compatible with your dongle's commands structure and key format. Or you'd have to carry a several disks with you, with a version of your software for every platform you could encounter. > >Once the host decrypts the file (at a high speed, as you say), you want > >to view the file, right? That means the plaintext is transmitted from > >the host to you. Anywhere in the link (which could be a simple RS-232 > Eh? The model I have is a local PC, possibly hacked, with a serial > port connected to my personal dongle sitting right beside it. In this case, you would have to save the encrypted message into a file on the host, download it to your local machine, and then decrypt it using the above approach. This would be some amount of hassle, when compared to just using the mail reader software on the host. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: crunch@netcom.com (John Draper) Date: Fri, 27 Nov 92 22:48:18 PST To: cypherpunks@toad.com Subject: Classified info and other stuff. Message-ID: <9211280644.AA24107@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain George Gleasin says: >I'd like to ask we have a general agreement to not post things which may be >classified. No point giving the govt a good excuse to stop our R&D projects >cold. I absolutly agree...As an ex-air force person, they can get really nasty if they want.. Oh, By the way, numerious complaints have been said about the way that the Mac PGP was stuffed when posted onto "umich'. I will be pushing for releasing it stuffed with a self extracting archive instead. I also had problems and lost significant time acquiring the new stuffit in order to extract it. John D. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Fri, 27 Nov 92 20:17:26 PST To: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings) Subject: Questionable Discussions (re: How far is too far?) In-Reply-To: <3920.2B16E302@fidogate.FIDONET.ORG> Message-ID: <9211280417.AA08200@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > U> myself getting a little uncomfortable with some of the > U> more anarchistic ideas expounded in this and similar > I agree, even though I'm interested in uses of encryption other than > privacy, implementation of privacy systems is a baseline to a lot of Yes. Once we have privacy, we can safely discuss all the other topics... -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Fri, 27 Nov 92 21:00:47 PST To: gnu@toad.com (John Gilmore) Subject: Alternative to physically meeting In-Reply-To: <9211280415.AA12997@toad.com> Message-ID: <9211280500.AA08808@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > person identified in the name field". Don't sign someone's key unless > you are sure you can make that statement (like, they're standing in the > same room with you and they verify that they key ID matches their real key). > Don't sign a key that you received by email or over a modem; it might > be from someone impersonating your friend (when they left their keyboard Here's an alternative method if you know the person (know them well enough to recognize the voice on the phone): You transfer the key over a non-trusted channel such as electronic mail.. Then both of you run a secure hash function (for example MD5) on the key. The result (128bits in the case of MD5) is then converted to alphanumerics using something like base64. In the case of 128bit hash, you end up with 22 character verification code. Then you call each other up on the phone, and spell out the 22 letters and verify they match what you independently computed. If they do, that means the key transferred over e-mail is correct. This is of course susceptible to the kind of attack where someone stands with a gun pointed at you and makes you give the wrong key, but that attack can also be done if meeting in person. I.e. someone tells you they are going to kill you as soon as you step out of the room if you don't give the compromised key. But at least with this attack one of the persons knows they key is no good, and you will avoid using it for sensitive material. Can you think of any other attack that this method is susceptible to? -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Richard Childers Date: Sat, 28 Nov 92 00:27:13 PST To: cypherpunks@toad.com Subject: Re: comments on Don's "Cypher Bank" Message-ID: <9211280826.AA22989@rchilder.us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain > I will maintain a public list showing handles vs. Amount received, > in collection, and in escrow.(Set Subject = "BANK" to get the list) "You should not disclose someone's balance to anyone else, and certainly no[t] to the public. Someone requesting their balance should send the request by any communications channel (anonymous mail, newsgroup, anything) and sign it with the private key corresponding to the public key used when making the deposit. Then you should encrypt your reply (the account balance & any other info) using the public key, and send it back through any channel." Maybe both options should be supported. I can see how some people would like numbered accounts, a la Switzerland. However, it's not likely. It would be abused. If you want to oppose taxes, that's one thing, but it should not be confused with the electronic trans- -fer and maintenance of funds. It might be more likely to arrange for a compromise where numbered accounts are permitted iff account balances are publically available also. This might have interesting spinoffs, such as allowing a much wider range of interested individuals, access to economic data at the level usually reserved for banking institutions. We might - as many people have noted - learn much and contribute accordingly to both economic and cryptographic theory. Personally, I think things are much more likely to remain aboveboard if they are never placed out of sight in the first place except where it is strictly necessary - and that necessity clearly documented to all. -- richard ===== -- richard childers rchilder@us.oracle.com 1 415 506 2411 oracle data center -- unix systems & network administration Klein flask for rent. Inquire within. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Richard Childers Date: Sat, 28 Nov 92 00:42:52 PST To: cypherpunks@toad.com Subject: Re: ping..mailing list integrity.. Message-ID: <9211280841.AA23039@rchilder.us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain "So if you posted a message, you could check in the evening if it got out or not. If you are not sure if you are receiving all the messages, you could maintain a simlar file yourself, and at the end of day compare your notes with what is received from the list." This could be spoofed by an intermediate delivery agent also ... Generally, in netnews, I regard mail back from individuals or test sites which honor posts to *.test newsgroups as adequate confirmation. These, too, could be spoofed, I suppose, but that's a degree of duplicity that is so complicated to maintain for an indefinite period of time that it is unlikely to ever be put into practice, IMHO, since it's bound to fail in the long term, and would probably result in a backlash of disfavor towards organizations practicing, supporting or funding such behavior. Perhaps an equivalent service could be implemented where some people's systems make a point of sending mail directly to posters to verify that their posting was posted. Bitnet's LISTSERV software does this, which is very convenient when one is managing a listserver entirely by email from a few thousand miles away. Other mail servers - Home Brew Digest comes to mind - do the same thing ... Grist for the collective mill. -- richard From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Richard Childers Date: Sat, 28 Nov 92 01:08:42 PST To: cypherpunks@toad.com Subject: verification of posting Message-ID: <9211280907.AA23308@rchilder.us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain Below is a copy of the email I received as a consequence of posting to the Home Brew Digest. Of course, the HBD is a digest, not a mail list ... but it occurs to me, it is much harder to interfere with the operation of a Digest. The Digest comes out once a day, it has ( usually ) a table of contents at the top, and, if one received email telling where in the queue one's message was, one could verify it by reading the Digest when next issued forth. As well as discussing it with individuals separately via email, which provides a redundancy of sorts to this verification process. Eternal vigiliance and all that. Freedom is not a passive process !! -- richard > From homebrew-request@hpfcmi.fc.hp.com Fri Nov 27 18:31:24 1992 > Reply-To: homebrew-request@hpfcmi.fc.hp.com > Errors-To: homebrew-request@hpfcmi.fc.hp.com > Subject: Re: A clarificatioon on clarification > > > > (This message has been generated by a program, and is for your > information only. No further action is necessary.) > > Your article has been received for publication in the Homebrew > Digest. There are currently 2 article(s) ahead of yours in > the queue that will be published first. > > Thanks for your submission and your support of the Digest! > > > Rob (program author) > > > From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: VANGUARD@gribb.hsr.no Date: Fri, 27 Nov 92 16:37:46 PST To: cypherpunks@toad.com Subject: Random numbers Message-ID: MIME-Version: 1.0 Content-Type: text/plain It has lately been discussed different ways to construct pure random number generators by means of radiactive decay. I must admit that this is a very good way to produce such numbers, but for a number of reasons it is impractical to use such a device. (High radiation levels are needed too produce a significant amount of data.) What I have been thinking of is a way to reduce the amount pure random data needed to produce good random sequences. The way to do this would too have a weak random number generator like: R(n+1)=(17*R(n)+1)mod256, and then inject the pure random into this function giving the result R(n+1)=(17*R(n)+1+PR(t))mod256 or something of the like. Would this constitute a sufficiently secure stream of data for use in one time pads? Has this been thought of before ? THE REST OF THIS MESSAGE CAN BE SAFELY INGNORED: A friend of mine now serving in the air force gave me a report of the cryptographic devices used for communicating on permanent lines. (Twisted pair or something dug down). The machines used till now are huge totaly outdated mostly mechanical monsters. While not transmitting data the machines produce random data to hinder traffic analysys (like how many messages are sent), these data are produced by cookiebox sized thing, and I strongly suspect it to be of a very mechanical nature. Thats how a came up with the idea of a very inexpensive way to produce random data by mechanical means: Use a contaner filled with marbles some made of conducting, and some of non- conducting material. Then mix them in some way or another (this is bound to make a lot of noise) and in the container there should be a few closely placed points of contact that would be able to send a small current through a steel ball if it where to pass over the pair of contacts, and what do we have: Random Data ! (I know this is not very practical at all) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: edgar@spectrx.Saigon.COM (Edgar W. Swank) Date: Sun, 29 Nov 92 07:56:36 PST To: Cypherpunks Subject: Re: Secure key exchange Message-ID: MIME-Version: 1.0 Content-Type: text/plain On Nov 26, Mark inquired about "secure" methods of exchanging public keys. Apparently the only really secure method is a physical transfer face-to-face with someone you know; or to have a key certified by someone you trust whose key you trust. [PGP has key certification built-in; for other implementations, just digitally sign some form of the key to be certified]. There is no secure method of exchanging public keys using only the net. As far as you know all your messages, both incoming and outgoing, are being intercepted by a "spoofer" who will substitute his public key for yours in all outgoing messages and another public key of his for each unique public key intercepted in incoming mail. A few methods were discussed on Extropians of trying to get a genuine public key distributed by outsmarting the spoofer. But if the spoofer is smarter than you, these methods will fail. That leaves methods which exchange, or at least verify, keys by other means than the network. I proposed a service to verify keys by paper mail and (optionally) telephone. Here is an update of what I posted. The offer is still good. ================================================================ I'd like to announce the opening of the Swank Public Key Verification Service. To become a customer, do the following. 1)On a piece of paper put: a)Your name and Network address. b)The "armored" ASCii form of your PGP 2.0 Public Key. c)(optional) Any other information you want to certify about yourself, such as: Home address. Mailing address (if different). Home phone number. Occupation-Work Phone-Work Address. "I am not a law enforcement officer or agent." d)"I certify the above to be true under penalty of perjury". e)A photocopy of your driver's license or other picture ID with signature. Actually this is a photocopy of all of the above with the ID on top of the original. [note: if you don't want to reveal your home address, you can cover that portion of your photo ID. Your name, photo, and signature must show] f)Your signature. (NOT photocopied) g)(optional). have the paper notarized. 2)E-mail to me edgar@spectrx.saigon.com (Edgar W. Swank) An ASCII message containing Items a) through d). You may encrypt this with my public key (optional). 3)Mail to me at Edgar W. Swank 5515 Spinnaker Dr., #4 San Jose, CA 95123 Via U.S. Mail or alternate such as FedEx: a)The paper prepared as specified above. b)A self-addressed, stamped envelope. This could also be a pre-paid FedEx envelope. It could be addressed to a trusted friend if you're concerned your own mail may be intercepted. c)$1.00 cash (preferred), check, money order, etc. Payment by check will delay processing until check clears. If you don't enclose a self-addressed stamped envelope, enclose an extra $1.00. That all you have to do. Then what I will do for you: I will visually verify that the public key on the paper matches the key I received via E-mail and that the signature on your photocopied ID matches your original signature on the paper. (I do not claim to be a handwriting expert). I will send to you by return E-Mail your public key signed with my public key. I will send to you in the evelope you supplied (or to the address you specify) a paper about myself constructed as described above (but not notarized - if you want notarized send an extra $10). This will give you a verification independent of the network that my public key is really mine. I will post your machine-readable ASCII record that you E-mailed to me to Extropians and Cypherpunks (optional, specify if you DON'T want this). This feature is subject to no objection from Extropians and Cypherpunks list management. I will keep your paper on file for at least one year. Anyone may request a photocopy of your paper (and up to three others) by sending me $1 and a self-addressed, stamped envelope. I will also send your machine-readable ASCII record to his network address, if supplied. Any customer may also phone me directly at (408)227-3471 during reasonable hours and I will verify your/others public key(s) by reading them over the phone. Edgar W. Swank 5515 Spinnaker Dr., #4 San Jose, CA 95123 edgar@spectrx.saigon.com (Edgar W. Swank) (408)227-3471 (listed) Cal. Drivers License MO531219 Retired from IBM -- Employee #788281 I am not a law enforcement officer or agent Here is my PGP 2.0 Public Key: --Type bits/keyID Date User ID --pub 1024/87C0C7 1992/10/17 Edgar W. Swank --sig 67F70B Philip R. Zimmermann -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.03 mQCNAirfypkAAAEEAKe2jziPeFw6hY19clR2GtQ4gtGCSSVOTgPKEJzHfuC74Scf 9PEuu1kebLhHk43A9wo1vr52o4jpH/P/tnFmRtBQOMzLUzAt5rMucswtSVviMQS2 hBuc9yGJKWHVcyfA79EARKEYTdhx+2qKI+hFJcPE+rmD8wVoF94nNf3ah8DHAAUR tClFZGdhciBXLiBTd2FuayA8ZWRnYXJAc3BlY3RyeC5zYWlnb24uY29tPokAlQIF ECsRFxzidd4O/2f3CwEBsmID/2qXL/VdjGxxYFNIZdA+DC6howUXlHw66MUArILE 2/9J69VvcpbQTKmD4A+04SwH9q8SDzWxsg+1VANuy08EE0up9pm7ZBzrxkFcOydh sEwOt9fRn9EJ3tDNYe1SVoxV9Fc47of55Om7cTNrky0hdp1LA13uf/TeV3nrBYa2 1zaz =IFW+ -----END PGP PUBLIC KEY BLOCK----- ====================================================================== Other Options: If you have a listed phone number and request it, I will verify your number through information and call you (collect) to verify the public key you sent me. I will add this as a notation to your electronic and paper record. No extra charge! Another possible option is to use a full color photocopy of your photo ID. This costs about $1.00 at photocopy centers such as Photo Drive-Up as opposed to 5 or 10 cents for an ordinary photocopy. I will also note this on your electronic and paper record. ====================================================================== So far I have zero (0) customers. Philip Zimmerman, in e-mail to me, endorsed the idea, but he has declined to become a customer himself even though I waived the fee for him. Plan B is to exchange/verify public keys face-to-face at parties, such as the PenSFA parties I previously posted info about. Rather than bringing diskettes, I would think printed copies of (armored form) public keys would be easy to handle. I have printed up business-card size copies of *fragments* of my public keys with the 6-hex-digit "Key ID". I think it would be very difficult to generate a valid new key pair where the public key matched the key ID and key fragment. -- edgar@spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: edgar@spectrx.Saigon.COM (Edgar W. Swank) Date: Sun, 29 Nov 92 07:56:20 PST To: Cypherpunks Subject: Remailer followup Message-ID: <7DgyuB6w165w@spectrx.saigon.com> MIME-Version: 1.0 Content-Type: text/plain No-one has replied to my request for help using the remailer at Remailing Service Am I the only person having trouble making this thing work?? Recall I had to use the "::" convention since I can't specify network headers (except subject) from this system. -- edgar@spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nathanf@cup.portal.com Date: Sat, 28 Nov 92 08:54:40 PST To: cypherpunks@toad.com Subject: unsubscribe nathanf@cup.portal.com Message-ID: <9211280725.1.15557@cup.portal.com> MIME-Version: 1.0 Content-Type: text/plain unsubscribe nathanf@cup.portal.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Sat, 28 Nov 92 06:30:11 PST To: rchilder@us.oracle.com (Richard Childers) Subject: Re: verification of posting In-Reply-To: <9211280907.AA23308@rchilder.us.oracle.com> Message-ID: <9211281429.AA17081@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > Of course, the HBD is a digest, not a mail list ... but it occurs to me, Digests also introduce a time-delay. You can have almost-realtime discussions with an immediate reflector. It is possible to have both. On many mailing lists (such as future-culture for example) you can "subscribe realtime" or "subscribe digest". > comes out once a day, it has ( usually ) a table of contents at the top, I suggest that even if we don't have a digest, we could still have a "table of contents" at the end of the day. > and, if one received email telling where in the queue one's message was, You would not need a receipt message, you would just check to see if you message appeared in the index. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Sat, 28 Nov 92 06:33:06 PST To: rchilder@us.oracle.com (Richard Childers) Subject: Re: ping..mailing list integrity.. In-Reply-To: <9211280841.AA23039@rchilder.us.oracle.com> Message-ID: <9211281432.AA17580@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > "So if you posted a message, you could check in the evening if it got > out or not. If you are not sure if you are receiving all the messages, > you could maintain a simlar file yourself, and at the end of day compare > your notes with what is received from the list." > > This could be spoofed by an intermediate delivery agent also ... Not if the evening "verification index" was signed with the list maintainer's private key. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tony@morgan.demon.co.uk (Tony Kidson) Date: Sat, 28 Nov 92 02:43:14 PST To: cypherpunks@toad.com Subject: Re: Electronic Banking Message-ID: <893@morgan.demon.co.uk> MIME-Version: 1.0 Content-Type: text/plain In message <9211280427.AA21844@rchilder.us.oracle.com> you write: > > "Using the net, the 'banker' could easily be 'offshore' and not > subject to US law in these matters." > > Feds busted some folks doing just this with modems in Puerto Rico, > I think it was, within the past year ... heard it on NPR, maybe it > was BBC or CBC ... > > > -- richard The 'Feds' writ does not run everywhere. After all, Puerto Rico _is_ a US colony. Tony ------------------+-------------------------------+--------------------------+ | Tony Kidson |`morgan' is an 8MB 486/33 Cat-| Voice +44 81 466 5127 | | Morgan Towers, |Warmer with a 670 MB Hard Disk.| E-Mail | | Morgan Road, |It resides at Morgan Towers in| tony@morgan.demon.co.uk | | Bromley, |Beautiful Down Town Bromley. | tny@cix.compulink.co.uk | | England BR1 3QE | -=<*>=- | 100024.301@compuserve.com| +=================+===============================+==========================+ From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Alan Hunter Date: Sat, 28 Nov 92 03:26:42 PST To: cypherpunks@toad.com Subject: How Far is Too Far Message-ID: <2b174c79.dunaad@dunaad.co.uk> MIME-Version: 1.0 Content-Type: text/plain Phil Karn said: I must concur with George Gleason's remarks about "sneaking around in the shadows of legality". I find myself getting a little uncomfortable with some of the more anarchistic ideas expounded in this and similar groups. [and lots of other sensible things] Just as good fences make good neighbors, we may well find that in the hands of the people, good cryptography will make for good government. That's why I find cryptography so interesting, and that's how we should sell it to the public. And as an authentication tool. There are many things that, while I would rather they were private, the authentication aspects are more important to me. Borrowing Money from the bank, any transaction. People cotton on very fast to authentication and digital signatures, they like the idea and buy into the need. Alan From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Sat, 28 Nov 92 07:44:49 PST To: extropians@gnu.ai.mit.edu Subject: FutureCulture FAQ Message-ID: <9211281544.AA19245@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain Does anyone have a copy? Nyx seems to be down for the last couple of days so I can't get it. Don't send it to me, I don't want to have 150 copies of this fairly large document pile up in my mailbox overnight, just let me know if you have it, and I will request ONE of you to send it. Thanks. Yanek, yanek@novavax.nova.edu From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Sat, 28 Nov 92 07:53:25 PST To: cypherpunks@toad.com Subject: Detailed Scenario of Dongle Usage Message-ID: <9211281553.AA19458@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain So, you walk up to ANY terminal directly connected to a host, or to a terminal server, or a personal computer of any kind connected through a modem, or borrow someone's laptop connected to a cellular modem. You connect your dongle in between the terminal/computer and the communications line, and punch in your secret code on the keypad (which, like phones, also has letters so you can remember fairly long ID-s). Call up, or telnet, dial up a bbs, or connect through any other means, to your host, and log in. Run your favorite mail reader, let's say _elm_. Start reading your mail as you usually would. Any time an encrypted message is displayed whose public key ID matches one of the private keys on your keyring, the dongle temporarily buffers the message it into its RAM, flashes the "decrypt" LED, while decrypting the message. Then you can view the plaintext using a simple, terminal-independent pager that lets you go forward/back one page, and search for a key word. When you are done, you press Q, and the plaintext is immediately deleted from the memory. Note that during all this, the plaintext did not appear anywhere on the host or any of the communication links connecting you to it. Let's say you want to reply to a message. Press 'r' or whatever key is used to reply in your particular mail reader. Or if you want to send a message, press 'm' and fill in the address. Then, if your editor is something like vi or ed that requires you to do something before you can input text (like press 'a') then do that. If you use an editor like EMACS or SMiLE or jove or cat or anything that lets you just type in text, you skip this step. Now, press the "encrypt" button on the dongle. It presents you with a simple line editor, that works with any terminal or terminal emulation, but is reasonably easy to use (something like most bbs-es use for composing messages). You type your message, or if it was prepared ahead of time on the local equipment, you transmit the text. NOTE: this is the simpler of the several different approaches to plaintext handling that I am considering. When you are done, you pick the public key to encrypt it with (or it can be automatically determined based on the address you typed in to your mail program previously). If you have lots of public keys, you could use a search to quickly find the one you want. Then you have the option of signing the message with any one of the private keys that you have. Finally, the dongle transmits the cyphertext to the host, and you type the _exit_ key sequence for the editor (:wq, or C-x C-c, or /done, etc). The message is sent by the mailer software on the host. Then you may want to scan a newsgroup like alt.w.a.s.t.e for any mail that may be for you. Put your dongle into "WASTE SCAN" mode (for example by pressing *WS on the keypad) and tell your newsreader something like "display all new messages". The dongle will detect a message whose key-id matches one of the keys on your key-ring decrypts and displays it, while ignoring all the other messages that are not for you. You must retrieve all the messages, so that anyone monitoring your activity has no way of knowing which one, if any, was actually addressed to you. Then you receive a "talk" request (or a chat call on a bbs, or you may be on irc or a MUD with "chat mode") from someone you know has a similar device (or software that emulates it). If you both know each other's public keys, the two devices both generate a random session key and encrypt it with the others' public key. If not, a key-exchange protocol may be used to generate a key both of you know, but that can not be later recovered by someone recording the data. Now the dongles encrypt any text (one line at at time) that you type, and decrypt anything received. Many other applications for a portable, trusted crypto engine could be thought of, given time. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Sat, 28 Nov 92 10:53:31 PST To: cypherpunks@toad.com Subject: bounced mail Message-ID: <9211281853.AA06156@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain We've made a small change to the way mail gets sent out to the list which should alleviate the bounced message problem. The change went into effect last night. It should take care of most, but perhaps not all, of the problems. So, take heart. Starting in a few days, please _do_ forward bounce reports to cypherpunks-request@toad.com. At that point I'll want them for further debugging. Eric with the list maintainer hat on From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: norm@xanadu.com (Norm Hardy) Date: Sat, 28 Nov 92 11:50:46 PST To: cypherpunks@toad.com Subject: John Gilmore & NSA Message-ID: <9211281912.AA12654@xanadu.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain This Saturday's NewYork Times has a nice article on page 7 regarding NSA's declassification of some of the Friedmann works under legal pressure from John Gilmore. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Sat, 28 Nov 92 12:45:07 PST To: cypherpunks@toad.com Subject: Paranoia and Cypherpunks Message-ID: <9211282040.AA02902@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain PARANOIA, THIS LIST, AND APPROPRIATE TOPICS It is inevitable that a group such as ours should have varying opinions about the nature of the group, its role in society, its approach to outsiders and journalists, and its basic attitude. Recently, several people have expressed concern that the proper message is not being conveyed, even that a subversive and seditious message is often presented on this list. Some have cited discussion of military cipher systems as being too dangerous for us to discuss, while others have expressed some discomfort at the "anarchist" flavor of some postings. Well, folks, we all have different axes to grind. Since this is an open, unmoderated list, little control of content can be expected. * Some want "cryptography" downplayed, to be replaced with "privacy" as an emphasis. Privacy is seen as more palatable to Americans, less likely to upset them into cracking down on crypto methods. In other words, privacy is an easier "sell" than secrecy. Perhaps, but why dilute our focus just to make a more digestable pill for the masses of America, who typically don't think much about abstractions anyway? Those who want to sell "privacy" are free to. (BTW, the die was mostly cast when the name "Cypherpunks" was adopted. That's already raised red flags, just by the name! If we want to downplay this "crypto-cyber-punks outlaw" image, then a name change to something more like the "Electronic Frontier Foundation" or the CPSR, nice, safe-sounding names.) * Others have expressed some concern that some minor details of how U.S. cipher machines send out padded traffic were mentioned on this list--the fear being that discussion of military matters will invite the scrutiny of the government. Well, check out sci.military some time and see the debate on such issues! Also, many details of the KG-36, KWR-37, and Autodin cipher systems--just to cite the specific military cipher machines that the posting on this list was probably referring to--have already been published, and the Walker spy ring delivered the complete specs to these and other machines in the early 1980s. It's typically only the public who lacks knowledge on these matters. The Soviets (May They Rest in Pieces) usually got the salient details fairly quickly. Since ours is a crypto education group--amongst other things--what's wrong with discussing any of the gadgets and techniques that numerous books and other postings have already dealt with? (Surely John Gilmore's lawsuit to get some critical crypto papers declassified has already "angered" the folks at NSA. Are we to censure John for stirring up trouble? Of course not. We're free individuals, able to say what we wish, meet in secret meetings without the permission of the government, and learn anything we wish to. This, at least, is the theory. Until told otherwise, I intend to act on this theory.) * Some have argued persuasively for concentrating efforts on the more palatable (to the public at large) aspects of crypto techniques, such as authentication to reduce forgeries, privacy protection against illegal eavesdroppers, and so on. This is the "selling our vision to the public" point of view. Fine, it is good for some folks to do this, to concentrate on the areas that are unlikely to upset Middle America. But some of us--and you've seen my postings--believe the _selling_ of these ideas of authentication and privacy is a lost cause, or at least is not our main interest (e.g, it's not _my_ interest). * I favor technological solutions over political solutions. Don't call it sedition, call it the natural trend of new technologies. The printing press broke the power of medieval guilds in ways a political approach could never have done. Same with steam engines, electric motors, incandescent light, copying machines, computers, modems...well, you get the point. The things we talk about on this list, the things being developed and deployed, will have revolutionary effects. I've written about these effects over the past several years, and this wonderful list is pursuing them all with gusto! The anonymous remailers alone will set off alarms throughout the law enforcement community--you're kidding yourself if you think otherwise. Are we to stop working on anonymous remailers? What about digital cash? Face it, what we're doing will have major implications. To not talk about these effects, to not speculate on the possible consequences, is to bury our heads in the sand for fear that someone reading this list will order this list shut down or have us arrested! Yes, it's true some journalists are reading this list. Yes, it's fairly likely someone is forwarding this list to various agencies (this isn't paranoia...they'd be fools to not know about this list by now, given the publicity, the reputations of some of us, etc.). I know that some of the recipients of the list are gatewaying to other systems, or are forwarding specific articles to much wider audiences (I know this partly from e-mail I get). But these are all consequences of having a public list. Anyone uncomfortable with the free discussion of ideas and technologies on this list, anyone who fears personal or professional liability for views expressed by _others_ on this list, should probably unsubscribe from the list. I certainly don't intend to stop writing about the areas that interest me. Cheers. --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pozar@kumr.lns.com (Tim Pozar) Date: Sat, 28 Nov 92 12:42:31 PST To: gnu@cygnus.com Subject: Re: John Gilmore & NSA In-Reply-To: <9211281912.AA12654@xanadu.xanadu.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Norm Hardy wrote: > This Saturday's NewYork Times has a nice article on page 7 > regarding NSA's declassification of some of the Friedmann works > under legal pressure from John Gilmore. Nice picture too! Tim -- Internet: pozar@kumr.lns.com FidoNet: Tim Pozar @ 1:125/555 UUCP: ...!uunet!kumr.lns.com!pozar Snail: Tim Pozar / KKSF / 77 Maiden Lane / San Francisco CA 94108 / USA Voice: +1 415 788 2022 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Hal <74076.1041@CompuServe.COM> Date: Sat, 28 Nov 92 10:23:07 PST Subject: Misc. Items Message-ID: <921128181712_74076.1041_DHJ61-1@CompuServe.COM> MIME-Version: 1.0 Content-Type: text/plain A few random points related to messages from the last few days. (First, a "meta" point - whenever I post to this list, I get from 3 to about 10 messages over 2 or 3 days reporting on delivery errors. It would be nicer if these went to someone else. Some of the messages include as many as 20 or 30 names of list subscribers who were apparently included in the same "outgoing batch" as the bounced mail.) On PGP key verification: I understand that Branko hopes to get version 2.1 of PGP out in a week or so. One of the new features will be a mode to display a MD5 hash of each PGP key to facilitate read-aloud over the telephone. This should make it easier to phone-verify PGP keys, so we can have more _good_ sigs. On pseudonyms and reputations: Several people have suggested that it would be easy to conjure up dozens of fake personalities who would then vouch for each other, giving the illusion of a well-founded and trusted pseudonym. This would be ideal for con men and cops. This can be defeated by the use of the is-a-person credential, which Chaum describes in a couple of his papers, including CACM Oct 1985. This is a signed document given by an organization which makes you come in and give your thumbprint. The document is "re-blinded" a la Chaums' proposals for electronic cash, so that there can be no linkage between your is-a-person document and your actual thumbprint. However, the thumbprint makes it so you can't get more than one is-a-person document. Now, when you go to apply for credit, and you say, here are signatures from dozens of people that I've done business with in the past, and I've paid them all off on time, the first thing the creditor is going to ask is, who are all these people? Are they legit? Can you at least show me is-a-person creds on them? You won't be able to. You only have one is-a-person credential, and you can't make more. Again, these credentials do _not_ hurt crypto anonymity. There is no linkage between your credential and anything else about you. On electronic banking: The interesting thing about electronic banking is digital cash. The key feature of digital cash is anonymity of payments. There is nothing subversive about this. Ordinary cash has (nearly) this property. Are you being subversive when you buy a newspaper without paying by check or credit card? Of course not. The point is, we want to use digital payments so that we can transact business over the net. But the more things get computerized, the more possible forms of monitoring there are, by businesses as well as gov- ernments. There's nothing immoral in trying to keep VISA from knowing whom I like to do business with. Digital cash is designed to allow the convenience of electronic shopping, while keeping the privacy of ordinary cash payments. Conceptually, it's a simple idea. Technically, what has to be done to turn an electronic banking proposal such as Don Bellenger's into electronic cash is some way to make it so that withdrawals can't be paired up with deposits. You also need, of course, to prevent cheating such as spending the same piece of cash twice. It's not trivial to meet these requirements. The Chaum proposal I described is the simplest one that I know of that achieves this. On remailers: I haven't yet succeeded in doing a doubly-encrypted remailer test using Bill O'Hanlon's and mine. Once this works, I'll post instructions on how to do this, and possibly a script or two to make it easier. With two encrypted anonymous remailers, you can for the first time send anonymous messages such that no one person can know whom you are sending to. Bill and I would have to collude to find out who sent a particular anonymous message. If more such remailers can start operating, such collusion will become that much more difficult. On John Draper: I just wanted to say publically that the famous "Captain Crunch" was an inspiration to me when I was in college in the 1970's. Although I did not become a "phone phreak" or "cracker" he represented to me the spirit of questioning authority and exploring beyond the accepted bounds of the system. I have followed his career to some extent over the years and I think he has more than paid for any sins he may have committed in his youth. I for one am thrilled to have the idol of my younger days on the list. Hal 74076.1041@compuserve.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tribble@xanadu.com (E. Dean Tribble) Date: Sat, 28 Nov 92 13:48:31 PST To: uunet!novavax.nova.edu!yanek@uunet.UU.NET Subject: PGP on a multiuser system In-Reply-To: <9211261554.AA26688@novavax.nova.edu> Message-ID: <9211282123.AA12941@xanadu.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain You get the picture. There is no security on a multiuser system. It is possible to get security on a multiuser system (there are at least B3 rated systems out there), you just can't currently get them with Windows or Mac interfaces :-) dean From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tribble@xanadu.com (E. Dean Tribble) Date: Sat, 28 Nov 92 14:20:26 PST To: uunet!novavax.nova.edu!yanek@uunet.UU.NET Subject: reputation In-Reply-To: <9211261521.AA26207@novavax.nova.edu> Message-ID: <9211282205.AA13176@xanadu.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain What's to stop you (once you have some "reputation") from creating 250 other pseudonyms or "identitites", giving them all a "reputation", and then create another identity, and have these 250 all give this one as much as possible, in effect creating an identity with a lot of "credibility" out of thin air? Even in the simple system I described, there's probably sufficient feedback to discourage that. If the identity you went to so much trouble to promote turns out to be a bozo, then the original identity loses credibility as a source of recommendation. Further, the positive recommendations aren't just for filtering, they're also for sorting. By spreading the credibility of the first identity out over 250 others, those 250 identities just don't carry much weight when my mailer is ordering messages for me to read. If reputation is a conserved capital, for instance, they together carry only as much weight as the first identity that recommended them. dean From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tribble@xanadu.com (E. Dean Tribble) Date: Sat, 28 Nov 92 14:48:27 PST To: uunet!informix.com!efrem@uunet.UU.NET Subject: credibility & pseudonyms With digital signatures a dozen secretaries could run a hundred or more pseudoagents, build a solid reputation for each over years. In-Reply-To: <9211270916.AA25959@godzilla.informix.com> Message-ID: <9211282227.AA13290@xanadu.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain The same approach would work for a patient con man. Real credibility has to be tied to a physical body. Some thing at risk. Real credibility has to be tied to assets. The credibility is equivalent to the amount of assets at risk. In a positive reputation system, the asset is reputation capital, it is the respect granted by others. It embodied in the settings of their sorters that order your messages before those of other people. In the farther-out world of nanotech with duplicate bodies and backups, having a body at risk is worthless because bodies would be cheap :-) If the operators of an escrow service are anonymous, then either their accessible assets had better be enough that you can recover losses if they walk with your goods, or their opportunity cost of defecting on their clients had better be high enough (in terms of lost revenue, lost opportunity on outstanding customer goodwill, name recognition, channels, etc.) that they are sufficiently unlikely to that you will take the risk. Scary prospect, and one which many people will estimate wrongly, so the simplest strategy would be to only use escrow companies with an accessible person responsible for them. dean From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tribble@xanadu.com (E. Dean Tribble) Date: Sat, 28 Nov 92 14:48:26 PST To: uunet!novavax.nova.edu!yanek@uunet.UU.NET Subject: security on a multiuser system > You get the picture. There is no security on a multiuser system. > > It is possible to get security on a multiuser system (there are at > least B3 rated systems out there), In-Reply-To: <9211282159.AA28597@novavax.nova.edu> Message-ID: <9211282230.AA13299@xanadu.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain That is fine as long as you trust all the entities that designed, built, (modified :-), programmed, installed, and administer the system. You can inspect the design, the code, the installation, and probablyu even the administration of the system. That would typically be economically infeasible, however, so to reduce your expense, you'll have to trust someone (preferably someone who stands to lose a lot if they defect). dean From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Sat, 28 Nov 92 12:00:51 PST To: cypherpunks@toad.com Subject: CFP93 information (fwd) Message-ID: <9211282000.AA25462@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain The following message was posted to Extropians by Fred Moulton. Forwarded message: > Message-Id: <9211281835.AA05819@geech.gnu.ai.mit.edu> > To: Extropians@gnu.ai.mit.edu > Date: Sat, 28 Nov 92 10:31:56 -0800 > From: moulton@netcom.com (Fred C. Moulton) > Subject: CFP93 information > > > Attached is some information on CFP93 which might be of interest to some > persons on this list. > > Fred > > > > CFP'93 > The Third Conference on Computers, Freedom and Privacy > Sponsored by ACM SIGCOMM, SIGCAS & SIGSAC > 9 - 12 March 1993 > San Francisco Airport Marriott Hotel, Burlingame, CA > > > SCOPE > > The advance of computer and telecommunications technologies holds > great promise for individuals and society. From convenience for > consumers and efficiency in commerce to improved public health and > safety and increased participation in democratic institutions, > these technologies can fundamentally transform our lives. > > At the same time these technologies pose threats to the ideals of > a free and open society. Personal privacy is increasingly at risk > from invasion by high-tech surveillance and eavesdropping. The > myriad databases containing personal information maintained in the > public and private sectors expose private life to constant scrutiny. > > Technological advances also enable new forms of illegal activity, > posing new problems for legal and law enforcement officials and > challenging the very definitions of crime and civil liberties. But > technologies used to combat these crimes can threaten the > traditional barriers between the individual and the state. > > Even such fundamental notions as speech, assembly and property are > being transformed by these technologies, throwing into question > the basic Constitutional protections that have guarded them. > Similarly, information knows no borders; as the scope of economies > becomes global and as networked communities transcend > international boundaries, ways must be found to reconcile > competing political, social and economic interests in the digital > domain. > > The Third Conference on Computers, Freedom and Privacy will > assemble experts, advocates and interested people from a broad > spectrum of disciplines and backgrounds in a balanced public forum > to address the impact of computer and telecommunications > technologies on freedom and privacy in society. Participants will > include people from the fields of computer science, law, business, > research, information, library science, health, public policy, > government, law enforcement, public advocacy and many others. > > Topics covered in previous CFP conferences include: > > Personal Information and Privacy > International Perspectives and Impacts > Law Enforcement and Civil Liberties > Ethics, Morality and Criminality > Electronic Speech, Press and Assembly > Who Logs On (Computer & Telecom Networks) > Free Speech and the Public Telephone Network > Access to Government Information > Computer-based Surveillance of Individuals > Computers in the Workplace > Who Holds the Keys? (Cryptography) > Who's in Your Genes? (Genetic Information) > Ethics and Education > Public Policy for the 21st Century > > INFORMATION > > For more information on the CFP'93 program and advance > registration, as it becomes available, write to: > > CFP'93 Information > 2210 Sixth Street > Berkeley, CA 94710 > > or send email to: cfp93@well.sf.ca.us with the word > "Information" in the subject line. > > THE ORGANIZERS > > General Chair > ------------- > Bruce R. Koball > CFP'93 > 2210 Sixth Street > Berkeley, CA 94710 > 510-845-1350 (voice) > 510-845-3946 (fax) > bkoball@well.sf.ca.us > > Steering Committee > ------------------ > John Baker Mitch Ratcliffe > Equifax MacWeek Magazine > > Mary J. Culnan David D. Redell > Georgetown University DEC Systems Research > Center > Dorothy Denning > Georgetown University Marc Rotenberg > Computer Professionals > Les Earnest for Social Responsibility > GeoGroup, Inc. > C. James Schmidt > Mike Godwin San Jose State University > Electronic Frontier Foundation > Barbara Simons > Mark Graham IBM > Pandora Systems > Lee Tien > Lance J. Hoffman Attorney > George Washington University > George Trubow > Donald G. Ingraham John Marshall Law School > Office of the District Attorney, > Alameda County, CA Willis Ware > Rand Corp. > Simona Nass > Student - Cardozo Law School Jim Warren > MicroTimes > Peter G. Neumann & Autodesk, Inc. > SRI International > > Affiliations are listed for identification only. > > > -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Sat, 28 Nov 92 13:24:30 PST To: 74076.1041@CompuServe.COM (Hal) Subject: Re: Crypto Dongle... In-Reply-To: <921128171942_74076.1041_DHJ49-2@CompuServe.COM> Message-ID: <9211282124.AA27769@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > Yanek - I do think your dongle idea is promising, but there are a > couple of other problems I haven't seen you mention. The concept is by no means complete. I will continue to add improvements as people suggest them. > One problem with this is that the terminal programs I use tend not to > just blast the whole mail message out in literal form, especially > since it is likely to be longer than one screenful. Instead, it > pauses after each screen, prompting with something like "type space > for next page", It would be transparent the other way, so that you would press space or 'n' or 'return' or anything you want. > or such. Also, it may insert VT100 control sequences as it goes from > page to page in order to clear the screen, etc. It should not be too difficult to ignore any codes that are not part of the data stream. If the message is coded with something like uuencode or base64 then the uniform-length lines of data should be clearly disinguishable from any other text such as "Press N for next screen" or an escape sequence. Also, overlapping display (some pagers show you a couple of lines from the previous screenful) could be dealt with by detecting duplicate lines. >> When you are done, you press Q, and the plaintext is immediately >> deleted from the memory. > Well, I'd think you'd want the option of saving the plaintext to a > file on your PC, not always deleting it from memory. By memory I meant the RAM in the dongle. If you wanted to save it, you could have just used to "logifile" function of your communication software. > What if you wanted to do what I'm doing here, which is to quote the > message you are replying to? I have not thought about that. Right away I see several possibilities: one, if the message you are replying to is the one you just decrypted, it could have been stored in the buffer, and you can delete the irrelevant lines, and insert your comments. The other would be that as you read a message, you could write and encrypt your reply. In that case it would also be simple to automatically use the public key that was used to verify the signature. I am sure there are other ways. There is essentially no limit on possibilities once you have a CPU. I will think about it some more. Thanks for bringing this up. >> simple line editor, that works with any terminal or terminal > I think this is OK, although I'm not sure how happy I'd be with > your line editor, not being accustomed to using BBS's. You could probably download an editor of your choice into it. There could be several editors available. Maybe even a simple screen editor that recognizes several most common terminals like vt100 and ansi. > like I can always compose on my PC, so that's OK. If your comm software supperted such a feature, the dongle could transmit a magic sequence which would make the pc to automatically go into an editor and then transmit the text. I would imagine eventually the most popular communication programs would have this feature. Some might already. The point is that if you happen to be using a dumb terminal or some machine or software WITHOUT this capability you could still receive and send secure messages. >> Then you may want to scan a newsgroup like alt.w.a.s.t.e for any mail >> message whose key-id matches one of the keys on your key-ring, >> decrypts and displays it, while ignoring all the other messages > You might have a buffering problem here. A decryption takes 30 > seconds They would not be decrypted "on-the-fly". Each Subject: line would contain the MD5 hash of the public key. It would take a fraction of a second to determine if that hash matches one of your keys for which the hash values would be precomputed and stored. Then the message would be captured. Later, when the scan is complete, it would be decrypted and displayed. > reasons; first, you don't know what flow control the host uses (if > any), and second, it would expose the fact that you had found a > message you wanted to decrypt). That is true. It should not be a problem though, if there are not too many messages for you. I plan for the device to have 256k of ram, so it could hold a few messages. The ram could be expanded if necessary. > You can't really anticipate how big the buffer might need to be, > especially if this method of anonymous communication became popular. > As I said in a previous post, you could easily have thousands of > messages to sort through, with perhaps dozens for you. I envision that this method would only be used for short and important messages, mostly of the form: "Contact me by sending mail to xyzzy@anon-r-us.com, key: dfgSDFgds34DF" So they would be short, easy to buffer, quick to decrypt and hopefully not too many of them. If there WAS too many messages, more than you were able to buffer, then it would just ignore the rest, process the ones it did get, and then you would request a second scan during which the first ones (that have already been processed) would be ignored, and the rest would be received. The problem with this is that the host would know that if you scan twice you have a lot of messages. They dont know which ones though. Or maybe you just had a transmission error... > solution than just encouraging people to buy laptops and use them? Most people that use e-mail already have a computer, They may not want to buy another one. They may use the computer or terminal on their desk for other things too, and would not want the inconvenience of having to use a separate screen/keyboard anytime they receive or want to send a private message. Laptop will cost more. Why buy a screen, keyboard, disk drive if you already have it. Hopefully my device will be cheap. It should be cheaper than any laptop. All I have is two serial ports, a cpu, some RAM and support cirquitry. I don't have a full-fledged keyboard, display, disk (or card) drive, and all the other stuff that goes in a laptop. Laptops are bigger. Or if they are small, they have lousy screens/keyboards. I hope to make my device smaller than even the so-called "palmtops". It would be easier to carry with you, in your pocket. It would be easier to hide if necessary. You can't make a laptop. You cant easily open it up, or if you can, it is complex enough that you can not completely understand its design. You can make a dongle from a kit, testing each part before you assemble it. You could make one from scratch. You can design one if you don't trust the schematics. Or you could show it to a competent electronics engineer and he could tell you if it does what it says it will. A laptop is not designed with security in mind. If you find that someone has just learned your secret code (that you used to encrypt your private key) and are going to seize your laptop in 15 seconds, you can't immediately destroy the key (you need to turn it on, boot or resume, exit from whatever program you were running or create a new window, CD to the directory where you store your private key, delete the file, run some program that makes sure the sectors are cleared.) And you still can't be sure that the key is not stored in some buffer or disk or cpu cache or a temporary file. Compare this with punching in a short "DESTRUCT" sequence on the keypad; if you have the device in your pocket, you can even do it without taking it out of your pocket, if you know the keypad well; And be absolutely sure that all information is completely gone. > Despite my negative comments here, I think there is room for plenty > of different approaches to making crypto easier to use. Absolutely. I am not saying that a hardware device designed specifically for cryptography is the ONLY way to go, what I do believe is that it is just a very good way to make easy access to cryptography widespread. A person that does not even know enough to be able to download, uncompress and install a software package could get one of these devices and make use of it. And there is no limit as to what a knowledgeable person could do with such a device. >If the dongle really could be made available at the price level you >mentioned, there might be some interest ... and if there was one for >$200 or less that would definately be interesting to me. Right now I hope to make it available for about $100. I don't know if I can yet, but will find out soon. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Sat, 28 Nov 92 14:00:11 PST To: xanadu!tribble@uunet.UU.NET (E. Dean Tribble) Subject: security on a multiuser system In-Reply-To: <9211282123.AA12941@xanadu.xanadu.com> Message-ID: <9211282159.AA28597@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > You get the picture. There is no security on a multiuser system. > > It is possible to get security on a multiuser system (there are at > least B3 rated systems out there), That is fine as long as you trust all the entities that designed, built, (modified :-), programmed, installed, and administer the system. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hollander Date: Sat, 28 Nov 92 17:59:17 PST To: "George A. Gleason" Subject: Re: Electronic Banking In-Reply-To: <199211261116.AA24529@well.sf.ca.us> Message-ID: <9211290158.AA22750@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain I think we should set up a digital money system, and just take the legal risks. I volunteer. On a related note, I noticed an article on electronic money in a recent issue of _the_Futurist_. It kept on coming back to the big advantage of cryptomoney: it is completely traceable. The main point was that cryptomoney would eliminate black marketeering (including the drug trade). The author said it would be wonderful for the federal government to run this new system, for several reasons. First, it would allow them to monitor all activity, so there could be no tax evasion or black marketeering. Second, we would all be safe knowing that the government kept the information confidential, so it couldn't be used imporoperly. This was a scary article. e From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hollander Date: Sat, 28 Nov 92 18:25:32 PST To: yanek@novavax.nova.edu (Yanek Martinson) Subject: Re: comments on Don's "Cypher Bank" In-Reply-To: <9211271825.AA25349@novavax.nova.edu> Message-ID: <9211290225.AA24130@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain >If only the hash value is mailed, then the full key can be e-mailed >or anonymously posted to a newsgroup that you montitor. If the full key >is mailed, you should invest in a scanner and some simple OCR software. I have been thinking about this. I think that pgp should have a postscript output module, so you can print your public key on the back of business cards and hand them out to people you meet. Or businesses could put it on thier flyers. Or many other uses for times when you don't want to have to have your computer there to exchange keys and you don't want to exchange disks because they're expensive and big and have lots of different incompatible formats (and some people, like me for instance, don't have any disk drives). I think the best font for this would be a font like OCRA, the font used at the bottom of checks. This font allows for very reliable scanning. Does anyone know where I can get a postscript version of this font? If someone can find it, I'll write a program that outputs a public key in that font in the right size for a business card. e From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Richard Childers Date: Sat, 28 Nov 92 20:01:51 PST To: cypherpunks@toad.com Subject: credibility and banking Message-ID: <9211290400.AA00660@rchilder.us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain "If the operators of an escrow service are anonymous, then either their accessible assets had better be enough that you can recover losses if they walk with your goods, or their opportunity cost of defecting on their clients had better be high enough (in terms of lost revenue, lost opportunity on outstanding customer goodwill, name recognition, channels, etc.) that they are sufficiently unlikely to that you will take the risk." It seems to me that there are many parallels between this state of affairs and that which prevailed in the American West of the 1800s, with respect to banking .... there were no agencies insuring deposits, and only the rep- -utation of the bank's president - usually a leader of the community - was guarantee upon the funds. Bank robberies were not uncommon, depositors were few, runs on the bank, I speculate, may not have been unknown in those cir- -cumstances where the community of bank depositors lost confidence in the bank or its officers. Another parallel which occurs to me is that of the computerized trading that occurred when programs controlled trading in, um, was it October of 1987 that the stock market shuddered ? 1989 ? ... it suggests the inevitability of software shuttling funds around at cyberspace speeds to take advantage of ebbs and flows in the economic tides of the human race, around the world ... It would be interesting to further study the origins of banking, as I expect such a study would provide many such parallels by which the case for digi- -tized banking could be made stronger ... -- richard From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Richard Childers Date: Sat, 28 Nov 92 20:08:47 PST To: cypherpunks@toad.com Subject: Re: Electronic Banking Message-ID: <9211290407.AA00714@rchilder.us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain "On a related note, I noticed an article on electronic money in a recent issue of _the_Futurist_. It kept on coming back to the big advantage of cryptomoney: it is completely traceable. The main point was that cryptomoney would eliminate black marketeering (including the drug trade)." I don't think cash will _ever_ be eliminated. If it is, someone will make their own ( banks did this for many decades in North America ) and these will fill the role. There will always be transactions which will not justify the cost of the overhead in hardware and transaction processing, and market pressures will reward those whom develop a way to avoid this overhead, IMHO. -- richard From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: mark@coombs.anu.edu.au (Mark) Date: Sat, 28 Nov 92 04:39:57 PST To: cypherpunks@toad.com Subject: Re: comments on Don's "Cypher Bank" Message-ID: <9211281239.AA00261@coombs.anu.edu.au> MIME-Version: 1.0 Content-Type: text/plain richard childers (rchilder@us.oracle.com) : >It might be more likely to arrange for a compromise where numbered accounts >are permitted iff account balances are publically available also. > >This might have interesting spinoffs, such as allowing a much wider range >of interested individuals, access to economic data at the level usually >reserved for banking institutions. We might - as many people have noted - >learn much and contribute accordingly to both economic and cryptographic >theory. It is said information should be free... however, if someone was (and someone undoubtedly would), to monitor the bank(s) they would probably see accounts going up and down by various amounts and it should be possible to track transactions between identities. This, coupled with widespread traffic analysis (assuming no padding had occured) would allow someone to deduce that Alice had asked something of Bob and had then paid him. This probably isnt particularly inviting to the majority to know that your funds could be traced very anonymously and that patterns could be formulated... for instance three times a month various amounts are deducted from your account and those exact same amounts appear in an account known to be owned by a 1-900 phone sex number. That would have an affect on your reputation, (if not your marriage if your True Name was known), if it was published. (The 1-900's identity could be discovered simply by someone using the service and noting what psuedonym took your funds, or if that was changed, noting which account increased by your $127.30. (It was an intense call I guess :) If you wish to entertain such a testbed financial system be very careful with any decision made and work through each possible consequence. Most people I think would prefer to remain anonymous. I know I would, in the long run. Mark mark@coombs.anu.edu.au From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: gnu (John Gilmore) Date: Sat, 28 Nov 92 23:40:54 PST To: cypherpunks Subject: George Gleason speaks out about cryptography: Today 2PM Berkeley. Message-ID: <9211290740.AA13833@toad.com> MIME-Version: 1.0 Content-Type: text/plain BMUG, Inc. Computer Professionals for Social Responsibility . . . . . . . Berkeley Chapter _______________________________________________________________ FOR IMMEDIATE RELEASE Contact: Judi Clark, 549-2684 (BMUG), 261-1869 (direct), fax: 261-4836 (direct), or e-mail judic@netcom.com November 27, 1992 Special Interest Group on Freedom, Privacy and Technology A public forum co-sponsored by BMUG and CPSR/Berkeley For those that need a brief break from Thanksgiving, the CPSR/BMUG Special Interest Group will explore cryptography with a brief overview and discussion lead by George Gleason. Gleason is founder of a telecommunications contracting firm in Berkeley. He is also professionally involved in psychological research on interpersonal communication and state variables (i.e. perception, cognition, etc.). Gleason's overview will be followed by a video taken from the Second Conference on Computers, Freedom and Privacy in Washington DC last March. The video is entitled: "Who Holds the Keys? Cryptography & Control: National Security vs. Personal Privacy." You are encouraged to join us on November 29, 1992 at 2:00 pm for a look into cryptography and personal privacy. The Special Interest Group's next meeting is Sunday, Nov. 29, 1992, at 2:00 pm. The monthly meetings are free and open to the public. The group meets on the last Sunday of the month at the BMUG office, 2055 Center Street, Berkeley -- a half block from the Berkeley Bart station. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Sat, 28 Nov 92 20:46:59 PST To: rchilder@us.oracle.com (Richard Childers) Subject: Governmental Economic Control In-Reply-To: <9211290407.AA00714@rchilder.us.oracle.com> Message-ID: <9211290446.AA07027@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > I don't think cash will _ever_ be eliminated. > There will always be transactions which will not justify the cost of the > overhead in hardware and transaction processing, and market pressures will > reward those whom develop a way to avoid this overhead, IMHO. You can not depend on this. The government may subsidize the transactions, reducing or elimintating the overhead. For example it may issue "free" (paid for by money extorted from you) Personal Identitiy Cards, and install "public" Funds Transfer Terminals in most public locations. It may pass laws requiring every business to accept it (just write "This Card is a Legal Tender..." on the card). Then the only incentive for bypassing the system would be desire for privacy, which, for the average American, is much weaker than the economic incentive. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: gnu (John Gilmore) Date: Sat, 28 Nov 92 23:56:27 PST To: yanek@novavax.nova.edu (Yanek Martinson) Subject: Re: Detailed Scenario of Dongle Usage In-Reply-To: <9211281553.AA19458@novavax.nova.edu> Message-ID: <9211290756.AA14123@toad.com> MIME-Version: 1.0 Content-Type: text/plain Yanek's scenario might have been great for 1980, but in 1993, if your electronic mail doesn't come right down into the computer in front of you, that you trust, I want to know why not. It works this way for millions of Internet users, AppleLink users, and users of "offline edit" programs for MCI Mail, ATT Mail, compuserve, AOL, Prodigy, etc. It's cheaper to buy computers these days than terminals! Seriously! John Gilmore PS: Don't tell the list -- we've had more than enough traffic recently. Tell *me* (gnu@toad.com) why you use your computer like a terminal instead of like a computer. I'll be gone for a week, so lack of speedy replies doesn't mean I'm not listening. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Sun, 29 Nov 92 00:52:05 PST To: hh@soda.berkeley.edu Subject: Re: Electronic Banking Message-ID: <199211290850.AA03386@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain "...and just take the legal risks..." Wellll, what is there to gain by taking legal risks, as opposed to doing a research gig where we're trading in pennies for fictitious goods & services...? Please spell it out explicitly; there would have to be a very significant advantage to convince me to agree. Like maybe that the govt is about to pull all cash out of circulation and this is our last hope.... -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Sun, 29 Nov 92 01:01:10 PST To: cypherpunks@toad.com Subject: "gleason speaks at CPSR..." Message-ID: <199211290859.AA04170@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Just a quick note of reassurance here. Someone at BMUG saw something I posted about crypto and education and values, and suggested I give a short talk on that to get discussion going. I will definitely Not 1) be a "spokesperson" for anything or anyone other than my own views, and 2) say anything likely to arouse premature publicity regarding things going on in the group or on the list. So in other words I intend to play it way careful, low-key, stick to social issues, and make it clear that there are many people far more qualified than I to discuss technical aspects in detail, and make it clear that there is wide debate and difference of opinion on the subjects of discussion. Now also, apologies for not contacting other folks on the list here when this was just getting set up. Actually it surprised the heck out of me to find out how fast the date came up; I was expecting at least another week. Properly, there are at least ten or twenty people on our list who could be addressing other groups on these issues. Any feedback, email back to me quick, because it's about 12 hours from now...! -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Karl L. Barrus Date: Sun, 29 Nov 92 07:38:56 PST To: cypherpunks@toad.com Subject: crypto banking Message-ID: <9211291538.AA23755@tree.egr.uh.edu> MIME-Version: 1.0 Content-Type: text/plain I'd like to see a digital bank go up as well - just to be able to work through the protocol, at first. I took a cryptography course last summer at the university, and learned a lot (and had some fun!) working through various protocols: coin flipping, poker, subliminal channels, number comparison without giving away the numbers involved, signatures, etc., and more recently since joining this group: dc-nets. It doesn't have to be fancy: this list or maybe just email between various participants at first, maybe then a fancier system with transactions posted or made public for study, then a more advanced system with telnet or mail to the digital bank and transactions kept private. We could make everybody's account balance public and then study ways to avoid traffic analysis on account fluctuations (maybe the only way to do this is to keep balances secret) - maybe everyone can have more than one account and pay off transactions with a little bit from each account (this would be inconvenient though...) Anyway, I'm just rambling on... :-) /-----------------------------------\ | Karl L. Barrus | | barrus@tree.egr.uh.edu (NeXTMail) | | elee9sf@menudo.uh.edu | \-----------------------------------/ From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: phr@napa.Telebit.COM (Paul Rubin) Date: Sun, 29 Nov 92 11:13:33 PST To: gg@well.sf.ca.us Subject: Electronic Banking In-Reply-To: <199211290850.AA03386@well.sf.ca.us> Message-ID: <9211291912.AA07318@napa.TELEBIT.COM> MIME-Version: 1.0 Content-Type: text/plain "...and just take the legal risks..." Wellll, what is there to gain by taking legal risks, as opposed to doing a research gig where we're trading in pennies for fictitious goods & services...? Please spell it out explicitly; there would have to be a very significant advantage to convince me to agree. Like maybe that the govt is about to pull all cash out of circulation and this is our last hope.... How about a crypto poker game, or crypto diplomacy (with fictitious money)? This would allow us to try some coin flip protocols, zero knowledge proofs etc. as well as crypto banking. Of course, cheating (trying to rig the coin tosses, spoof messages etc.) would be encouraged! That would allow us to find weak spots in the protocols, which are supposed to prevent this from happening. Then, at the next physical meeting, people could describe what kinds of things they did, and maybe the winner could get a small prize (e.g. be treated to dinner by the rest of the players). From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Sun, 29 Nov 92 10:38:53 PST To: cypherpunks@toad.com Subject: comments on Don's "Cypher Bank" In-Reply-To: <9211290225.AA24130@soda.berkeley.edu> Message-ID: <9211291813.AA23423@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >>If only the hash value is mailed, then the full key can be e-mailed >>or anonymously posted to a newsgroup that you montitor. If the full key >>is mailed, you should invest in a scanner and some simple OCR software. >I have been thinking about this. I think that pgp should have a postscript >output module, so you can print your public key on the back of business >cards and hand them out to people you meet. Is anything preventing you from building seperate tools to do this? PGP will happily put out your key into a file, from whence you can do anything you like. Why add bloody postscript generation capability to an encryption program, fercrissake. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Sun, 29 Nov 92 11:07:39 PST To: gg@well.sf.ca.us Subject: the list In-Reply-To: <199211290859.AA04170@well.sf.ca.us> Message-ID: <9211291832.AA23438@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: George A. Gleason >Just a quick note of reassurance here. Someone at BMUG saw something I >posted about crypto and education and values, and suggested I give a short >talk on that to get discussion going. I will definitely Not 1) be a >"spokesperson" for anything or anyone other than my own views, and 2) say >anything likely to arouse premature publicity regarding things going on in >the group or on the list. "Premature" publicity? This list isn't exactly a private club -- I bet the government folks know exactly what it is we are discussing and in great detail. Posting something to a list like this means it isn't a secret any longer. Not that we are much of a threat -- the average subscriber here seems to have far more opinions than knowledge. If you have something you want to see done, just go out and do it. Don't form a committee to discuss the matter. Things that get discussed on this list immediately enter my list of things I'm unlikely to see anyone else build any time soon. Sorry for lashing out, but the drivel is getting thick enough to cut with a chainsaw. Repeating, if you want to do something, just go out and do it, don't talk. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: karn@qualcomm.com (Phil Karn) Date: Sun, 29 Nov 92 14:04:10 PST To: edgar@spectrx.Saigon.COM Subject: Re: Secure key exchange Message-ID: <9211292203.AA17336@servo> MIME-Version: 1.0 Content-Type: text/plain How byzantine! PGP 2.1 will have a much more convenient facility for verifying public keys that you receive over the network. If you say "pgp -kvc karn", for example, it will display the MD-5 hash of karn's public key as 16 hex bytes. If you know the sound of my voice, you can call me on the phone and have me read off the hash code that I compute here on my key so you can compare it to the value you computed. If they match, you can sign my key with reasonable confidence. About the only way to defeat this system is for the bad guy who feeds you the bogus key in my name to come to my house and hold a gun to my head as I receive your phone call. I would much rather trust a simple verification procedure based on redundancy and close personal relationships than a single, complex, impersonal process involving people I don't know. This is not to impugn your integrity, of course -- I'm simply speaking on principle. People need to be very selective about the signatures they sign, otherwise they will become meaningless. I've already had people sign my public key without any verification that it is legit. This is a no-no. I am bothered by the message that PGP currently generates when it reads in some new public keys asking if you'd like to certify each new key. Even though the default is "no", it makes it too easy to sign a key without really verifying its authenticity. Phil From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Marc Horowitz Date: Sun, 29 Nov 92 13:27:17 PST To: cypherpunks@toad.com Subject: crypto dongle design problems Message-ID: <9211292126.AA22394@deathtongue.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain A few comments on "Detailed Scenario of Dongle Usage": >> So, you walk up to ANY terminal directly connected to a host, or to a >> terminal server, or a personal computer of any kind connected through a >> modem, or borrow someone's laptop connected to a cellular modem. As several people have pointed out, terminals are passe'. In general, my mail never goes over a serial line. Here at MIT, most people have unix machines on their desks. Mail is composed on the unix machine, sent via ethernet to the mail hub, and received via POP or NFS from the mailhub. To make life worse, often, the machines are in public clusters where anyone can log in. And, (sit down here), the root password for these public machines is well known. (The servers' root passwords are a closely guarded secret.) So, for me, the crypto-dongle is almost completely useless. >> Call up, or telnet, dial up a bbs, or connect through any other means, >> to your host, and log in. Except IP. One of my machine at work runs SLIP over its serial port. What am I supposed to do now? >> Any time an encrypted message is displayed whose public key ID matches >> one of the private keys on your keyring, the dongle temporarily buffers >> the message it into its RAM, flashes the "decrypt" LED, while >> decrypting the message. Someone else mentioned this, but I didn't understand your response. I read mail in emacs, a full-screen editor. it displays the first screenfull, and I hit space to scroll down. Does the dongle recognize emacs and hit space, or what? >> Now, press the "encrypt" button on the dongle. It presents you with a >> simple line editor, that works with any terminal or terminal emulation, >> but is reasonably easy to use (something like most bbs-es use for >> composing messages). You type your message, or if it was prepared >> ahead of time on the local equipment, you transmit the text. So, I'm trusting the local equipment with my private message. Even if I'm only "typing directly to the serial port", how do I know if my friend's borrowed laptop has been (maybe unknowingly) modified to store the data? Similar problems arise with all the other sample applications you describe. More personal comments: I've had several years of experience designing large-scale systems incorporating security features. One of the most valuable lessons learned is that security and privacy must be designed into a system from the beginning, not added later. Ease of use comes from design, not hacks, which inevitably fail. My view of a useful crypto-dongle is more like Phil's. A device with one serial port, which stores my private keyring. It has functions to list the keys it has (names and hashes, not keys), to decrypt a message (while displaying some external indication of having done so), and to sign a message (again, with display). Programs would have to be modified to use the dongle to do the appropriate very sensitive crypto stuff, and I can do the DES or other work on my desktop machine. I forsee the dongle being made of a well-known CPU or MCU (easily verifiable), an EPROM (software), a static RAM (long-term, encrypted storage of keys), a DRAM (short-term cleartext storage and buffering), a UART, an input keypad of some sort, a small (say 1x20 LCD display for simple output, and perhaps a special chip for the math. Sources to the EPROM would be available, of course. Paranoid people could burn their own chip (assuming they trusted the programmer :-). Yeah, this isn't much use on a dumb terminal, but dumb terminals aren't of much use nowadays, anyway. Marc From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: mcmahonm@wybbs.mi.org (Mike McMahon) Date: Sun, 29 Nov 92 14:51:00 PST To: cypherpunks@toad.com Subject: UNSUBSCRIBE Message-ID: <9211291635.AA01230@wybbs.mi.org> MIME-Version: 1.0 Content-Type: text/plain unsubcribe mcmahonm@wybbs.mi.org From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Marc Horowitz Date: Sun, 29 Nov 92 13:43:41 PST To: cypherpunks@toad.com Subject: No Subject Message-ID: <9211292143.AA22427@deathtongue.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain >> This entire business may be pretty simple. If we have anonymity >> both ways, (where one or neither party knows the others physical >> location), then who cares about the content of the message? >> >> You might as well send it in plain text, Except you need RSA >> just for the signitures so you know you aren't being spoofed. Very good reasons. "Here is my plan to kill President Foo: ...." Just because you and your hired gun are anonymous, you don't want anyone, especially the government, to read your message. It could throw a wrench into your plans. Marc From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Marc Horowitz Date: Sun, 29 Nov 92 14:08:03 PST To: cypherpunks@toad.com Subject: thoughts on digital cash Message-ID: <9211292207.AA22455@deathtongue.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain I've thought a bit about digital cash since the thread started here, and I have a bunch of thoughts. I hope I'll be coherent. ** For production use, you want a real, live bank or other entity to issue the "money". Assuming the digital cash is backed by gold, or securities, or something else tangible, you don't want the bank to go away with all your money. Or, if you read in the newspaper "Feds seize First National Bank", you want to know if they've just seized *your* bank, and therefore will be able to watch your deposits and withdrawals. If you don't know who your bank really is, you won't know. ** All of the above applies to your escrow agent (who may be your bank) for similar reasons. Public key systems provide non-repudiability, but knowing provably that a pseudonym just stole money or goods from you doesn't help you get it back. Sure, it tarnishes their reputation, but if they steal a whole lot of money all at once, they won't care. ** Anonymity in banking is a well-known concept. If I transfer money from my numbered swiss bank account to your numbered swiss bank account, nobody knows anything, except who the bank is. And I don't see Switzerland giving up their enviable position in the international banking community willingly. All we need to do is convince a swiss bank to do some digital cash banking. Easier said than done. ** Legality of starting our own anonymous electronic bank: what do the laws say, anyway? As long as I pay taxes on any profit, I can form a sole proprietorship to freely buy and sell purple widgets with very little government interaction. Would it still be legal if I got a whole lot of people to accept purple widgets instead of cash? Would it be legal if we called it "digital purple widgets" instead of "digital cash"? I'd really like to see some sort of digital cash system set up. My feeling is that there would be a stronger demand than most people think for such a thing, even if it weren't anonymous and untraceable and all that. But if it has those features, too, and we do it first, it will get used. And de facto standards are hard to get rid of. Marc From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: S950272@slvaxa.umsl.edu Date: Sun, 29 Nov 92 15:19:41 PST To: cypherpunks@toad.com Subject: Please... Message-ID: <01GRQCRO6QHG8WW8IZ@slvaxa.umsl.edu> MIME-Version: 1.0 Content-Type: text/plain Please delete me from the mailing list, the mail volume is too great for me. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Marc Horowitz Date: Sun, 29 Nov 92 15:25:14 PST To: cypherpunks@toad.com Subject: unsubscribe messages Message-ID: <9211292324.AA22516@deathtongue.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain If you don't want to be on this list, that's fine. BUT PLEASE STOP CLUTTERING MY INBOX WITH THE UNSUBSCRIBE REQUESTS!!! I AND MOST OF THE OTHER RECIPIENTS OF THIS LIST CANNOT DO ANYTHING ABOUT IT!! There is a convention on the Internet that if there is a list called foo@bar.domain, the maintainers of this list will be on a much smaller list called foo-request@bar.domain. Send requests there to get added or removed, not to the whole list. If you get a bounce, then, and ONLY THEN, should you send to the whole list. So, if you want to get off the list, send mail to cypherpunks-request@toad.com. It's not hard. And it will keep large numbers of people from wanting to kill you. Flame off. Marc From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: cmr!cmrp!berry_k@mailer.cc.fsu.edu (Kevin Berry) Date: Sun, 29 Nov 92 15:53:56 PST To: cypherpunks@toad.com Subject: UNSUBSCRIBE Message-ID: <9211292336.AA19892@cmrp.cmr.uucp> MIME-Version: 1.0 Content-Type: text/plain unsubscribe berry_k@cmr.fsu.edu From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Bill O'Hanlon Date: Sun, 29 Nov 92 20:24:59 PST To: cypherpunks@toad.com Subject: Some hacked scripts for the remailers Message-ID: MIME-Version: 1.0 Content-Type: text/plain Here's a couple of real rough Bourne shell scripts to get some mail to go to both Hal's and my remailers. Not too helpful if you don't have a unix machine around--sorry. Nothing fancy, but it'll keep the mental confusion down when trying to put a message together. First is twohop... ------ Cut here ------ #!/bin/sh # Two hop anonymous remailer hal's first, then rebma ... if [ $# != 2 ] then echo Usage: twohop message-file-name destination-address exit 1 fi message=$1 dest=$2 t1=twohop.1 t2=twohop.2 # if the "remailing" and "remailer" names look odd--well, that's what hal's # and my respective keys for the remailers are named... encap $message $dest remailer $t1 encap $t1 remailer@rebma.mn.org remailing $t2 elm hal@alumni.caltech.edu < $t2 rm -f $t1 $t2 ----- Cut here ----- twohop calls encap twice. Encap is a more general and useful script. ------ Cut here ------ #!/bin/sh # # usage: encap message-file destination remailer resultfile # if [ $# != 4 ] then echo Usage: encap message-file-name destination remailer-key-name outputfile exit 1 fi mfile=$1 dest=$2 remailer=$3 result=$4 t1=encap.1 t2=encap.2 echo :: > $t1 echo Request-Remailing-To: $dest >> $t1 echo "" >> $t1 cat $mfile >> $t1 pgp -ea $t1 $remailer echo :: > $t2 echo Encrypted: PGP >> $t2 echo "" >> $t2 cat $t1.asc >> $t2 mv $t2 $result rm -f $t1 ---- Cut here ----- These seem to work for me... At least, a couple messages now have gotten back to me from them. They helped me get a couple problems out of the remailer. -Bill -- Bill O'Hanlon wmo@rebma.mn.org From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Mon, 30 Nov 92 00:33:34 PST To: edgar@spectrx.Saigon.COM Subject: Re: Secure key exchange Message-ID: <199211300832.AA16031@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Edgar- Two possible points of critique in an otherwise good idea. 1) HOME Address?! As I've said before, that's arguably your most secure datum since it's where you keep your soft, squishy body, and where the baddies and black-baggers and so on would just looove to know where to find you. Let's not make it any easier for them. 2) "I certify that I'm not a cop or spy." That doesn't and hasn't ever held up in any court in the land. Plenty of precedent in drug case law. "I want to buy some pot." "Okay, first tell me under oath that you're not a nark." Result: nark laughs all the way to the police station, with fresh catch in handcuffs. We can't keep them out, and at some future time might want to open up a dialog with the LE community on various issues. No point looking like a conspiracy if we aren't one. -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: strat@intercon.com (Bob Stratton) Date: Mon, 30 Nov 92 01:30:00 PST To: cypherpunks@toad.com Subject: Secure key exchange In-Reply-To: <9211292203.AA17336@servo> Message-ID: <9211300930.AA00855@intercon.com> MIME-Version: 1.0 Content-Type: text/plain >>>>> On Sun, 29 Nov 92 14:03:25 -0800, karn@qualcomm.com (Phil Karn) said: Phil> People need to be very selective about the signatures Phil> they sign, otherwise they will become meaningless. I've Phil> already had people sign my public key without any Phil> verification that it is legit. This is a no-no. I am Phil> bothered by the message that PGP currently generates Phil> when it reads in some new public keys asking if you'd Phil> like to certify each new key. Even though the default is Phil> "no", it makes it too easy to sign a key without really Phil> verifying its authenticity. I have to echo Phil's comments here. One of the things that might be worth a few minutes is for this group to hash out (pun intended) a set of guidelines for "when it's o.k. to sign a key". I have been talking to some people about personal applications of cryptographic technology, and I'm frequently surprised when even people with a DP security background want to rush to certify keys they've received via email, etc. I'm thinking something along the lines of "If I'm in a real-time communications mechanism, and on the phone at the same time, and I receive their key at the moment when they told me they hit the return key - then it's probably theirs"...It would be prohibitive to list all of the possible permutations, but it might go a long way toward building the right habits if we brainstormed about a few firm guidelines for the uninitiated as to what constitutes responsible key management. I confess to some personal bias, because I know the PEM folks are watching to see how robust our key distribution "web" becomes over the course of its evolution, and I'd like to be able to show them a convincing argument against centralized key management, empirically... --Strat From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Mon, 30 Nov 92 08:18:40 PST To: cypherpunks@toad.com Subject: Electronic Banking In-Reply-To: <9211251953.AA01487@nano.noname> Message-ID: <9211301618.AA14930@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain [Hal Finney describes Chaum's blind signature scheme.] >The "social" problems are more challenging, it seems to me. One such social problem that Hal does not mention is that the blind signature is a patented algorithm. You'd have to get a signature from Chaum. Since any such company which wanted to deploy with blind signatures whould be competing with Chaum's own company, DigiCash, there might be a problem here. >One possibility is to base digital cash on real money. >Unfortunately, this approach would currently be illegal (at least, >unless you actually were a real bank!). If you wanted to do this as a business, you can start a bank with (roughly) a million dollars in capital or you can buy an existing one with at minimum (roughly) fifty thousand. These minimum investments are for bank regulation purposes, not operating costs. So, if you really want to _be_ a bank, it's not that hard. Your greatest startup expense will most likely be attorney's fees for a specialist in bank regulation law. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pfarrell@cs.gmu.edu (Pat Farrell) Date: Mon, 30 Nov 92 05:33:16 PST To: cypherpunks@toad.com Subject: Re: Secure Key exchange Message-ID: <9211301332.AA10244@cs.gmu.edu> MIME-Version: 1.0 Content-Type: text/plain Bob Stratton suggests we hash out ideas on key signing prorocols. Ok, here is what I do: I sign keys only when I am certian that the key belongs to the human who claims to have the name on the key. There are not a lot of keys signed by me floating arround, maybe six total. My sig does not mean that the key is not owned by a cop or NSA/CIA/KGB agent (Unlike Edgar's service) because I can't tell. So if you care about that stuff, start your own web of trust with "higher" standards. My sign doesn't mean that the person is really who they claim to be, I can't tell that either. I've signed the key of a guy claiming to be "Ray Kaplan" because I believe that he uses that name reegularly. But I don't know that his name isn't really Boris Badinov. You won't find my sig on Phil Zimmermann's key, even tho that is a popular activity. Phil is a Net/Ether person to me. My sig means that there is a real person with that name. I was at NCSC and exchanged keys there. I'll be at CFP-3 and exchange keys there too. And if you are in my area, (suburban Wash DC) we can meet and exchange keys. I see no reason to hurry. A slowly growing web of trust that is strong is far more useful than an exploding web of trash. Pat Pat Farrell, Grad Student pfarrell@cs.gmu.edu Department of Computer Science, George Mason University, Fairfax, VA PGP key available via finger or request #include standard.disclaimer Write PKP. Offer money for a personal use license for RSA. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Mon, 30 Nov 92 06:10:54 PST To: marc@mit.edu Subject: thoughts on digital cash In-Reply-To: <9211292207.AA22455@deathtongue.MIT.EDU> Message-ID: <9211301400.AA05557@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: Marc Horowitz >** Anonymity in banking is a well-known concept. If I transfer money >from my numbered swiss bank account to your numbered swiss bank >account, nobody knows anything, except who the bank is. Such accounts do not exist in Switzerland -- there is no such thing as a Swiss account for which the bank does not possess information on who the account holder is. Such things may have existed at one point -- but emphatically do not exist today. There are a few such things in existance in odd corners of the world -- but they aren't well publicized. >** Legality of starting our own anonymous electronic bank: what do the >laws say, anyway? As long as I pay taxes on any profit, I can form a >sole proprietorship to freely buy and sell purple widgets with very >little government interaction. Would it still be legal if I got a >whole lot of people to accept purple widgets instead of cash? Would >it be legal if we called it "digital purple widgets" instead of >"digital cash"? The law is a slippery thing -- however, anonymous bank accounts, no matter what you call them, are almost certainly illegal in the United States. Most computer people don't seem to understand that the law is interpreted not by a computer but by humans -- and they won't care what "hacks" you use. If it smells like a bank, they will likely convict you if it comes to that point. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: John W Noerenberg Date: Mon, 30 Nov 92 09:07:42 PST To: tony@morgan.demon.co.uk Subject: Re: The Cypherpunks Mail Project Message-ID: <9211301706.AA27590@harvey> MIME-Version: 1.0 Content-Type: text/plain At 8:07 PM 11/25/92 +0000, Tony Kidson wrote: > >I'd like to chip in here, in my _very_ newbie way, that not >everybody is running a unix system with the ability to pipe >things between processes in so facile a manner. Good point. My vision for the Mac is to have a PGP service with an AppleEvent suite defined so that any other AE-aware program can use the services. This isn't trivial, but it is the right thing to do, imho :-). john noerenberg jwn2@qualcomm.com noerenberg.j (Applelink) =========================================================== Do not uselessly lament your luck that is giving way, your work that has failed, your life's plans that have all ended in despair. Like a man long prepared, like a man of courage, bid her farewell, the Alexandria that leaves you. -- "The God Abandons Anthony", Constantine Peter Cavafy [1911] =========================================================== From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: mark@coombs.anu.edu.au (Mark) Date: Sun, 29 Nov 92 14:20:56 PST To: cypherpunks@toad.com Subject: Secure PK swapping.. what are the methods? Message-ID: <9211292219.AA28149@coombs.anu.edu.au> MIME-Version: 1.0 Content-Type: text/plain Since Im not sure this got through to the list last time I'll resend. Certainly I havent had any pointers to where to find the information I need.... ------------------------------------------------------------------------ Below is a letter Ive sent to a person designing a communications system similar to IRC but designed with the ability to be anonymous and as secure as possible. Further details will be announced soon when it's stable. --------------------Begin letter----------Begin letter------------------- Before you get too involved with the client in the comm system I was thinking of a way of having secure privmsgs, two forms depending on how open one chose to be: Messages are exchanged via UDP to hide from the netstat junkies... When someone does a msg the first time and the client doesnt know about that user it queries the server to either get a hostname/port pair for that user and/or a public key. The data is then stored in an internal attribute bank. Format of a private message: ._________________________________________________________. | Nickname Plaintext | dest IP | dest udp port | | =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= | | =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= | | =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= | `---------------------------------------------------------' [Return host/port/public key are encrypted into the PGP? message] The above message is then sent to the delivery module of the client. The above host and port are either the recipeints or the server's depending on what type of message is being sent. Thus the same message can go to the server or the recipient direct per se: 1) Using the hostname/port + public key for that user the sender's client encrypts the message and udp transmits a message to that port on the other users host. That remote client has set up a socket to listen on that udp port for messages. The remote client unpacks the message with it's private key and extracts the message, a reply host and port and the senders public key. He can then reply to the sender and they both can talk without loading down the server. Plus, unless someone is logging the ethernet, no one can ascetain wether they are talking. There is only the initial request of the users public key from the server which each client sends in automatically when it connects. You might also have an option in the client to auto download a block/all of the users nicks and their keys so no-one can detect the initial query of a user. 2) The other, differently secure :), form is because the server has been told to hide the users username + hostname from the /who information. All there exists for that person is a nickname and a public key. The senders client gets individually/block downloads the key he wants and proceeds to udp a message to the server which has the udp port and hostname of the recipient as normal from the client connect. It acts as IRC does now, as a middle man for messages. Less secure because the server admin can ascetain that there is a message being sent between the two people and also he can slip in his *OWN* keys to basically grab and decipher messages between the two parties. i.e he sends his own key to the sender and decrypts the incoming message and then sends the message out to the recipient using their encryption key. neither user could tell there was a switch in between. (There are schemes to get past this however). Both ways have their flaws because you are relying on the non-hackedness of the server to give you the right keys and hostnames and ports. A bad admin could easily, knowing enough about coding, disrupt the entire process if we didnt from the start ensure the right protocols were used. It has to be done right the first time or not at all. I'll echo this letter to a cryptography mailing list to ask for details of schemes that will allow each user to know they have a valid, secure public key of the other. One possible solution would be to do a mass query of all the online servers at once and if they didnt report the same keys sound a Real Big Alarm (tm). Maybe an automatom could sit there randomly checking keys :) (Can hear the cries of "No Bots.. No Bots" now :). (Note this allows *someone* to know your doing a query for a user... that may or may not bother the sender/recipient. Doing a block transfer from all the servers at once isnt net.nice) Comments? ------------------End of Letter----------------End of Letter---------------- Now what Im curious about is any other methods of secure key exchange where the exchange mid point may be lying about the keys, the hosts and the ports. Assume each person knows the others 'style' etc. How does one get the real keys to each other with an unreliable "medium"? (It might slip in it's PK). Assume that they havent previously organised a key exchange. Replies to me or the list.. (but not both please.. my mbox is busy enuff :) Mark mark@coombs.anu.edu.au From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tribble@xanadu.com (E. Dean Tribble) Date: Mon, 30 Nov 92 10:03:02 PST To: uunet!intercon.com!strat@uunet.UU.NET Subject: Secure key exchange I have to echo Phil's comments here. One of the things that might be worth a few minutes is for this group to hash out (pun intended) a set of guidelines for "when it's o.k. to sign a key". I have been In-Reply-To: <9211300930.AA00855@intercon.com> Message-ID: <9211301720.AA19058@xanadu.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain An excellent suggestion. Can you start writing such a thing? (This is not a facetious request). I imagine there will be two or three strategies for approving a key, and if we write them up well, we will be able to ask people which protocol they have engaged in: 1) Only people I know personally and whose keys I receive in person. 2... n) Any key received throuhg any medium. This could have lots of educational value. dean From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Mon, 30 Nov 92 09:22:03 PST To: cypherpunks@toad.com Subject: Secure key exchange In-Reply-To: Message-ID: <9211301721.AA17060@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain >There is no secure method of exchanging public keys using only the >net. [spoofing, etc.] As mentioned by Hal, the new PGP 2.1 (imminent) has a feature to create an hash or a public key which can be read over the telephone to make sure that a key transmitted electronically has not been altered in transmission. >[long business description deleted] There's really no need for a physical authentication service with the telephone verfication ability. >Plan B is to exchange/verify public keys face-to-face at parties, There is just such a plan underway to have a PGP key exchange table at Usenix in January. >I have printed up business-card >size copies of *fragments* of my public keys with the 6-hex-digit >"Key ID". What could easily be printed is the hash function of the key. That would be even harder to duplicate. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Mon, 30 Nov 92 09:37:45 PST To: cypherpunks@toad.com Subject: Secure Key exchange In-Reply-To: <9211301332.AA10244@cs.gmu.edu> Message-ID: <9211301737.AA17617@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Pat Farrell write: >A slowly growing web of trust that >is strong is far more useful than an exploding web of trash. I urge everybody to go out and quote this! It's a great aphorism. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Mon, 30 Nov 92 09:43:34 PST To: cypherpunks@toad.com Subject: thoughts on digital cash In-Reply-To: <9211301400.AA05557@newsu.shearson.com> Message-ID: <9211301743.AA17881@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain >>** Legality of starting our own anonymous electronic bank: what do the >>laws say, anyway? Perry write: >The law is a slippery thing -- however, anonymous bank accounts, no >matter what you call them, are almost certainly illegal in the United >States. OK, Perry, time to quote sources. Exactly what laws _do_ prohibit such bank accounts? >Most computer people don't seem to understand that the law is >interpreted not by a computer but by humans -- and they won't care >what "hacks" you use. If it smells like a bank, they will >likely convict you if it comes to that point. Most political dissidents don't seem to understand that the law is interpreted accurately, for the most part. There exist clear statutory definitions on what a bank is. If you don't meet those criteria, you're not a bank. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: lasterm@ohm.ee.utulsa.edu (Mike Laster (664-5510)) Date: Mon, 30 Nov 92 08:13:16 PST To: ncselxsi!drzaphod@ncselxsi.netcom.com Subject: RE: PGP on local machine (was Re: MacPGP) Message-ID: <9211301610.AA05451@ohm.ee.utulsa.edu> MIME-Version: 1.0 Content-Type: text/plain folders a From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: ghsvax!hal@uunet.UU.NET (Hal Finney) Date: Mon, 30 Nov 92 11:19:02 PST To: cypherpunks@toad.com Subject: Re: Electronic Banking Message-ID: <9211301830.AA23870@nano.noname> MIME-Version: 1.0 Content-Type: text/plain Eric Hughes points out that the blind signatures used to provide anonymity in Chaum's digital cash schemes are patented (by Chaum himself). This is a problem for an official, legal, profit-making business which wants to engage in electronic banking. However, such a business would face many other problems. Chaum's digital cash system could be construed as using the RSA algorithms, since it is in effect an RSA signature which makes the cash unforgeable. So a license for RSA would have to be obtained as well. (RSA licensing would also be needed for secure communication between the bank and its customers.) In addition, the acceptable use policies of NSFNET, which would probably have to be involved in most communications with the bank, are inconsistent with this kind of commercial activity, from what I understand. I believe new policies are in the works to allow commercial activities on the net, but these again will involve licensing costs. There is also the question of the legality of private cash in any form, electronic or otherwise. Nobody seems to have hard evidence on this. On the one hand, people can legally exchange certain types of securities, and they could perform services for each other in return for such exchanges. This is legal, but they are supposed to report the income on their tax returns. Our digital cash would seem to fit this model. (But are such securities transfers as untraceable as digital cash? Perhaps not.) On the other hand, I read several years ago that casino chips in Las Vegas were starting to be used as cash substitutes, but that the government cracked down on this practice. Perhaps this was too conducive to money laundering, especially with the reputed underworld activity in that city. I do think, though, that an informal digital cash system, presented as a research project or an educational game, would be able to slip between the cracks of the legal system, much as PGP has done. And I think this presentation would be legitimate. Digital cash is new (actually, nonexistant, as far as I know), and any use of it would by its very nature be research and be educational. I would suggest that anyone who proposes to implement such a game might want to consider releasing it anonymously (actually, pseudonymously). Sign the release with a PGP or RIPEM key, and let that be your pseudonym. Let people post messages to alt.security.pgp or some other newsgroup to discuss it, so that you can read them without revealing yourself, as proposed by Yanek. Post your replies anonymously using our remailers. This way there won't be a single-point target for anyone wishing to punish users of the game. Hal 74076.1041@compuserve.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tribble@xanadu.com (E. Dean Tribble) Date: Mon, 30 Nov 92 11:15:21 PST To: uunet!us.oracle.com!rchilder@uunet.UU.NET Subject: credibility and banking It seems to me that there are many parallels between this state of affairs and that which prevailed in the American West of the 1800s, with respect to banking .... there were no agencies insuring deposits, and only the rep- -utation of the bank's president - usually a leader of the community - was guarantee upon the funds. Bank robberies were not uncommon, depositors were In-Reply-To: <9211290400.AA00660@rchilder.us.oracle.com> Message-ID: <9211301831.AA19785@xanadu.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain Our mechanisms for estimating credibility of a guarantor partly assume that life can be made difficult for the guarantor if they renege. Those intuitions are often completely wrong if the guarantor is anonymous. That's the main point of what I was saying. few, runs on the bank, I speculate, may not have been unknown in those cir- -cumstances where the community of bank depositors lost confidence in the bank or its officers. My understanding of the history of banking is that there are ZERO documented cases of runs on banks before the gov't started mucking with the banking industry. They started that mucking based on some economists projection that such a run could happen, so the gov't had to protect the pipul from it. It would be interesting to further study the origins of banking, as I expect such a study would provide many such parallels by which the case for digi- -tized banking could be made stronger ... It also has strong arguments for free banking, which is consequence of cryptographic electronic banking. dean From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: bwebster@pages.com (Bruce F. Webster) Date: Mon, 30 Nov 92 11:34:34 PST To: cypherpunks@toad.com Subject: Re: Paranoia and Cypherpunks Message-ID: <9211301900.AA14307@pages.com> MIME-Version: 1.0 Content-Type: text/plain > (Surely John Gilmore's lawsuit to get some critical crypto papers > declassified has already "angered" the folks at NSA. Are we to > censure John for stirring up trouble? Buy him a really nice dinner would be a more appropriate response. :-) 'Way to go, John! ..bruce.. --------------------------------------------------------------------- Bruce F. Webster | We hackers linger by our leading edge Chief Technical Officer | Forgetting what is pending in the cache Pages Software Inc | Till practice hurtles past us, bwebster@pages.com | and we crash. -- Jeff Duntemann --------------------------------------------------------------------- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: fen@genmagic.com (Fen Labalme) Date: Mon, 30 Nov 92 12:19:33 PST To: cypherpunks@toad.com Subject: Re: remailers Message-ID: <9211301903.AB08401@> MIME-Version: 1.0 Content-Type: text/plain [ Marc Horowitz writes: ] >People who want to use remailers don't necessarily have the access to >turn their site into one. Far more people use email than are >sysadmins, or friendly with one. [ mark@coombs.anu.edu.au (Mark) agrees: ] >What if for instance the user is sending from a student account or some >other limited system (such as a PC) and they either arent allowed to run >nohupped unattended processes or are unable to. Will you deny them the use >of your remailer simply because they cant, or havent the technical knowledge >on how to, install their own remailer? That sounds a bit odd to me.... First, things are changing. More and more people are owning their own machines and setting up their own mail. Heck, I'm planning on having my own internet node at home! Second, we need to proliferate remailers. Get the students running the system to install the code (perhaps for credit!). Or, if you're at a company, explain to the sysadmin that you need to have access to information that is only availble from sources on the other side of remailers, or, perhaps more generally, just indicate that you need connectivity and that not being a remailer cuts down on the number of sites that you can connect to. Finally, perhaps a "student" rating can be added (in addition to "free" and "reputation-based"). Keeping track of the reputations of remailers is a first step to being able to keep track of the reputations of signatures (whether real or pseudonymous). The next step is the active filtering based on such info. Fen From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: John W Noerenberg Date: Mon, 30 Nov 92 11:54:14 PST To: crunch@netcom.com (John Draper) Subject: Re: Classified info and other stuff. Message-ID: <9211301953.AA02873@harvey> MIME-Version: 1.0 Content-Type: text/plain At 10:44 PM 11/27/92 -0800, John Draper wrote: >Oh, By the way, numerious complaints have been said about the way that >the Mac PGP was stuffed when posted onto "umich'. I will be pushing for >releasing it stuffed with a self extracting archive instead. I also had >problems and lost significant time acquiring the new stuffit in order to >extract it. > >John D. Aladdin makes a freely available unstuffer which reads all their current formats, including self-extracting archives. I found it on their applelink bboard. john noerenberg jwn2@qualcomm.com noerenberg.j (Applelink) =========================================================== Do not uselessly lament your luck that is giving way, your work that has failed, your life's plans that have all ended in despair. Like a man long prepared, like a man of courage, bid her farewell, the Alexandria that leaves you. -- "The God Abandons Anthony", Constantine Peter Cavafy [1911] =========================================================== From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: phr@napa.Telebit.COM (Paul Rubin) Date: Mon, 30 Nov 92 11:54:35 PST To: eichin@cygnus.com Subject: Secure Key exchange In-Reply-To: <9211301925.AA29778@tweedledumber.cygnus.com> Message-ID: <9211301954.AA13674@napa.TELEBIT.COM> MIME-Version: 1.0 Content-Type: text/plain I have at this point signed keys of 6 people (the first three over dinner at a chinese restaurant -- this didn't start a trend, unfortunately :-) I haven't signed John Gilmore's key (even though I work for him) since I haven't actually seen him in person, though I may get a chance to when I'm in California next week -- this will create a link between east-coast and west-coast signatures, though possibly not the first. If you meet someone claiming to be John Gilmore, how will you know he's not an impostor? From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: deboni@diego.llnl.gov (Tom DeBoni) Date: Mon, 30 Nov 92 12:53:42 PST To: cypherpunks@toad.com Subject: tutorial needed Message-ID: <9211302051.AA25066@diego.llnl.gov> MIME-Version: 1.0 Content-Type: text/plain Howdy! I'm in need of a tutorial text that will bring me up to date on the current methods and terminology in the crypto arena. Any and all suggetions are welcome, and since this is probably an old and tired topic on this list, feel free to mail them to me directly. Thanks! Tom deBoni deboni@diego.llnl.gov From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Mon, 30 Nov 92 11:49:21 PST To: hughes@soda.berkeley.edu Subject: Secure key exchange In-Reply-To: <9211301721.AA17060@soda.berkeley.edu> Message-ID: <9211301806.AA08378@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: Eric Hughes >>There is no secure method of exchanging public keys using only the >>net. [spoofing, etc.] >As mentioned by Hal, the new PGP 2.1 (imminent) has a feature to >create an hash or a public key which can be read over the telephone to >make sure that a key transmitted electronically has not been altered >in transmission. Just to point out, though, this is not foolproof. A good impressionist can fool people, especially if they are extremely skilled. A person with Rich Little's or Peter Sellers' level of skill can sound astonishingly like the original person (although a sound spectrograph isn't fooled, other humans can be). Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) Date: Mon, 30 Nov 92 10:37:21 PST To: pfarrell@cs.gmu.edu Subject: Re: Secure Key exchange In-Reply-To: <9211301332.AA10244@cs.gmu.edu> Message-ID: <9211301836.AA20482@tsx-11.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain Date: Mon, 30 Nov 92 08:32:45 EST From: pfarrell@cs.gmu.edu (Pat Farrell) I sign keys only when I am certian that the key belongs to the human who claims to have the name on the key. There are not a lot of keys signed by me floating arround, maybe six total..... Ah, but how do we know that it's really you making this statement, and not some evil NSA spoofer? What people need to do is to make their key-signinging policies available _signed_ with their private key; that way at least we would know that the entity signing the keys and the entity claiming that this is its policy are the same. This helps, but we would then still need to trust that the entity is telling the truth insofar as its key-signing policy is concerned. - Ted From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pfarrell@cs.gmu.edu (Pat Farrell) Date: Mon, 30 Nov 92 11:11:12 PST To: tytso@ATHENA.MIT.EDU Subject: Re: Secure Key exchange Message-ID: <9211301910.AA11750@cs.gmu.edu> MIME-Version: 1.0 Content-Type: text/plain tytso@ATHENA.MIT.EDU (Theodore Ts'o) wrote: quoting: pfarrell@cs.gmu.edu (Pat Farrell) I sign keys only when I am certian that the key belongs to the human who claims to have the name on the key. There are not a lot of keys signed by me floating arround, maybe six total..... tt> tt> Ah, but how do we know that it's really you making this statement, and tt> not some evil NSA spoofer? What people need to do is to make their tt> key-signinging policies available _signed_ with their private key; that tt> way at least we would know that the entity signing the keys and the tt> entity claiming that this is its policy are the same. Exellent point. I'll put a signed statement of my policy in my .plan. It won't add many characters, and anyone can find it by fingering me. (and I've never claimed I don't work for NSA/CIA/...) tt> This helps, but tt> we would then still need to trust that the entity is telling the truth tt> insofar as its key-signing policy is concerned. I can't solve this one so easily. I have two ideas that can help: 1. change PGP in future versions (starting with 2.1?) so it doesn't ask for confirmation every time a key is added to the ring. Make the user do an active action, rather than a half-asleep y to sign a key. 2. store a comment in my secret ring that is captured each time I sign a key. Thus I could store the "reason/justification" for the signature to jog my memory. I know whose key's I've signed now, but as the number gets bigger, then I'll need a memory aid. I suggest the secret ring, as I share my public ring, and don't think that why I chose to sign a key should be generally available. If this were supported, you could then send me a msg asking "why did you sign John Doe's key?" You would have to compare my answer to my published policy and make your own judgement as to whether I follow it. I could keep track of this manually, and should. But PGP already requires me to have a lot of files arround. Pat Pat Farrell, Grad Student pfarrell@cs.gmu.edu Department of Computer Science, George Mason University, Fairfax, VA PGP key available via finger or request #include standard.disclaimer Write PKP. Offer money for a personal use license for RSA. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Mon, 30 Nov 92 14:14:20 PST To: cypherpunks@toad.com Subject: thoughts on digital cash In-Reply-To: <9211301957.AA10429@newsu.shearson.com> Message-ID: <9211302214.AA08418@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Perry writes: >If you take deposits and allow people to write drafts against those >deposits you are going to fall under the commercial banking or >securities laws no matter what you do, Eric. The definition of a bank is an institution that accepts demand deposits. From Black's Law Dictionary: Demand deposits. Any bank deposit which the depositor may demand (withdraw) at any time in contrast to time deposit which requires depositor to wait the specified time before withdrawing or pay a penalty for early withdrawal. Funds accepted by bank subject to immediate withdrawal; such represent largest element in money supply of the United States. Certain mutual funds which have checks available to them do not fall under this classification. Such a mutual fund might be said to have deposits, but they are not demand deposits. You can't get them whenever you like. The fine print of such aggreements states that the mutual fund company does not have to honor the check for up to thirty days, typically. Because of the time delay, such deposits are not payable on "demand." Mutual funds, though, since they are backed by securities, do fall under securities law. Again, from Black's: For purposes of the Securities Act of 1933 and the Securities Exchange Act of 1934, the term "security" embraces all investment contracts, and the test is whether the investment is made in a common enterprise which is premised upon the reasonable expectation of profits solely from the managerial or entrepreneurial efforts of others; such test contains three elements: the investment of money; a common enterprise; and profits or returns derived soleley from efforts of others. I merely pointed out that if you're not a bank, you're not under banking regulation. This does not preclude regulation under other laws. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: "Mark W. Eichin" Date: Mon, 30 Nov 92 11:25:34 PST To: pfarrell@cs.gmu.edu Subject: re: Secure Key exchange In-Reply-To: <9211301332.AA10244@cs.gmu.edu> Message-ID: <9211301925.AA29778@tweedledumber.cygnus.com> MIME-Version: 1.0 Content-Type: text/plain >> I see no reason to hurry. A slowly growing web of trust that >> is strong is far more useful than an exploding web of trash. precisely. I only sign keys when I've met the person physically, and had them tell me that yes, they have a PGP key, and yes, here are the lower bits (the keyid.) (The latter is a little weak, I look forward to the MD5 output version...) I keep keyid's in my "little black book" as well as my online keyring. Also, because keys are a reasonable "proof" that one is using PGP, some people will only release their "public" keys to people they will correspond with anyhow. (At least one key on the recent cypherpunks key list was in that category.) I have at this point signed keys of 6 people (the first three over dinner at a chinese restaurant -- this didn't start a trend, unfortunately :-) I haven't signed John Gilmore's key (even though I work for him) since I haven't actually seen him in person, though I may get a chance to when I'm in California next week -- this will create a link between east-coast and west-coast signatures, though possibly not the first. _Mark_ MIT Student Information Processing Board Cygnus Support From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: "Mark W. Eichin" Date: Mon, 30 Nov 92 11:37:42 PST To: tytso@ATHENA.MIT.EDU Subject: re: Secure Key exchange In-Reply-To: <9211301836.AA20482@tsx-11.MIT.EDU> Message-ID: <9211301937.AA29781@tweedledumber.cygnus.com> MIME-Version: 1.0 Content-Type: text/plain allegedly (:-) writes: >> key-signinging policies available _signed_ with their private key; that I noticed in the pgp docs that there is a "signature classification field" which has a (rather small) set of reserved values, only one of which is actually implemented: 10 - Key certification, generic. Only version of key certification supported by PGP 2.0. Material signed is public key pkt and User ID pkt. 11 - Key certification, persona. No attempt made at all to identify the user with a real name. Material signed is public key pkt and User ID pkt. 12 - Key certification, casual identification. Some casual attempt made to identify user with his name. Material signed is public key pkt and User ID pkt. 13 - Key certification, positive ID. Heavy-duty identification efforts, photo ID, direct contact with personal friend, etc. Material signed is public key pkt and User ID pkt. >> we would then still need to trust that the entity is telling the truth I think we probably need a similar "web" certifying operational procedures. (That is, I believe, one thing that the PEM hierarchy claims to provide -- the institutional signature providers are auditted, etc. to guarantee that they provide the claimed level of security.) Some people trust my signatures more than other signatures because I'm already known to be somewhat "paranoid" w.r.t. security matters... _Mark_ MIT Student Information Processing Board Cygnus Support From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Mon, 30 Nov 92 14:41:53 PST To: cypherpunks@toad.com Subject: thoughts on digital cash In-Reply-To: <9211301957.AA10429@newsu.shearson.com> Message-ID: <9211302241.AA00770@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain >However, I'm so certain that the law in the U.S. requires >that the bank have full information on the holders of all accounts >that I'm willing to bet $150 right now with anyone who believes >otherwise. You've certainly showed us that you believe this Perry, but otherwise this statement contains no educational content. This, to me, sounds like a grown-up version of "Is so!!!" backed up by "My bank account can beat up your bank account!" >[...] ID be presented when you open an account (I know that this is >now routine practice, although its possible that its only implied >from the standards used to determine non-compliance rather than >directly required by the law.) I'd really like to know if ID is required or not, for one, because that seems to affect the banks liability vis-a-vis presentation of false credentials. You made a claim of fact. I'm asking for you to provide a reference in support of your claim. Simple rational discourse. >[...] you are going to fall under the commercial banking or >securities laws no matter what you do, Eric. I'm sorry that you don't >like this, but its the truth. Now you're putting words into my mouth. I made no judgement as to whether I thought this was a good state of affairs. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pfarrell@cs.gmu.edu (Pat Farrell) Date: Mon, 30 Nov 92 11:44:28 PST To: cypherpunks@toad.com Subject: my key signing policy, signed Message-ID: <9211301943.AA11949@cs.gmu.edu> MIME-Version: 1.0 Content-Type: text/plain As suggested, here is a PGP signed copy of my policy. It and my public key is available via finger -----BEGIN PGP MESSAGE----- Version: 2.0 owGVVL9rFEEUToKKnm5nIWl8YBPxcjGJIkERlaBoQAKayiLM7b69G252Zp2ZvXOx FTGI/gmKdgER7PwBFnY2YiWCWIggImihqIUSfW/2Ek8E0eVgj5n343vf971dGloY WT+8azST28+Mdq+aj1eGh9+/HBm6e3OufHxh6fu968+e7vi05cGj+5e+fLt96/Om pdnl84cfPpk5sfD6xcSG6MfbrRdXGl8vb96/be7DtSMv36y0b8w+f3dned0rv9HJ ls6V0EP0wP8/J00XsyZamN5dh8mZmamodrotHdAvKyE3SsYlpMYC95G6BfPH5qGD pasDpinGXnYRUmsyDk+ldR4Kh2BSDmxEteOQiRLittAtBOlBavBtyih8YbEOQifQ k0qtRnju3e/qvPCYofacoakWVzNalQFLAAE9uoHjsNhEJbGLixQqQjxf8xCx0d4a pTCBZhkucrTO6KjWaxsCqkWGE9Q7UcjhRq8mN6isxbOFtIRWxDjuzTi/aQIqmBQ0 OQVTYlTDc330NHXeLp2MhQrwuEZbEEEMmBD4nqlgjxHjWqI9FIusYWxrZyCCqTeZ cHCY8Oo6HNg3tXd6X2Nycs/0odhkORFru9igvwdBpJ5EEzyNNAl3ZhwedUJ9BgGh jm2ZezrN0DnRQlLOaSEVCSNVpUDeNhqBUCuCzCz36Vxlk4kKuOnckAe8gXm64FRG TDy5vLKCKoPmQVJtgKPRDuolqVrh12iqB265YHgPAI9qv1EJY8EabKYmQiJdB8iU uaD5d/atEZjORILcWXjyTu65cpcoSstfzqgMQKBp3hIUtsLb9LSLanzPlliLJu8q ITNWMvmjVElFWoUSlvLZ9QEip0c18nleNMnH/UxtPHS06YFMq0xBvqoiQvuesR1e r4IEJF3JWc4VGZK7uN7fisTWmA6JGpucpc15NR3GFkmgFm0Pb6qPK11FVi1QjNbT INzwt4Wp9HXM2gBTtCk8nuOzPp6o9q8fGDbKUWEtKvXvSaeqfWG3rH5wgsg/AQ== =mxji -----END PGP MESSAGE----- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tom.jennings@f111.n125.z1.FIDONET.ORG (tom jennings) Date: Mon, 30 Nov 92 13:58:28 PST To: cypherpunks@toad.com Subject: USSC Cases Available Message-ID: <3939.2B1A8DA6@fidogate.FIDONET.ORG> MIME-Version: 1.0 Content-Type: text/plain Cross posted from a local net 125 echo... net access not availble for this system. ----------------------------------------------- | To All Sysops -- You might want to leave an | | announcement advising your users of the | | following. -={lsg}=- | ----------------------------------------------- USSC CASES & Selected Other Legal Decisions Available The PC GFX Exchange BBS in San Francisco has begun building a collection of US Supreme Court and selected legal decisions (eg., Cubby v. CompuServe). The files are PKZIPed and, after their initial upload, will eventually be moved into the board's file directory #64 (Legal & USSC Case Files). The BBS can be reached at the following numbers. 415-337-5416 HST144/v.32bis (public line) 415-337-5599 HST168/v.32bis (downloading for subscribers only) 415-337-6846 HST144 (public line) 415-337-6849 HST168/v.32bis (public line) While the board is an RBBSNet node, regretfully, FREQs are not currently available. PC GFX also carries the FidoNet LAW Echo as well as the LEGAL echos from SmartNet and ILink. A special note of deep appreciation to Mike Riddle and Alec Grynspan for their generous contributions to the file base. -==- --- msgedsq 2.1 * Origin: -={The Lyceum}=- San Francisco, CA (1:125/101) -- tom jennings - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!111!tom.jennings INTERNET - tom.jennings@f111.n125.z1.FIDONET.ORG From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: wcs@anchor.ho.att.com (Bill Stewart) Date: Mon, 30 Nov 92 11:45:58 PST To: cypherpunks@toad.com Subject: cypherpunks mailing list structure Message-ID: <9211301944.AA03295@anchor.ho.att.com> MIME-Version: 1.0 Content-Type: text It's nice to have cypherpunks-announce existing. A couple questions: - will all the cypherpunks-announce traffic be gatewayed to cypherpunks? (alternatively, have all the cypherpunks subscribers been added to -announce?) - will the new list be announced to sci.crypt, etc.? - we've already lost a number of subscribers from cypherpunks due to volume, so folks may have missed the announcement. I've been getting swamped by the number of postings coming in through the day, and we seem to have been losing a lot of people. It's getting hard to find my "real" mail in the clutter. An alternative structure, which libernet uses, is to have both batch and reflection subscriptions - batch folks get one digest a day, (produced automatically rather than by-hand as with some digest), which has the articles in alphabetic-by-Subject order to provide some continuity. Would it be possible for cypherpunks to do the same? Thanks; Bill Stewart, somewhere over New Jersey. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pfarrell@cs.gmu.edu (Pat Farrell) Date: Mon, 30 Nov 92 11:47:51 PST To: cypherpunks@toad.com Subject: My key policy signed. Message-ID: <9211301947.AA11983@cs.gmu.edu> MIME-Version: 1.0 Content-Type: text/plain As suggested, here is my key policy signed (not encrypted). It has minor rewordings from my clear text posting of this morning. It and my public key are available via finger. -----BEGIN PGP MESSAGE----- Version: 2.0 owGVVL9rFEEUToKKnm5nIWl8YBPxcjGJIkERlaBoQAKayiLM7b69G252Zp2ZvXOx FTGI/gmKdgER7PwBFnY2YiWCWIggImihqIUSfW/2Ek8E0eVgj5n343vf971dGloY WT+8azST28+Mdq+aj1eGh9+/HBm6e3OufHxh6fu968+e7vi05cGj+5e+fLt96/Om pdnl84cfPpk5sfD6xcSG6MfbrRdXGl8vb96/be7DtSMv36y0b8w+f3dned0rv9HJ ls6V0EP0wP8/J00XsyZamN5dh8mZmamodrotHdAvKyE3SsYlpMYC95G6BfPH5qGD pasDpinGXnYRUmsyDk+ldR4Kh2BSDmxEteOQiRLittAtBOlBavBtyih8YbEOQifQ k0qtRnju3e/qvPCYofacoakWVzNalQFLAAE9uoHjsNhEJbGLixQqQjxf8xCx0d4a pTCBZhkucrTO6KjWaxsCqkWGE9Q7UcjhRq8mN6isxbOFtIRWxDjuzTi/aQIqmBQ0 OQVTYlTDc330NHXeLp2MhQrwuEZbEEEMmBD4nqlgjxHjWqI9FIusYWxrZyCCqTeZ cHCY8Oo6HNg3tXd6X2Nycs/0odhkORFru9igvwdBpJ5EEzyNNAl3ZhwedUJ9BgGh jm2ZezrN0DnRQlLOaSEVCSNVpUDeNhqBUCuCzCz36Vxlk4kKuOnckAe8gXm64FRG TDy5vLKCKoPmQVJtgKPRDuolqVrh12iqB265YHgPAI9qv1EJY8EabKYmQiJdB8iU uaD5d/atEZjORILcWXjyTu65cpcoSstfzqgMQKBp3hIUtsLb9LSLanzPlliLJu8q ITNWMvmjVElFWoUSlvLZ9QEip0c18nleNMnH/UxtPHS06YFMq0xBvqoiQvuesR1e r4IEJF3JWc4VGZK7uN7fisTWmA6JGpucpc15NR3GFkmgFm0Pb6qPK11FVi1QjNbT INzwt4Wp9HXM2gBTtCk8nuOzPp6o9q8fGDbKUWEtKvXvSaeqfWG3rH5wgsg/AQ== =mxji -----END PGP MESSAGE----- Pat Farrell, Grad Student pfarrell@cs.gmu.edu Department of Computer Science, George Mason University, Fairfax, VA PGP key available via finger or request #include standard.disclaimer Write PKP. Offer money for a personal use license for RSA. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tribble@xanadu.com (E. Dean Tribble) Date: Mon, 30 Nov 92 15:20:39 PST To: uunet!anchor.ho.att.com!wcs@uunet.UU.NET Subject: cypherpunks mailing list structure In-Reply-To: <9211301944.AA03295@anchor.ho.att.com> Message-ID: <9211302248.AA21643@xanadu.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain I would note that even the current remailers can double as mail-sorters to sort your crypto mail into different bins. This lets you just peruse them once a day, and keeps your higher priority mail separate. I like this solution because more people will then have built-in remailers. Right now it only is set up for UNIX, but the ideas can be reproduced elsewhere. dean From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Mon, 30 Nov 92 12:38:24 PST To: hughes@soda.berkeley.edu Subject: thoughts on digital cash In-Reply-To: <9211301743.AA17881@soda.berkeley.edu> Message-ID: <9211301957.AA10429@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: Eric Hughes >>>** Legality of starting our own anonymous electronic bank: what do the >>>laws say, anyway? >Perry write: >>The law is a slippery thing -- however, anonymous bank accounts, no >>matter what you call them, are almost certainly illegal in the United >>States. >OK, Perry, time to quote sources. Exactly what laws _do_ prohibit >such bank accounts? I know securities law much better than commercial banking law -- I can't quote commercial banking law or the UCC for the most part, so I've got no idea precisely where in the codes such accounts are prohibited. However, I'm so certain that the law in the U.S. requires that the bank have full information on the holders of all accounts that I'm willing to bet $150 right now with anyone who believes otherwise. The law not only requires that the bank know who you are, but may even require that ID be presented when you open an account (I know that this is now routine practice, although its possible that its only implied from the standards used to determine non-compliance rather than directly required by the law.) I don't have any incentive to find the precise place in the books where it says you can't have an anonymous account in the US, but for a few hundred bucks in easy money I'd find it fairly quickly. If you don't believe me, well, have fun. >>Most computer people don't seem to understand that the law is >>interpreted not by a computer but by humans -- and they won't care >>what "hacks" you use. If it smells like a bank, they will >>likely convict you if it comes to that point. >Most political dissidents don't seem to understand that the law is >interpreted accurately, for the most part. There exist clear >statutory definitions on what a bank is. If you don't meet those >criteria, you're not a bank. If you take deposits and allow people to write drafts against those deposits you are going to fall under the commercial banking or securities laws no matter what you do, Eric. I'm sorry that you don't like this, but its the truth. The best you can hope for is to be classified as a mutual fund or the like and not as a commercial bank -- in which case the reporting requirements are just as tight and you fall under the even more restrictive securities laws. The securities laws are EXTRAORDINARILY tight when it comes to reporting. Other than brokerages holding securities in street name, nominee and other anonymous arangements of any sort are not merely prohibited under the securities laws but actual criminal offenses. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Mon, 30 Nov 92 15:04:22 PST To: cypherpunks@toad.com Subject: Electronic Banking In-Reply-To: <9211301830.AA23870@nano.noname> Message-ID: <9211302303.AA02723@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Hal mentions all the problems a going concern would have with an electronic banking: patent on the blind signature, RSA license also required, acceptable use policy, underlying legality. >I do think, though, that an informal digital cash system, presented as >a research project or an educational game, would be able to slip >between the cracks of the legal system, much as PGP has done. I agree. An experimental money system should be fine, practically speaking. There will be no problem if no goods or services change hands. If everything is scored in points, then there is no concern about money at all. More generally, a digital money system is isomorphic to a conserved quantity server. For example, if I were to write a distributed multi-player simulation game, I could represent conserved quantities such as fuel and ammunition as the equivalent digital money tokens. That is, in order to fire, I have to "spend" a bullet. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Mon, 30 Nov 92 14:03:15 PST To: tribble@xanadu.com Subject: credibility and banking In-Reply-To: <9211301831.AA19785@xanadu.xanadu.com> Message-ID: <9211302008.AA10892@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: tribble@xanadu.com (E. Dean Tribble) >My understanding of the history of banking is that there are ZERO >documented cases of runs on banks before the gov't started mucking >with the banking industry. They started that mucking based on some >economists projection that such a run could happen, so the gov't had >to protect the pipul from it. Not strictly speaking the case -- there were instances of bank runs under free banking systems, but restriction clauses usually eliminated these problems immediately. Restriction clauses permitted banks to briefly suspend payments in gold, with a heavy interest penalty paid by the bank. Such clauses allowed banks to stop runs, but they could not be lightly used. In any case, runs were quite infrequent under free banking systems. In any case, I believe that digital banknote systems, when they arrive, will almost certainly involve explicit issuance banks rather than any sort of anonymous banks. Likely such banks will first appear offshore and will, at least at first, be nothing more than banks that accept cryptographically signed electronic mail in the stead of checks and bank drafts. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: "Mark W. Eichin" Date: Mon, 30 Nov 92 12:09:44 PST To: phr@napa.Telebit.COM Subject: Secure Key exchange In-Reply-To: <9211301954.AA13674@napa.TELEBIT.COM> Message-ID: <9211302009.AA29816@tweedledumber.cygnus.com> MIME-Version: 1.0 Content-Type: text/plain allegedly asks: >> If you meet someone claiming to be John Gilmore, >> how will you know he's not an impostor? 1) I've met him before. (I wouldn't, for example, sign Tim Jennings' key after meeting him for the first time at a cypherpunks meeting, since I'd have no other way of identifying him. You, on the other hand, may be someone I've met before (do you think so?) so I might...) I've interacted with him to a reasonable extend, both socially and technically (including one interview with John Markoff.) 2) He signs my paychecks -- which is "good enough", since the checks clear :-) _Mark_ MIT Student Information Processing Board Cygnus Support From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hollander Date: Mon, 30 Nov 92 15:45:30 PST To: pmetzger@shearson.com Subject: Re: thoughts on digital cash In-Reply-To: <9211301957.AA10429@newsu.shearson.com> Message-ID: <9211302344.AA06143@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain We should just write all the software to fully automate the system, get lightweight hardware for it and some solar panels and launch it into orbit. Whose jurisdiction is that? e From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: wcs@anchor.ho.att.com (Bill Stewart) Date: Mon, 30 Nov 92 14:47:10 PST To: cypherpunks@toad.com Subject: Re: Unlabelled PGP messages Message-ID: <9211302245.AA04980@anchor.ho.att.com> MIME-Version: 1.0 Content-Type: text Hal Finney points out some problems with unlabelled messages, where the headers don't identify the public key by keyid - remailers include your email address, while newsgroups / broadcasts might have a LOT of articles, such that decrypting them to see if they're for you would be impractically slow. Some techniques that may help: - a remailer-to-newsgroup anonymous poster, which lets you send the remailer articles (presumably with unlabelled keys) to be posted to the alt.whatever group -- should be an easy combination of existing tools. - include an optional non-address label along with the unlabelled message. If you're having an ongoing secret conversation with somebody, you can secretly tell them the label to include, Subject: Unlabelled PGP message label: fnord If you don't see the fnords, you don't have to decrypt them. You don't want to use anything that can be traced to you, and you probably don't want to use labels in a sequence, or use the same label throughout a conversation, but it could help. You could also, if you're only mildly paranoid, use something like a 4-bit checksum of the PGP key or the key length as a label - it's not enough to identify which key it is, but it's enough to cut down on your decryption by a factor of 16. A longer checksum is too revealing - even 8 bits identifies 1/256th of the crypto community, which isn't very anonymous. With all these methods, if you're concerned about traffic analysis, you've still got to download the messages you don't care about to your machine before discarding them. - The Conventional Data Encryption (DEK) packet includes a checksum, which lets you know if you've successfully decrypted it using the RSA key, so you can tell quickly enough whether a message is for you, without decrypting the message itself. The RSA step probably takes most of the time for short messages, but it's still a win. (PGP does lose some security this way, since the Bad Guys can also tell if their exhaustive search of PGP keys has gotten the right one, and now they can go beat up the Key-Certifier to find out who the key really belongs to, but it's a start. If you want heavier anonymity, you have to do without the checksum. There's also an extremely small chance of an incorrect PGP key producing a correct checksum, but it's about 2**-26, and it still gives an incorrect session key.) Bill Stewart, somewhere in New Jersey From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: ghsvax!hal@uunet.UU.NET (Hal Finney) Date: Mon, 30 Nov 92 19:50:44 PST To: cypherpunks@toad.com Subject: Re: remailers Message-ID: <9212010311.AA24273@nano.noname> MIME-Version: 1.0 Content-Type: text/plain Fen Labalme quotes some messages with concerns about people needing permission from the sysadmins to run remailers. The current remailers, based on Eric Hughes' approach, don't have this problem. I don't even know who the sysadmin is on the system where I run the remailer. They don't know anything about it. Eric's remailers don't require continual processes to be run, root privileges, hacking the mail tables, or anything special. All you need is to be on a Unix system which supports the ".forward" file. This is typically implemented by the mail programs which deliver mail to the user's mail file. The programs check to see if a file called .forward exists in the user's home directory, and if so they treat its contents as either a program to pipe the incoming mail into, or a user name or list of user names to send the mail to. This is the hook by which Eric's remailers operate. The .forward file is set up so that mail is piped to a program which sorts the mail based on its headers, using the mh utility slocal or, in my case, a perl script which provides some of the same functions. Each message is checked like this, and if it doesn't contain any of the special stuff which activates the remailer software, it is simply deposted in the user's mailbox file as usual. Otherwise the remailers run and forward it as requested. With this solution, there's no need for anybody to be aware that you are running a remailer, as long as it's not too much of a load in terms of extra message traffic. Hal 74076.1041@compuserve.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: S.E. Brown Date: Mon, 30 Nov 92 20:18:21 PST To: cypherpunks@toad.com Subject: 386des wanted Message-ID: <9212010418.AA02687@toad.com> MIME-Version: 1.0 Content-Type: text/plain Does anyone possess a copy of the des package 386des? I've heard that it is incredibly fast, and would like to look at a copy. I have been unable to find it on any of the regular crypto haunts on the inet. Thanks in advance Shawn From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Mon, 30 Nov 92 17:41:25 PST To: wcs@anchor.ho.att.com (Bill Stewart) Subject: Re: Unlabelled PGP messages In-Reply-To: <9211302245.AA04980@anchor.ho.att.com> Message-ID: <9212010141.AA18205@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain [talks about posting anonymous messages that only recipient can decrypt] > like a 4-bit checksum of the PGP key or the key length as a label > - it's not enough to identify which key it is, but it's enough > to cut down on your decryption by a factor of 16. > A longer checksum is too revealing - even 8 bits identifies > 1/256th of the crypto community, which isn't very anonymous. Why not generate a key just for this conversation, and then post a full 128-bit (22 base64 characters) hash in the subject. You can even have a key for each message if the conconversation is two-way then whenever you are about to send a message you can generate a new key pair and include the new public key with your message. As soon as you receive and decrypt the message for that key, destroy the private key. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Mon, 30 Nov 92 18:39:37 PST To: hughes@soda.berkeley.edu Subject: thoughts on digital cash In-Reply-To: <9211302241.AA00770@soda.berkeley.edu> Message-ID: <9212010219.AA19516@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: Eric Hughes >>However, I'm so certain that the law in the U.S. requires >>that the bank have full information on the holders of all accounts >>that I'm willing to bet $150 right now with anyone who believes >>otherwise. >You've certainly showed us that you believe this Perry, but otherwise >this statement contains no educational content. This, to me, sounds >like a grown-up version of "Is so!!!" backed up by "My bank account >can beat up your bank account!" I'm sorry, but I can't be troubled to spend time looking for the regulation otherwise. This is tantamount to asking me to bother spending time looking up where in the law books precisely running red lights is outlawed. I'm certain its illegal, but have very little interest without a monetary incentive to go and look up precisely where it says so -- I'd gain no interesting information personally. I'd have to take time off of work and go to a law library to determine precisely where in the mass of regulations and laws this particular practice is prohibited. For $150, the hour or so of my time involved, although not well compensated for, would at least be sufficiently compensated for that I would bother. Obviously, this is not evidence of the truth, but as you have noted, it is evidence of a very strong belief. If you have evidence to the contrary, here is your chance not only to make $150 but to have me do all the work required for you to get your $150. >You made a claim of fact. I'm asking for you to provide a reference >in support of your claim. Simple rational discourse. You don't have to believe me if you don't want to. As I've said, I have very little incentive to track down the specific place that the practice of permitting anonymous accounts is outlawed -- but I'm as certain of it as I am that driving a car requires a license in all 50 states. If I asserted that fact, and you desired evidence, I would have a similar lack of desire to go and look up where specifically in the law books of all the states that driving without a license was listed as a violation. Doing legal research of this kind is not entirely unpleasant, but it is tedious and would put me out of my way, little or no reward. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Joe Thomas Date: Mon, 30 Nov 92 18:46:33 PST To: cypherpunks@toad.com Subject: Rumors of your existence Message-ID: MIME-Version: 1.0 Content-Type: text/plain As a follower of sci.crypt and comp.org.eff.talk, I felt I had to check up on the owners, if any, of this e-mail mailbox that was listed at the end of St. Jude's "Cypherpunk Movement" article in Mondo 2000 Issue 8. How "patently false" are the rumors you can be contacted here? Joe From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Mon, 30 Nov 92 22:48:00 PST To: cypherpunks@toad.com Subject: John Gilmore on CNN Message-ID: <9212010643.AA01350@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Our own John Gilmore's fame in the NSA-tweaking community continues. I just saw John interviewed by CNN for a report on crypto, the recent case involving the Friedman papers, and RSA Data Security's problems getting export licenses for its products. The piece ran on "Headline News," and possibly on the main CNN channel as well (as is typical). John spoke about crypto and the need for private individuals to have secure communications, a woman from CPSR spoke about recent threats to further limits communications privacy, and Jim Bidzos from RSA spoke about licensing for exports. The NSA had no substantive comment. All in all, no surprises for any of us. It was too brief, of course, but seemed fairly done. Reports like this will gradually get the word out. By the way, you should all check out John's excellent articles he wrote in sci.crypt about the declassification of the Friedman papers. If you don't have Usenet access, I'll mail them to the first several people who request them. (I'd just post them here, but John's in Japan and I can't get his permission.) --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tribble@xanadu.com (E. Dean Tribble) Date: Tue, 1 Dec 92 00:40:47 PST To: uunet!shearson.com!pmetzger@uunet.UU.NET Subject: thoughts on digital cash In-Reply-To: <9212010219.AA19516@newsu.shearson.com> Message-ID: <9212010700.AA24193@xanadu.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain For important claims like that, the value added is that other people putting in voluntary effort to produce things spend it in places that better satisfy your desires. It certainly is an indirect reward, however. dean From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Marc Horowitz Date: Mon, 30 Nov 92 21:13:48 PST To: cypherpunks@toad.com Subject: Chaum's DigiCash Message-ID: <9212010513.AA05283@steve-dallas.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain Does anybody have any contact information for David Chaum or DigiCash? I think it's worthwhile to find out if any of the problems we've been discussing have been previously solved. It's possible that our experiment could increase visibility of digital cash to the point that a real commercial venture could work, in which case he may even be interested in helping us. Email me personally, I'll summarize. Marc From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: karn@qualcomm.com (Phil Karn) Date: Tue, 1 Dec 92 02:24:57 PST To: phr@napa.Telebit.COM Subject: Re: Secure Key exchange Message-ID: <9212011022.AA25238@servo> MIME-Version: 1.0 Content-Type: text/plain allegedly asks: >> If you meet someone claiming to be John Gilmore, >> how will you know he's not an impostor? Get a copy of last Saturday's New York Times. John's picture appears on page 7. Of course, it's always possible for the NSA to print up a "special edition" of that paper just for you... :-) Phil From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: karn@qualcomm.com (Phil Karn) Date: Tue, 1 Dec 92 02:28:08 PST To: pmetzger@shearson.com Subject: Re: Secure key exchange Message-ID: <9212011027.AA25256@servo> MIME-Version: 1.0 Content-Type: text/plain >Just to point out, though, this is not foolproof. A good impressionist >can fool people, especially if they are extremely skilled. Perhaps. But if it's someone you know well, the imposter may have a hard time passing that particular Turing Test. For example, Jeff Schiller called me the other night, nominally to compare our RSA public keys before signing, but we ended up chewing the fat for nearly an hour. It would be hard for an imposter to duplicate that feat without arousing my suspicion. Another (somewhat more likely) possibility is that the NSA or FBI might be holding a gun to the guy's head when you call him up to verify the key you got with his name on it. Perhaps we need "duress" hash codes. :-) Phil From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: mlf3@Lehigh.EDU (Matt Fante) Date: Tue, 1 Dec 92 07:03:51 PST To: cypherpunks@toad.com Subject: Nonlinear CODEC of the digital domain Message-ID: <199212011455.AA69037@ns3.CC.Lehigh.EDU> MIME-Version: 1.0 Content-Type: text/plain Here is a new crypto idea - I would appreciate some feedback! Matt. My senior project is the extension of a grad student's *published* thesis entitled "Nonlinear CODEC in the digital domain". I use essentially a digitial filter to encode/decode the digital domain. I believe that it has applications to data security and I welcome people's input to this claim. The encoder. My prototype encodes 4-bits but I have software that works for n bits. If you would like to have the software let me know. I'm not an ASCII artist but here goes my best block diagram of the IIR digital filter encoder: x[n] ---------> + --------------------------> u[n] ^ | | | | | | | | -------------- | | z^(-1) | | -------------- | | | | | | + <------------------| ^ | | --------------- | | z^(-1) | | --------------- | | | | | --------------- | | Left Circ | | --------------- | | | | ---------------------- x[n] is the input data word, u[n] is the encoded output word, z^(-1) (z transform) is a delay element and Left_Circ is the left circulate function, i.e. Left_Circ(10)=5 (10 has binary representation 1010 and upon left circulation we get 0101 which has decimal representation 5). Another example is Left_Circ(3)=6. Clearly this filter is IIR with function: u[n] = x[n] + u[n-1] + Left_Circ( u[n-2] ) the decode is FIR and is found by solving for x[n] x[n] = u[n] - u[n-1] - Left_Circ( u[n-2] ) I won't bother you with another ASCII block diagram. I have run all kinds of signals (in software) through the filter pair. I get, what seems to me, a moderately secure coding of the digital domain with exact signal reconstruction from its coded form. Both Wavelet and Fourier techniques have failed to find anything "interesting" in the encoded domain. Please play around with this and send me feedback ( mlf3@Lehigh.EDU ) Matt. ________________________________________________________________ Matt Fante ________________________________________________________________ From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: mark@coombs.anu.edu.au (Mark) Date: Mon, 30 Nov 92 15:27:53 PST To: cypherpunks@toad.com Subject: Offshore banking.. Message-ID: <9211302309.AA12369@coombs.anu.edu.au> MIME-Version: 1.0 Content-Type: text/plain With respect to offshore banking, what about the legislation governing the export of money from the coutry? Here in Australia if we send an amount of money overseas then we have to pay a tax/levy of an amount based on the size of the funds being sent offshore. If we start snailmailing certified envelopes full of money overseas then someone will want to know about it so they can tax us. Im fairly sure there wouldnt be a problem (from the governemnt) with shuffling your funds from offshore bank to offshore bank. If encrypted money was going in and out all the time from a (legal) onshore bank that accepted digital transactions to an offshore one, then you would face the same export laws. How do the banks handle this when they send fifteen trillion overseas to have their money working for them while we all sleep at night....? Mark mark@coombs.anu.edu.au From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Karl L. Barrus Date: Tue, 1 Dec 92 09:03:17 PST To: cypherpunks@toad.com Subject: remailer scripts Message-ID: <9212011702.AA01281@tree.egr.uh.edu> MIME-Version: 1.0 Content-Type: text/plain In a previous message, Hal Finney describes in general terms how the anonymous remailer works. I have a "spare" account I could use to set up such scripts - it's an HP9000 model 730 running HP-UX (if that matters). So if someone will send me the scripts, I will try to install them and test them myself. And if I get it working, there will be a new anonymous remailer for our use... /-----------------------------------\ | Karl L. Barrus | | barrus@tree.egr.uh.edu (NeXTMail) | | elee9sf@menudo.uh.edu | \-----------------------------------/ From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Karl L. Barrus Date: Tue, 1 Dec 92 09:18:49 PST To: cypherpunks@toad.com Subject: Nike says: Just Do It Message-ID: <9212011718.AA01351@tree.egr.uh.edu> MIME-Version: 1.0 Content-Type: text/plain I agree with Mark's letter: we've philosophized enough - let's implement a digital bank. The only thing I have to go on is a recently posted summary of a digital cash scenario - apologizes to the poster, I don't have the article handy and I can't remember who nicely summarized the protocol. If that summary isn't good enough, I'll go look for more of Chaum's stuff. I'm willing to help pull such a feat off - even if to start I (and anybody else who wants to help!) take Email and respond by hand. The only high precision math routines I have are the rsa programs that are available @ghost.unimi.dsi.it (see Dave Vincenzetti's (sp?) recent message on sci.crypt) OR what I used during my crypto class for working through various protocols: Mathematica. Automating the procedure can come later, and I'm willing to work with anybody in doing that as well. If initially the transactions are handled by hand and Mathematica, don't expect a rapid turnaround! :-) The nice thing about Mathematica is that I can run it remotely and don't need to be in front of the NeXT to do it - especially since the command line version is good enough for out purposes: high precision integer math, etc. I remember the protocol involved a hash (MD5 is suggested) of an input to produce a number. Suggestions? Would turning the MD5 output into a hex number be good enough? Anyway, I'm going to work through the protocol a few times by hand and post again with more info in a bit... /-----------------------------------\ | Karl L. Barrus | | barrus@tree.egr.uh.edu (NeXTMail) | | elee9sf@menudo.uh.edu | \-----------------------------------/ From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: The Phantom Date: Tue, 1 Dec 92 13:32:27 PST To: cypherpunks@toad.com Subject: PGP and Digi-money Message-ID: MIME-Version: 1.0 Content-Type: text/plain Well, it looks like it is going to happen. I, too, am interested in seeing the experiment run. The way it was talked about earlier this week, I pictured a system where people would snail-mail an amount of money to a central authority (bank) and would be turned into credits. Since this was only a simulation (not to raise eyebrows) I was thinking that a cap could be established (say, $25). Now it looks as if we'll have no acutal cash backing for the first simulation. How will this be distributed? Should everyone on the list be given a set amount of digital cash to start the 'poker game', or will we choose a smaller, representative sample? For the game, we'll have to set up an account as an internet `bank', scripts to handle incoming cash requests, etc. Are these the least of our worries? I'm also willing to help in any way I can, although I too know little C. I have a decent background in various other areas which may be helpful. On an entirely different subject: Has anyone worked up a PGP version that may help me out? My 286 plugs along when working on keys. :) I am specifically wondering if anyone has hacked in and created a PGP that supports the '87 coprocessor. thanks- Matt Thomlinson University of Washington, Seattle, Washington. Internet: phantom@u.washington.edu phone: (206) 528-5732 PGP 2.0 key availaible via email or finger phantom@hardy.u.washington.edu From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: fnerd@smds.com (FutureNerd Steve Witham) Date: Tue, 1 Dec 92 10:17:44 PST To: extropians@gnu.ai.mit.edu Subject: Lazy man's PGP key collection Message-ID: <9212011758.AA05964@smds.com> MIME-Version: 1.0 Content-Type: text/plain I collect PGP keys with a PGP keys mailbox. Instead of trashing a message when I'm through reading it, if it has a PGP key, I transfer it to the PGP keys mailbox. In Eudora that means pulling down the Transfer menu to the "-> PGP keys" entry. These are, of course, only play keys. They could be from people who aren't who they say they are, or they could have been tampered with on the way to me. Unless they've been signed by someone I trust and have a trustworthy key for. (Just a standard disclaimer anytime I mention public keys.) -fnerd only her cryptographer knows for sure fnerd@smds.com (FutureNerd Steve Witham) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: fnerd@smds.com (FutureNerd Steve Witham) Date: Tue, 1 Dec 92 10:17:33 PST To: cypherpunks@toad.com Subject: Re: How far is to far? Message-ID: <9212011758.AB05964@smds.com> MIME-Version: 1.0 Content-Type: text/plain Mark (mark@coombs.anu.edu.au) sed > Maybe it's not in the spirit of this mailing group but Seems on topic to me. > what of the question > of purposeful abuse of the anon mailers/newsposters? Say for instance some > person posts either a sh*tload of garbage to every known group, flooding > the USENET... Tim May and Fen Labalme have given good replies. I hate the sloppy setup of the internet/usenet/netnews/mailing-lists in general. The way things are gives anarchy a bad name, and I think they could use a good hosing off--if only that would mean they would get cleaned. Unfortunately the way people react to abuses is often just to add extra patches. Take "kill files," which Tim mentions. The thing I hate about that term (even more than that they're lists of people to "kill,") is that they're after-the-fact. Here's this mail that keeps pouring into my mailbox, and every day my robot has to find and burn the 90% that even a robot can be taught to recognize as junk. Prompt, temporary STUPID relief of symptoms. (I mean, while I'm at it, I hate the broadcast-and-filter model of netnews, CD ROMs, and cable TV. I want things available for me to go fetch.) That kind of filtering has a place, but I like more positive-reputation, positive-interest models. Like subscription mail groups. Also, I understand that Fido users have to pay their own transport charges. I don't know if that applies to the "echo" groups, but it should...Mr. Jennings?...because that's another natural kind of filtering against network hosing. You can flood my mailbox if you pay me enough. >> or a more personal attack whereby they send out anonymously >> information that was so fundamentally personal to someone they could >> possibly react very badly.... >> >> What if someone posted some top secret information and the various three >> letter acronyms all went out for someone's blood. I guess these won't happen much, just judging from how much they happen now even though they're not that hard to do. But sure, they'll happen. It would be nice if people learned information-hygene lessons like skepticism and protecting privacy, and accepting-life lessons like accepting what does get revealed about oneself and others...(whistful grin). More like, people will learn if we teach; things will change if we change them. Scary issues are good educational material when used right, especially when you can say, "This is stupid and it can be *fixed* and we can use your help." -fnerd quote me...within *reason* of course fnerd@smds.com (FutureNerd Steve Witham) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: mark@coombs.anu.edu.au (Mark) Date: Mon, 30 Nov 92 19:38:20 PST To: cypherpunks@toad.com Subject: Why not just do it? Message-ID: <9212010337.AA21322@coombs.anu.edu.au> MIME-Version: 1.0 Content-Type: text/plain With all the talk of banking regulations etc with regard to messing with the monetary system, why dont we just create a test system where everyone emails in an amount that they are prepared to coughup if they really had to, but at the moment dont (have to). Then we can go ahead with the digital "cash" scenario and not be governed by the banking/security laws of any country because no real money is involved. The object is to get a system going, find flaws, create software and protocols and basically experiment with it. The issue of actual cold hard cash is, to me, a not important. After all it's just numbers. Eric volunteered to do this earlier and, if he still wishes to, I'd be willing to participate in it. Maybe he doesnt have the benefit of a big cushy bank trust account earning him intrest for his work, but I dont think that was a consideration for him anyway. Mark mark@coombs.anu.edu.au From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Richard Childers Date: Tue, 1 Dec 92 14:40:32 PST To: cypherpunks@toad.com Subject: Re: PGP and Digi-money Message-ID: <9212012239.AA25238@rchilder.us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain "Should everyone on the list be given a set amount of digital cash to start the 'poker game', or will we choose a smaller, representative sample? " Maybe we should generate some digicash with a PostScript printer, just to make it interesting. I wonder how public key cryptology would effect efforts to counterfeit ? It seems to me that this same technology could make cash much harder to forge ... even allowing one to actually _print_ one's tender, authenticated by the information buried in the serial number of the bill ... and it would be the serial numbers that the bank would track, not the actual pieces of paper. -- richard ===== -- richard childers rchilder@us.oracle.com 1 415 506 2411 oracle data center -- unix systems & network administration Klein flask for rent. Inquire within. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: The Phantom Date: Tue, 1 Dec 92 15:00:53 PST To: cypherpunks@toad.com Subject: whoops! Too much 8086 assembly, Message-ID: MIME-Version: 1.0 Content-Type: text/plain Too much assembly language and not enough FPU support. It was pointed out that I should simply try recompiling with the coprocessor option. :l Sure easier than writing it in assembly, eh? ahem. thanks for you time - Matt Thomlinson University of Washington, Seattle, Washington. Internet: phantom@u.washington.edu phone: (206) 528-5732 PGP 2.0 key availaible via email or finger phantom@hardy.u.washington.edu From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Karl L. Barrus Date: Tue, 1 Dec 92 19:20:22 PST To: cypherpunks@toad.com Subject: anonymous remailer Message-ID: <9212020319.AA03423@tree.egr.uh.edu> MIME-Version: 1.0 Content-Type: text/plain Fellow cypherpunks: There is a new anonymous remailer for our use. Its address is elee7h5@rosebud.ee.uh.edu, its name is "remailer03", and here is the public key: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAiscKOYAAAED/jmrZbh5t5HgEHDGE2zzFZx3sIplEjIFRFsLpCfJYBfN36Rm uT8VGIyCcUSmCTqEOJ5HJZF58CUCOsy3B215ptOvbZdGijC3Qs7FbtGHKGA49q0v gBgVIcjjyppRI9YjfqlI2gUKDLPceCTw20ODAA7UTKYIa3IBS32zjcrFq/uzAAUR tCZyZW1haWxlcjAzIDxlbGVlN2g1QHJvc2VidWQuZWUudWguZWR1Pg== =9mBX -----END PGP PUBLIC KEY BLOCK----- Also, here is a script I have to use the remailers. It is the ultimate in brute force :-) Perhaps if more people implemented remailers, a general script can be written to bounce mail off them all, or a subset of them all, in the style of Bill's scripts which were recently posted. It didn't take long at all to set up: I spent most the time installing perl in my account, and tracing down an annoying bug that was my fault - I forgot to make the *.pl files executable. -----------8<--------->8---------- if [ $# != 3 ] then echo "Usage: anon.mail message destination remailer" exit 1 fi anon1=remailing mail1=hal@alumni.caltech.edu anon2=remailer mail2=remailer@rebma.mn.org anon3=remailer03 mail3=elee7h5@rosebud.ee.uh.edu message=$1 dest=$2 if [ $3 = remailing -o $3 = hal -o $3 = alumni -o $3 = 1 ] then remail=$anon1 mailaddr=$mail1 fi if [ $3 = remailer -o $3 = rebma -o $3 = 2 ] then remail=$anon2 mailaddr=$mail2 fi if [ $3 = remailer03 -o $3 = elee7h5 -o $3 = rosebud -o $3 = 3 ] then remail=$anon3 mailaddr=$mail3 fi t1=.anon1 t2=.anon2 echo "::" > $t1 echo "Request-Remailing-To: $dest" >> $t1 echo "" >> $t1 pgp -ea $t1 $remail echo "::" > $t2 echo "Encrypted: PGP" >> $t2 echo "" >> $t2 cat $t1.asc >> $t2 cat $message >> $t2 rm -rf $t1 $t1.asc mail $mailaddr < $t2 -----------8<--------->8---------- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Bill O'Hanlon Date: Tue, 1 Dec 92 20:27:29 PST To: cypherpunks@toad.com Subject: Re: anonymous remailer In-Reply-To: <9212020319.AA03423@tree.egr.uh.edu> Message-ID: MIME-Version: 1.0 Content-Type: text/plain > > >Fellow cypherpunks: > (Karl's remailer announcement, key, and script elided. Thanks, Karl -- the more the merrier! And the more, the safer, I would think.) I've got a couple really trivial comments. Karl, your script called "mail" to deliver the file. Looks like it works on your machine, but on mine, "mail" called /bin/mail, which seemed to put an "Apparently-To: xxx" header in the message, and messed things up. If any of you have a problem with Karl's script, you might check that. I used elm to send the file, but I would think /bin/mailx or /bin/Mail (depending on what Unix you're using) would work as well. Also, I'm hoping one of you who is proficient in perl will rewrite the darn thing. It needs generalizing, and perl's just the language for the job... As a Bourne shell script, it looks ugly, especially with all those temporary files all over the place. -Bill -- Bill O'Hanlon wmo@rebma.mn.org From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: hugh@domingo.teracons.com (Hugh Daniel) Date: Wed, 2 Dec 92 04:49:15 PST To: cypherpunks@toad.com Subject: Help with the contents of the Cypherpunks Mail Archive Message-ID: <9212021248.AA08444@domingo.teracons.com> MIME-Version: 1.0 Content-Type: text/plain As I said I would at the last 'in person' meeting I am starting up a mail archive of usefull things for old and new Cypherpunks. At first we will have a few files that can requested over email, ftp and more complex files sturctures might come later. The most important files that needs to get built are the FAQ (Frequently Asked Questions), the Glossary and the bibliographys. These need to be done keeping in mind who we want to reach, the programmer new to crypto systems and useage. This is a group effort, if you have a good definition of a word send it to me, I will likely use it! If you think you can do a great job of describeing one of the questions from the FAQ in a page or so, whip it out and send it to me! I will compile/edit what ever comes my way into the right place in the archive files. Once we have a good FAQ then when new folks join the list we can send them the FAQ to read and get them up to speed that much faster. This will mean that we will have just repetition on the main list and therefore a better signal to noise ratio! So, go over the list at the end of this email message and see if there is anything you want to tackle, and if there is write some of that English code! ||ugh Daniel Keeper of the archive for now... Propsed contents of the Cypherpunks mail archive. Glossory Bibliography Beginers Anotated Bibliography by Subject FAQ --- A beginers guide to Cypherpunking What is the cypherpunks list all about? Why do I need crypto? What is privacy? What are public keys? What is the differences between DES & RSA? Why can't I just use rot13? Why is generateing random numbers hard? Why do crypto in software insted of hardware? Why is this crypto stuff still legal? What journals are there on this subject? What are the good beginer books on crypto systems? What is the NSA and why does everyone seem to hate them? What is crypto anarchy? Is all I need to crypt my email? What are remailers and DC-Nets? What can I do? Sources Remailer sources Random number generators & testers From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Karl L. Barrus Date: Wed, 2 Dec 92 06:34:45 PST To: cypherpunks@toad.com Subject: summary of remailers Message-ID: <9212021434.AA04655@tree.egr.uh.edu> MIME-Version: 1.0 Content-Type: text/plain Here is a summary of the currently available anonymous remailers: hal@alumni.caltech.edu -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.01 mQBNAisCtU0AAAEB/jNOYzN1B2YzOxlK/Zb6axoOaGlPq5I7DV9GH3hcGRN5N6Fi T4sRLhi53Sc5rUdYDa8mFQd4tqvFG6rHcT8LtDcABRG0KlJlbWFpbGluZyBTZXJ2 aWNlIDxoYWxAYWx1bW5pLmNhbHRlY2guZWR1Pg== =K00H -----END PGP PUBLIC KEY BLOCK----- remailer@rebma.mn.org -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAisUI2QAAAEEAKgm07Hsje5KpmXYd5azk0R6AES+qK7LcofnVGojUs7GBghD WbwrmW8oOEOhRorlShRALKeYspV4xYIw4WDkJcJxuf1B254scz1urF/Eem3zPW9b yPAx7W/cGwvs6SouZvFcSDq4v1zApvGE9hP4szPzHeGmVr0NVNeaDK0guoCpAAUR tCBSZW1haWxlciAocmVtYWlsZXJAcmVibWEubW4ub3JnKQ== =/qHx -----END PGP PUBLIC KEY BLOCK----- elee7h5@rosebud.ee.uh.edu -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAiscKOYAAAED/jmrZbh5t5HgEHDGE2zzFZx3sIplEjIFRFsLpCfJYBfN36Rm uT8VGIyCcUSmCTqEOJ5HJZF58CUCOsy3B215ptOvbZdGijC3Qs7FbtGHKGA49q0v gBgVIcjjyppRI9YjfqlI2gUKDLPceCTw20ODAA7UTKYIa3IBS32zjcrFq/uzAAUR tCZyZW1haWxlcjAzIDxlbGVlN2g1QHJvc2VidWQuZWUudWguZWR1Pg== =9mBX -----END PGP PUBLIC KEY BLOCK----- /-----------------------------------\ | Karl L. Barrus | | barrus@tree.egr.uh.edu (NeXTMail) | | elee9sf@menudo.uh.edu | \-----------------------------------/ From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tribble@xanadu.com (E. Dean Tribble) Date: Wed, 2 Dec 92 13:16:58 PST To: uunet!toad.com!hugh@uunet.UU.NET Subject: Help with the contents of the Cypherpunks Mail Archive In-Reply-To: <9212021248.AA08444@domingo.teracons.com> Message-ID: <9212021905.AA04514@xanadu.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain Other topics for the FAQ: crypto for authentication pseudonyms economics of privacy/security what's in a reputation digital cash verifying keys dean From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nobody@rosebud.ee.uh.edu Date: Wed, 2 Dec 92 09:12:11 PST To: cypherpunks@toad.com Subject: . Message-ID: <9212021712.AA14781@toad.com> MIME-Version: 1.0 Content-Type: text/plain Subject: Digital Cash One point of digital cash is to allow electronic payments, so printing it on paper would not be useful as other than a novelty. People would have to scan the bit patterns back in, which would be inconvenient. How big will a piece of digital cash be? An electronic "dollar bill" in the simple scheme of Chaum's consists of two parts: (x, f(x)^(1/e). X is a random number, f(x) is a one-way function like MD5, and e is the exponent which could be taken to represent the denomination of the bill. MD5 takes 64 bytes as an input "chunk" so that would be a natural size for x. f(x)^(1/e) is f(x) "signed" by the bank using exponent e, so that would be about the size of the bank's modulus n, say 1024 bits or 128 bytes. Probably there would be some control information as well. So the total size of an electronic banknote would be 128 + 64 + a few, or about 200 bytes, maybe a little more. To print this you'd have to Ascii-encode it, which generally expands things by 1/3, so you'd get about 270 to 300 characters per bill/coin. This would be around four or five lines of text, comparable to a PGP key (and looking about as interesting - totally jumbled letters and numbers). "Forgery" is in one sense hard and in one sense easy. It's hard because to create new dollar bills because you have to forge a signature using the bank's public key (n, e). This is equivalent to breaking at least some uses of RSA. But it's easy to reproduce existing electronic dollars, and you don't even need a Xerox machine. Just "copy dollar1 dollar2" on your PC, and repeat the process. Presto, plenty of dollars, all exactly the same. Send one to the butcher, one to the baker, and you've still got plenty more where those came from. Keeping this kind of re-use from occurring is one of the things that makes electronic cash tricky. Chaum's simple scheme has the receiver of cash calling the bank or sending the cash there right away. The bank has a list of "serial numbers" for all the cash that's ever been deposited, which it compares against to see if this is a re-use. The first person to deposit a dollar with a given serial number gets credit for it; the others are told that it's worthless. Another area that people seem a little unclear about is the difference between electronic cash and electronic checking accounts. A checking account could be managed by simple RSA-signed messages (e.g. created with PGP) saying, please transfer $X.00 to account number XYZ. If you wanted to buy something from someone, you'd find out what his account number is with the bank, write up a little note like this, sign it using your public key with PGP, and email it to the person that you wanted to buy from. He'd send it on to the bank and his account would get credited. Again, you'd want to put a serial number on your check so that the guy couldn't send it again tomorrow and get another $X.00. Or, you could just send it directly to the bank and request the bank to notify the seller that the funds had been transferred. This would seem to avoid the re-use problem. The difference between this system and electronic cash is that the bank knows exactly what is going on. It sees all transactions, so it knows which accounts are making payments to which other accounts. This is true of ordinary paper checking accounts as well, of course. Electronic cash is designed so that not even the bank can tell who is paying whom. I withdraw some cash, say, $100.00, and I pay you $35.00 by mailing you the electronic bills. You deposit them. The bank has no way of determining which particular withdrawal produced those bills which you are depositing. This is, more or less, how real cash works. Hal 74076.1041@compuserve.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Wed, 2 Dec 92 12:32:11 PST To: cypherpunks@toad.com Subject: FAQ in sci.crypt Message-ID: <9212022031.AA14301@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Cypherpunks of Cypherspace, I just found a new FAQ and bibliography in sci.crypt. It's by Larry Loen and is intended as a stopgap FAQ, as sci.crypt hasn't had a good FAQ in a while. It doesn't cover the digital cash, anonymous remailers, crypto anarchy, etc. kinds of stuff, but it answers FAQs about one-time pads, ciphers, RSA, etc. Since this is a mailing list, I will not forward it. (It's 26 or so screenfuls of VT-100 screens, which is fairly long.) Also, I still have the "Crypto Glossary" available for forwarding to any newcomers to this list. --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: crunch@netcom.com (John Draper) Date: Wed, 2 Dec 92 13:22:39 PST To: cypherpunks@toad.com Subject: Suggest splitting things up Message-ID: <9212022122.AA16492@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain To Cypherpunks: Greetings, Back on-line again, after wading through about 225 messages that has accumulated in the last 4 days. The volume of messages is really getting high, and perhaps we might want to try and break them up into the following proposed lists. a) PGP Development - a mailing list has already been set up, but is reserved exclusivly for those doing the actual coding work. b) Digital money - A lot of traffic seems to contain this subject, which is all very interesting, but doesn't apply to me because money is something I never seem to have anyway. c) Key management and collaboration - for discussion on various key exchange methodology. Anyway, this is just a thought. And might help to cut down traffic. One also might consider setting up a newsgroup. JD From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: edgar@spectrx.Saigon.COM (Edgar W. Swank) Date: Thu, 3 Dec 92 15:26:58 PST To: Cypherpunks Subject: Re: Secure key exchange Message-ID: MIME-Version: 1.0 Content-Type: text/plain Anserwing some comments about my suggestions for key verification. Phil Karn pointed out that the next version of PGP will display an MD-5 hash of any public key for phone comparison purposes. That's great, but that version of PGP isn't here quite yet. I suspect, in any case, that the added security isn't all that great since I suspect it's very hard to find another valid key-pair where the public key matches the last 24 bits plus some fragment of another 20 bits or so from the middle of the key. Phone, as opposed to mailed paper verifications has the following problems: Phil says you have to recognize the voice, which implies you've met him in close quarters, which implies you could have exchanged keys physically anyway. If the only place you've heard the voice is over the phone, that's not a very good criterion. Phone verification is good, IMHO, *only* if the person being verified is *called at a listed number*. You can't verify a person who calls you, (unless you know the voice). You can't verify a person you call at an unlisted number which you got over the net!! Economics: Net participants are scattered over the country and even the world. Paper verification costs about $2-$3 allowing for my fee, copying costs and two-way international postage. Adding notarization adds about $5.00. Phone verification is economical locally (maybe cheaper than mail), but more expensive when long-distance rates apply, especially international rates. Meeting at parties or face-to-face is most expensive of all, unless the meeting happens fortuitously. Overseas plane fare to exchange keys is beyond the means of most of us. Phil says: I would much rather trust a simple verification procedure based on redundancy and close personal relationships than a single, complex, impersonal process involving people I don't know. This is not to impugn your integrity, of course -- I'm simply speaking on principle. No offense taken! I, on the other hand, would rather have in my hand a signed statement of identity with photocopied ID that I can keep and file away. I also don't want to go broke making international phone calls. As it happens, I, so far, have not been able to sign a single key!! I called Phil Zimmerman at a listed number, I read him my key and he signed it, but he was called away from the phone before he could verify his key to me. So I can't sign his! I've met a few people at parties I've given my paper key (fragments) to. So far none of them have signed my key, but none of them had paper key fragments to trade, so I can't sign theirs. George Gleason commented about supplying home addresses. Your comments are well taken. Phil Zimmerman also commented to me in E-mail that some people don't want the serial numbers on their photo ID copied. Everyone please feel free not to supply a home address and to obscure any home address or serial number on the photocopied photo ID. I'll still sign your key, although I'll note what you did in my signed key directory, which I'll send to customers & publish here. If you don't want *me* to know your home address, you can use a P.O. box for me to return my (or other customers') ID certificate(s) to you. On the other hand, as the service provider, MY home address and phone are public info. I also acknowledge George's criticism re the "I'm not a cop" statement. I'm going to leave it in my statement, because it's true, but in general you should be aware that any legal protection is questionable at best. The lack of protection has been verified by a source on Extropians and by an attorney on the RIME network. In the meantime, I guess we can discuss illegal subjects not with "I've done ..." but with "I've heard that ..." or "I used to know somebody who ...". Also anonymous remailers will be a big help. -- edgar@spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: centaur@netcom.com (Paul Blair) Date: Wed, 2 Dec 92 14:53:33 PST To: cypherpunks@toad.com Subject: Information wanted Message-ID: <9212022252.AA07012@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Hello there! I'm interested in getting information on the cypherpunk movement. Could y'all perhaps e-mail me back with your manifesto and suchlike things? Much obliged! Paul -- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: John W Noerenberg Date: Wed, 2 Dec 92 16:01:19 PST To: crunch@netcom.com (John Draper) Subject: Re: Suggest splitting things up Message-ID: <9212030000.AA02120@harvey> MIME-Version: 1.0 Content-Type: text/plain At 1:22 PM 12/2/92 -0800, John Draper wrote: >To Cypherpunks: > >Greetings, Back on-line again, after wading through about 225 messages >that has accumulated in the last 4 days. The volume of messages >is really getting high, and perhaps we might want to try and break >them up into the following proposed lists. Sounds like a fine idea. john noerenberg jwn2@qualcomm.com noerenberg.j (Applelink) =========================================================== Do not uselessly lament your luck that is giving way, your work that has failed, your life's plans that have all ended in despair. Like a man long prepared, like a man of courage, bid her farewell, the Alexandria that leaves you. -- "The God Abandons Anthony", Constantine Peter Cavafy [1911] =========================================================== From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nobody@rosebud.ee.uh.edu Date: Wed, 2 Dec 92 16:43:39 PST To: cypherpunks@toad.com Subject: No Subject Message-ID: <9212030043.AA01011@toad.com> MIME-Version: 1.0 Content-Type: text/plain This is a test post of a triple-remailed message, all encrypted. Sent at Wed Dec 2 16:17:47 GMT 1992 (Signed) Guess Who? From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Karl L. Barrus Date: Wed, 2 Dec 92 18:17:58 PST To: cypherpunks@toad.com Subject: digital banking, file formats, etc. Message-ID: <9212030217.AA07111@tree.egr.uh.edu> MIME-Version: 1.0 Content-Type: text/plain This is a run through of Hal Finney's summary of the bank protocol. Here is what I envision the digital bank working like, with rough sketches of file formats, conspicuously similar to the remailer's :-): 1) Alice chooses x, r Alice computes B = r^3 * f(x) mod n Alice sends the following message to the bank via an anonymous remailer :: withdraw Reply-To: In the final version, this message will be encrypted as well 2) Bank computes D = B^(1/3) checks for balance, withdraws if ok Bank sends to appropriate remailer :: Encrypted: PGP 3) Alice computes C = f(x)^(1/3) by dividing D by r. Alice gives Bob (x, C) - via anonymous mail, presumably :-) 4) Bob wants to verify (x, C) Bob mails to Bank via anonymous remailer :: verify Reply-To: In the final version, this message will be encrypted as well 5) Bank checks x to see if its been used Bank sends back to remailer :: Encrypted: PGP 6) Bob accepts the "cash" Bob sends to bank via anonymous remailer :: deposit Reply-To: 7) Bank checks x, C, account name; if everything OK, deposit Bank replies via anonymous remailer :: Encrypted: PGP Alice and Bob may send message to and receive messages from the bank via anonymous remailers. Or more than one... During the testing/development phase, account names and balances can be made public (available via finger command or something like that) for verification. Account names can be hashes of some user chosen string (Email address plus random text, etc.) Customers must be able to choose: two random numbers x, r compute: f(x) r^3 * f(x) mod n f(x)^(1/3) or C^3 solve: D = C r mod n for C Bank must be able to solve: D^3 mod n for D So, PGP has routines which can generate random number, calculate hashes, and be modified slightly to perform the necessary math. The Bank will be supported by a host of scripts and the math performing PGP routines. Sometime later I will post a run through of the digital bank protocol (all numbers and done with Mathematica) as an example for those who are interested in an example of the protocol. Any input or comments or help will be welcome. Or, if someone else is further along than me, I volunteer! Unfortunately, since the end of the semester draws near, I will be unable to work on this very much for the next few weeks. Besides, I've got to go pick up the O'Reilly and Associates Perl book to move this project along... --- /-----------------------------------\ | Karl L. Barrus | | barrus@tree.egr.uh.edu (NeXTMail) | | elee9sf@menudo.uh.edu | \-----------------------------------/ From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Peter Shipley Date: Wed, 2 Dec 92 20:33:22 PST To: cypherpunks@toad.com Subject: Re: Suggest splitting things up In-Reply-To: <9212030000.AA02120@harvey> Message-ID: <9212030432.AA01759@edev0.TFS> MIME-Version: 1.0 Content-Type: text/plain >At 1:22 PM 12/2/92 -0800, John Draper wrote: > >>To Cypherpunks: >> >>Greetings, Back on-line again, after wading through about 225 messages >>that has accumulated in the last 4 days. The volume of messages >>is really getting high, and perhaps we might want to try and break >>them up into the following proposed lists. > >Sounds like a fine idea. > I aggree. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Peter Shipley Date: Wed, 2 Dec 92 20:36:57 PST To: shipley%edev0.Tfs.COM@gateway.Tfs.COM Subject: Re: Suggest splitting things up In-Reply-To: <9212030000.AA02120@harvey> Message-ID: <9212030436.AA01770@edev0.TFS> MIME-Version: 1.0 Content-Type: text/plain I suggest to groups be split as suggested but I will like to add that it be donw cypherpunks-pgp: pgp development cypherpunks-digi-cash: digital cash cypherpunks: cypherpunks-digi-cash cypherpunks-pgp (all of the above) -Pete -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQA9AirUzbUAAAEBfjC3p5COEUMJ3xzrq4sJCTaU5MgvzC94tp8yxxBJeKUGo7xx gMShBCnIZp+xlFiyxQAFE7QYUGV0ZXIgTSBTaGlwbGV5IChjYXN1YWwptAZjYXN1 YWy0JlBldGVyIE0gU2hpcGxleSA8c2hpcGxleUBiZXJrZWxleS5lZHU+ =OR9u -----END PGP PUBLIC KEY BLOCK----- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Richard Childers Date: Wed, 2 Dec 92 21:14:29 PST To: cypherpunks@toad.com Subject: Re: Suggest splitting things up Message-ID: <9212030513.AA04842@rchilder.us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain >>Greetings, Back on-line again, after wading through about 225 messages >>that has accumulated in the last 4 days. The volume of messages >>is really getting high, and perhaps we might want to try and break >>them up into the following proposed lists. >Sounds like a fine idea. "I aggree." So do I, but a digest ( 225 / 4 == 56.25 messages per day, concatenated into one giant digest of messages, sans headers ) would also make the traffic manageable, while preserving the ability for the various groups to benefit from one another's divergent, but relevant, insights into the overall process and its possible applications. Even if you split the list into multiple 'sub-topical' lists, you'll be 'swamped' with N times the maintenance ( and I suspect maintenance is already a bit of a hassle, with bounce messages and the like 'deluging' the hapless administrative staff with a 'rain' of problems ), as well as 'flooded' with N times as many subscribe and unsubscribe requests ... and will probably still contemplate a digest format eventually. (-: An interactive direct mail option should be preserved, in fact, it would remain the primary entity ... all that's needed is to add some sort of alias that evaluates to a queue to the list, then write a script to read the queue ( with some queue management to avoid race conditions ), strip out all but trivial header information and '> ' those left behind, and generate email to those individuals whom have transferred themselves from the primary alias to the secondary digestifier-and-remailer. There's a thing called majordomo@greatcircle.com that does this, I think. I don't know if it's public domain, but it does a lot of this, firewalls and firewalls-digest are both served by it, and I think it also provides archival services and such. ( There are others, also. ) My $0.02. -- richard From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Wed, 2 Dec 92 21:28:56 PST To: cypherpunks@toad.com Subject: Re: Suggest splitting things up In-Reply-To: <9212030436.AA01770@edev0.TFS> Message-ID: <9212030528.AA25608@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Peter Shipley is one of several people suggesting this list be split into parts. His specific idea is: > I suggest to groups be split as suggested but I will like to add > that it be donw > > cypherpunks-pgp: pgp development > cypherpunks-digi-cash: digital cash > > cypherpunks: cypherpunks-digi-cash cypherpunks-pgp (all of the above) Splitting the list into "pgp development" and "digital cash" would take care of the topics being discussed in the _last few days_, but would do little for the various other "threads du jour" that have occupied us: one-time pads, dongles, legal issues, key registration, special purpose chips, etc. Are we to form a new list each time something fails to fit into one of the groups suggested? I think there's a simpler split, should one be needed: * cypherpunks-technical...writing software, details of dongles, math, PERL, details of algorithms, PGP development, etc. *cypherpunks-political...laws, debate, public policy, ethics of encryption, spread of digital cash, etc. *cypherpunks-announce....just the announcements of meetings, upcoming events, important developments, etc. Now splitting the list means more duplicate messages for those who subscribe to both (when messages are cross-posted, as some will be), more "missed" messages when one of the groups is not subscribed to (resulting in "Can you send me the article....?" thrashing), and some amount of additional work by the list administrator (Eric Hughes). Given that a list bifurcation will only buy a savings of 2x in volume for most people (and many will automatically take both lists), and given that we all know factors of 2 don't count (:-}), I recommend against splitting the list. Besides, you never know what useful stuff will get posted in the group you don't get. Anybody who chooses to stay ignorant of what the other group is doing probably won't be able to contribute much to the group he subscribes to. --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Karl L. Barrus Date: Wed, 2 Dec 92 19:49:53 PST To: cypherpunks@toad.com Subject: bank protocol run through Message-ID: <9212030349.AA07296@tree.egr.uh.edu> MIME-Version: 1.0 Content-Type: text/plain I find it useful to work through a protocol by hand a few times to really see what's going on. Here is an example of the digital bank protocol. It is meant for people who are curious to see if it works, as educational material for new subscribers, or general interest. I'm choosing relatively small numbers to use: in a real implementation, they would be much much larger. OK, let's start! ---------------------------------------- On the bank's side, it chooses the primes p = 2038074743 and q = 2038074947 and so the public key n = pq = 4153749073821763621 also phin = Euler totient function of n = (p-1)(q-1) = 4153749069745613932 The bank decides to make people use the exponent 5 (it's just easier to tell if GCD[5, phin] is 1) 1) Alice chooses a random x, r. She hashes x to yield fx x = 3141526535 r = 5772156649 fx = 2718281828 Here, I just picked the value of the hash function from the mathematical air, so to speak. Alice computes B = r^5 fx mod n = (5772156649^5 2718281828) mod 4153749073821763621 = 592088213321408342 -> B = PowerMod[r^5 fx, 1, n] in Mathematica Alice sends B to the bank. 2) The bank takes fifth root of B. Or, it raises B to the power that is the inverse of 5 mod n. To find the inverse of 5 mod n, compute inv1 = 5^(-1) mod phin = 5^(-1) mod 4153749069745613932 = 1661499627898245573 The bank can do this since it knows the factorization of n. -> inv1 = PowerMod[5, -1, phin] in Mathematica So, to take the fifth root: D = B^inv1 mod n = (592088213321408342 ^ 1661499627898245573) mod 4153749073821763621 = 1189395596986402260 -> D = PowerMod[B, inv, n] in Mathematica Just as a check: D^5 mod n = = (1189395596986402260 ^ 5) mod 4153749073821763621 = 592088213321408342 = B So we're OK. -> Mod[D^5, n] in Mathematica Bank sends Alice D. 3) Alice extracts C by dividing D by r. Or, she solves the following equation for C: D = C r mod n, or 1189395596986402260 = C 5772156649 mod 4153749073821763621 This can be solved by multiplying D by the inverse of r mod n, and taking the result mod n. You don't need to know the factors of n. As a technical note, there will be only one solution since GCD[D,n] = 1, which is usually true since n only has two factors p and q. The bank is in trouble if GCD[D, n] != 1 since that means n can be factored by the information in D. inv2 = r^(-1) mod n = 5772156649 ^ (-1) mod 4153749073821763621 = 3900656075651054436 -> inv2 = PowerMod[r, -1, n] in Mathematica So, C = (D inv2) mod n = (1189395596986402260 3900656075651054436) mod 4153749073821763621 = 3844350519262422248 -> C = Mod[D inv2, n] in Mathematica Just as a check: C r mod n = = (3844350519262422248 5772156649) mod 4153749073821763621 = 1189395596986402260 = D So we're OK. -> Mod[C r, n] in Mathematica So now Alice has x = 3141526535 and C = 3844350519262422248 4) Alice pays Bob by giving him (x, C) 5) Bob verifies that C = fx ^ (1/5) mod n. Or, he verifies that fx = C^5 mod n C^5 mod n = = 3844350519262422248 ^ 5 mod 4153749073821763621 = 2718281828 which does indeed equal f(3141526535) = 2718281828 where f is our hashing function. So Alice isn't cheating by sending a bogus (x, C) But Bob must also send (x, C) to the bank to verify Alice isn't trying to spend the money more than once! ---------------------------------------- So there it is, with numbers and Mathematica statements for those who have access to Mathematica. Hopefully, the numbers are large enough to convince people it didn't work out by chance. Now, the code to perform the math must be written, as well as the scripts to support the bank. Has anyone used the RSAREF routines, or should we stick to what's supplied with PGP? I haven't thought that far ahead. Like I said earlier, I'll pick up work on this in a few weeks. --- /-----------------------------------\ | Karl L. Barrus | | barrus@tree.egr.uh.edu (NeXTMail) | | elee9sf@menudo.uh.edu | \-----------------------------------/ From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eli Brandt Date: Wed, 2 Dec 92 21:57:33 PST To: cypherpunks@toad.com Subject: Re: Suggest splitting things up In-Reply-To: <9212030436.AA01770@edev0.TFS> Message-ID: <9212030557.AA06522@toad.com> MIME-Version: 1.0 Content-Type: text/plain > From: Peter Shipley > I suggest to groups be split as suggested but I will like to add > that it be donw [ a different way ] Before we consider splitting the list, we should ask whether there are a significant number of people who would take less than all of the sublists. I really don't know. If the purpose is just to provide a way to know what "kind" of message you're about to read, we could use a "tag" the way sci.v-w does, if we find this necessary. I personally don't object to this kind of list volume. > -Pete Eli ebrandt@jarthur.claremont.edu From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: peter honeyman Date: Wed, 2 Dec 92 19:29:35 PST To: cypherpunks@toad.com Subject: uh oh, o-o Message-ID: <9212030329.AA03885@toad.com> MIME-Version: 1.0 Content-Type: text/plain the following remarks were transcribed from today's live satellite broadcast from sun on object oriented technologies, hosted by john gage. in his introductory remarks, he said: I found something else that a number of you probably have read already, it's in a way relevant to this, about searching through large archives. This is John Gilmore, Sun employee number five. [Holding up to the camera last Saturday's NYT article.] This is John in his normal confrontational stance with the National Security Agency. John wanted two textbooks on cryptanalysis that were classified, then declassified briefly, then reclassified. Using good search techniques, using what Bob Kahn would call "knowledge robots" or "knowbots", objects searching for your bibliographic material on the net, John found them in a public library and that made the NSA very upset. For about three days there was a fight, this was in Saturday's New York Times, there was a fight until Tuesday of this week, yesterday, they declassified these books. So using object technology in some rough sense to pore through enormous amounts of information is a topic that may sound futuristic but it's very, very real, we think, and we'll talk about that. enjoy. peter From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: crunch@netcom.com (John Draper) Date: Wed, 2 Dec 92 22:38:55 PST To: tcmay@netcom.com Subject: Re: Suggest splitting things up Message-ID: <9212030638.AA03477@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain I recommend that we adopt Yim May's idea for how the mailing lists are split up. BTW, if that ever happens, I only want to me on the cypherpunks-technical, and cypherpunks-announce mailing lists. Cheers JD From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Fan Li TAI Date: Wed, 2 Dec 92 21:50:52 PST To: cypherpunks@toad.com Subject: enjoy enjoy Message-ID: <9212030550.AA06424@toad.com> MIME-Version: 1.0 Content-Type: text/plain Hiya, Below's something I found... I know you all have been swamped with mail... but this one is in the spirit of things, I think... Found it in Life... ____begin____ From: sherman@.cs.umbc.edu (Dr. Alan Sherman) Subject: Superpolylogarithmic Subexponential Functions Newsgroups: rec.music.dementia Announcing: Technical Report TRCS-91-17, University of Maryland Baltimore County. A preliminary version of this paper appeared in two parts in {\it SIGACT News}, {\bf 22}:1 (winter 1991), Whole Number~78, 65--73, and {\bf 22}:2 (spring 1991), Whole Number~79, 51--56. On Superpolylogarithmic Subexponential Functions Alan T. Sherman Computer Science Department University of Maryland Baltimore County Baltimore, Maryland 21228 and Institute for Advanced Computer Studies University of Maryland College Park College Park, Maryland 20742 June 21, 1990 (revised April 1, 1991) Abstract A superpolylogarithmic subexponential function is any function that asymptotically grows faster than any polynomial of any logarithm but slower than any exponential. We present a recently discovered nineteenth-century manuscript about these functions, which in part because of their applications in cryptology, have received considerable attention in contemporary computer science research. Attributed to the little-known yet highly-suspect composer/mathematician Maria Poopings, the manuscript can be sung to the tune of ``Supercalifragilisticexpialidocious'' from the musical Mary Poppins. In addition, we prove three ridiculous facts about superpolylogarithmic subexponential functions. Using novel extensions to the popular DTIME notation from complexity theory, we also define the complexity class SuperPolyLog/SubExp, which consists of all languages that can be accepted within deterministic superpolylogarithmic subexponential time. We show that this class is notationally intractable in the sense that it cannot be conveniently described using existing terminology. Surprisingly, there is some scientific value in our notational novelties; moreover, students may find this paper helpful in learning about growth rates, asymptotic notations, cryptology, and reversible computation. Keywords. Algorithms, asymptotic notation, complexity theory, cryptography, cryptology, DTIME, mathematical humor, Maria Poopings, Mary Poppins, musical computer science, reversible computation, Supercalifragilisticexpialidocious, superpolylogarithmic subexponential functions, SuperPolyLog/SubExp. --- lyrics --- Superpolylogarithmic Subexponential Functions (Sung to the tune of ``Supercalifragilisticexpialidocious.'') Um diddle diddle diddle, um diddle ay! Um diddle diddle diddle, um diddle ay! Superpolylogarithmic subexponential functions! Faster than a polylog but slower than exponential. Even though they're hard to say, they're truly quintessential. Superpolylogarithmic subexponential functions! Um diddle diddle diddle, um diddle ay! Um diddle diddle diddle, um diddle ay! For Alice to send a message through to Bob when Eve's eavesdropping, do use a trapdoor one-way function---not a one-key mapping. First take a message x, let's say, and raise it to the e; then mod it out by p times q but keep these secretly. Oh! (Chorus) Um diddle diddle diddle, um diddle ay! Um diddle diddle diddle, um diddle ay! The process takes but poly-time and appears to be secure: why even just a single bit is one over polylog pure. Though Alice thinks that Eve must spend time at least exponential, by using Lenstra's elliptic curves, Eve splits n subexponentially. Oh! (Chorus) Um diddle diddle diddle, um diddle ay! Um diddle diddle diddle, um diddle ay! we remove the heat with water but there's a better strategy. Since thermodynamics does not apply when info is not doomed, the laws of physics don't require that power be consumed. Oh! (Chorus) Um diddle diddle diddle, um diddle ay! Um diddle diddle diddle, um diddle ay! Now Bennett said in `73, to run a program P, you simulate the program P, but do so reversibly. The problem with this method is that space is exponential, so trade off time to save on space---this really is essential! Oh! (Chorus) Um diddle diddle diddle, um diddle ay! Um diddle diddle diddle, um diddle ay! Did you know if you invert one, you get a funtionential subexporithmic logapolyrepus? But that's quite a singularity! So, If you are in an oral exam and cannot find the way, just summon up these words and then you've got a lot to say. But better use them carefully or you could fail the test. A professor once asked me, ``What do you call functions that grow faster than any polylogarithm but slower than exponential?'' There're, Superpolylogarithmic subexponential functions! Superpolylogarithmic subexponential functions! Superpolylogarithmic subexponential functions! Superpolylogarithmic subexponential functions! --- end of lyrics --- Note: See paper for detailed performance notes and mathematical proofs by anagramming. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nobody@rebma.rebma.mn.org Date: Wed, 2 Dec 92 22:44:26 PST To: cypherpunks@toad.com Subject: No Subject Message-ID: MIME-Version: 1.0 Content-Type: text/plain Here's a new look for electronic cash. Instead of having a bank where people have accounts, have the "banker" be a money changer. He changes Federal Reserve Notes into crypto dollars. Anybody can send him dollars, and include an email address and public key, and he will email them that same amount of electronic cash. Anybody can email him electronic cash, and include a snail-mail address, and he will send them that same amount of U.S. dollars. You don't have a permanent relationship with him, you just use the service when you need to change between electronic and paper dollars. With the Chaum cash that was discussed here a while ago, where you need to "deposit" it right away when you get it, here's what you could do instead. Send it to the money changer, and ask for fresh crypto cash back. It's like you combined a "deposit" with an exactly equal "withdrawal". What you get back is good cash that you can hold or spend as needed. There are no account numbers involved, no demand deposits, no bank account at all. Eric Hughes mentioned demand deposits as defining a bank, so maybe this would be a way around that. -- Mr. Money -- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Mitra Date: Wed, 2 Dec 92 16:27:35 PST Subject: Re: Suggest splitting things up In-Reply-To: <9212022122.AA16492@netcom2.netcom.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain I've had this list gatewayed into a newsgroup locally since it started, as long as people are reasonably disciplined (what us, disciplined) about keeping the same subject line, then the volume of this list is quite managable. OTOH - there is no way I could have handled this volume in my regular mailbox. - Mitra -- Mitra mitra@pandora.sf.ca.us Technical Director, Pandora Systems (415)488-0944 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: "DrZaphod" Date: Thu, 3 Dec 92 07:38:03 PST To: cypherpunks@toad.com Subject: RE: digital banking, file formats, etc. Message-ID: <19286.drzaphod@ncselxsi> MIME-Version: 1.0 Content-Type: text/plain In Message Wed, 2 Dec 92 20:17:19 -0600, Karl L. Barrus writes: >1) Alice chooses x, r > Alice computes B = r^3 * f(x) mod n > Alice sends the following message to the bank via an anonymous >remailer > > :: > withdraw > > > Reply-To: > public key> > What happens if the bank mails $$$ to Alice. Somebody intprive Alice of HER money. I havn't read much about digital money protocols so correct me if I'm wrong. TTFN! DrZaphod [AC/DC] / [DnA][HP] [drzaphod@ncselxsi.uucp] Technicolorized From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nraizman@winchester.pp.psc.edu Date: Thu, 3 Dec 92 08:34:29 PST To: cypherpunks@toad.com Subject: Info Wanted Message-ID: <9212031629.AA08600@winchester.pp.psc.edu> MIME-Version: 1.0 Content-Type: text/plain Wiggidi-wiggidi-whassup? I'm new here, and , while I can follow the digital money threads, and otehr such things, I am lost when it comes to this PGP and Public Key stuff. Could someone please explain it to me? Thanx a lot! nraizman@winchester.pp.psc.edu From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: andrew_derry@sfu.ca Date: Thu, 3 Dec 92 12:07:53 PST To: cypherpunks@toad.com Subject: Re: digest (not splitting) Message-ID: <9212032007.AA24537@whistler.sfu.ca> MIME-Version: 1.0 Content-Type: text/plain Richard Childers says: >So do I, but a digest ( 225 / 4 == 56.25 messages per day, concatenated >into one giant digest of messages, sans headers ) would also make the >traffic manageable, while preserving the ability for the various groups >to benefit from one another's divergent, but relevant, insights into the >overall process and its possible applications. I'm for the digest format. Should make it much more managable. --- Andrew Derry | ACS@HCC - Simon Fraser University | Internet: derry@sfu.ca | From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: "DrZaphod" Date: Thu, 3 Dec 92 16:08:48 PST To: cypherpunks@toad.com Subject: Re: Suggest splitting things up Message-ID: <47824.drzaphod@ncselxsi> MIME-Version: 1.0 Content-Type: text/plain In Message Wed, 2 Dec 92 21:56:54 PST, Eli Brandt writes: > I personally don't object to this kind of list volume. Neither do I, just to cast my vote in the hat. In fact, I don't even think that we need to tag the messages for the type of content. I'm interested in anything that is posted in this list and read every message. TTFN! DrZaphod [AC/DC] / [DnA][HP] [drzaphod@ncselxsi.uucp] Technicolorized From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Karl L. Barrus Date: Thu, 3 Dec 92 11:21:49 PST To: ncselxsi!drzaphod@ncselxsi.netcom.com Subject: Re: digital banking, file formats, etc. In-Reply-To: <19286.drzaphod@ncselxsi> Message-ID: <9212031921.AA09706@tree.egr.uh.edu> MIME-Version: 1.0 Content-Type: text/plain Dr. Zaphod writes: >What happens if the bank mails $$$ to Alice. Somebody intprive >Alice of HER money. I haven't read much about digital money protocols >so correct me if I'm wrong. TTFN! Well, I intend for the communications themselves to encrypted as well. This would call for the remailing request to also somehow include Alice's public key, and Bob's communications to include his public key, etc. This will prevent intercepted mail from tampering and keep the anonimity. . Possibly the bank will have two public keys: one for money, and one for mail. However, in the initial phase to keep things simple, the messages won't be encrypted - only the remailing info will. This will implement the anonymous part, and allow transactions, but will provide no protection against intercepting mail, etc. Heck, the initial system will only allow withdrawals and deposits of a constant denomination, so I'll worry about spoofing later :-) I'm operating under the premise of getting something out that is usable but not full blown. So extra denominations, fully encrypted messages, etc. will be added later. Also, I received a mail from rjc@gnu.ai.mit.edu (Rob Crowley?) - whose mail I seem to have misplaced - voicing concern over proving deposits in the event that the bank can't be trusted. Any of the digital currency protocol articles discuss this issue? I guess I need to visit the library again and do some more research, after finals. /-----------------------------------\ | Karl L. Barrus | | barrus@tree.egr.uh.edu (NeXTMail) | | elee9sf@menudo.uh.edu | \-----------------------------------/ From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: ghsvax!hal@uunet.UU.NET (Hal Finney) Date: Thu, 3 Dec 92 18:36:43 PST To: cypherpunks@toad.com Subject: Re: digital banking Message-ID: <9212040022.AA15172@nano.noname> MIME-Version: 1.0 Content-Type: text/plain I enjoyed seeing Karl's walk-through of Chaum's digital cash algorithm. The numbers looked right. One point is that doing different denominations isn't that much harder, you just need to have more exponents. As you generate your primes p and q, make sure that p-1 and q-1 aren't divisible by any small primes (other than 2). This will ensure that phi = (p-1)(q-1) is not divisible by small primes, hence that gcd(e, phi) will be 1 for those same small primes, in fact for all the odd numbers. Karl also quoted a comment from Ray Cromwell expressing concern over proving deposits. Ideally you'd get a signed receipt from the bank for every deposit you make. In the case of electronic deposits, there exist protocols for "gradual secret exchange" that might be suitable for this purpose. What you'd like is to send the bank your deposit "gradually", while the bank simultaneously gradually sends you a digitally signed receipt. I don't recall the details of these protocols. Gradual exchange would not be very convenient for email because of the long turnaround times in mail systems, but if you had a better connection it might be useful, especially for large deposits. Another way to look at it is, what stops the local merchant from taking your payment, putting it in his pocket, and then denying that you've given him anything? It would just be his word against yours. One answer is, if he does that to multiple people, their multiple stories would have more credibility than his denials. Similarly, a bank which made a habit of cheating its customers would find itself publically exposed. So it may be reasonable to trust the bank for routine transactions. Hal 74076.1041@compuserve.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: fnerd@smds.com (FutureNerd Steve Witham) Date: Thu, 3 Dec 92 15:36:23 PST To: cypherpunks@toad.com Subject: understandable cypher software Message-ID: <9212032155.AB19933@smds.com> MIME-Version: 1.0 Content-Type: text/plain Folks-- A paragraph of philosophy and then some technical PGP questions. I should be able to verify with my own eyes how cypher technology works. Otherwise I'm trusting my security to somebody's black box. I should be able to write my own and test that it interacts with someone else's the way it's supposed to. I should be able to monitor the communications between my copy of a cypher product and some other, and verify that they're doing the things people say they are. Besides, I'd like to carry the crypto basics in my head "just in case." To these ends, I'd like cypher software that is as easy to read and understand and trust as possible. I'd like to start with a distilled PGP. Does this list cover the heart chambers of PGP? (Not to devalue the rest): RSA IDEA The signature algorithm (MD5?) 128 bits? Is that based on RSA? A cryptostrong pseudorandom # generator? Is this based on RSA? Something that takes keystroke delays (real, but not so good, random numbers) and makes real good random numbers? Is this based on RSA? A data compression algorithm (some variation of LZW?) A binary<-->ascii translator RSA seems to depend on doing modulo-multiply on big integers. What are the relative speeds of the different modmults in PGP (modulo processor speed)... the simplest C version the fastest C version the fastest assembler version on the processor where it matters least the fastest assembler version on the processor where it matters most? Given the time to do modmult, couldn't all the rest (including modexp) be done in an interpreter that had big ints and modmult as a primitive? What's the formula for RSA again? out = in * something ^ somethingelse mod yetanother?? I know it can't be, because the key is only one number. What is/are the basic primitive(s) for IDEA? -fnerd "Computer software must not only work, it must also appear to work." --Carl Hewitt fnerd@smds.com (FutureNerd Steve Witham) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Thu, 3 Dec 92 18:31:36 PST To: cypherpunks@toad.com Subject: FTP site Message-ID: <9212040228.AA26580@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain We have an anonymous FTP site. It's at soda.berkeley.edu. The directory is pub/cypherpunks. Right now there's not much in it. A few miscellaneous documents are in the misc/ directory. There's an empty directory for listings of ftp sites in other places that hold crypto software of various forms. But most importantly the source code to the remailer as currently running is in there. I'd like to see even more remailers than three. And if you can't put up a remailer (because, to take one of the few good examples, you don't run Unix) I'd still like people to study the code. We'll eventually have weekly digests of mail traffic from the list, but those aren't created yet. Enjoy! Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hughes Date: Thu, 3 Dec 92 18:35:51 PST To: cypherpunks@toad.com Subject: Suggest splitting things up Message-ID: <9212040235.AA27065@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain A word on the subject of altering the list from the list maintainer. There's been lots of discussion about splitting up the list into various pieces. In a word, it's not going to happen. Look, this is the cypherpunks list. Cypherpunks write code. A corollary to this is that cypherpunks take responsibility for the volume of mail they receive. If you're getting too much mail, use a filter. Many of you may not know that the remailer software as currently configured pressed into service just such a filter. In the just-announced ftp site, there's the source code, in perl, to just such a filter. You can change it to do whatever you like. In particular, you can install it to filter all your cypherpunks mail to a separate mailbox, file, or subdirectory. You can also use MH, whose slocal the above perl filter was based on. slocal can filter all of your cypherpunks mail to separate places. You can also send all of your cypherpunks mail to a separate directory and use a newsreader to read it. I've never done this, but certain list members have. If one of them (say, Mitra, who recently mentioned that he does this) would post a short summary of how it's done to the list and offer to answer questions off-line, I'd appreciate it. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: "Mark W. Eichin" Date: Thu, 3 Dec 92 15:53:18 PST To: fnerd@smds.com Subject: re: understandable cypher software In-Reply-To: <9212032155.AB19933@smds.com> Message-ID: <9212032352.AA02808@tweedledumber.cygnus.com> MIME-Version: 1.0 Content-Type: text/plain >> RSA seems to depend on doing modulo-multiply on big integers. What are the >> relative speeds of the different modmults in PGP (modulo processor speed)... Also consider reliability. As of 2.0, modmult on the SPARC (using the MERRITT code) fails on some keys, while either the PEASANT or UPTON routines function correctly but are slower. (I haven't had time to test them in parallel and find where they diverge, but there is a large keyring "out there" that breaks the MERRITT code in several places...) (on the main thread, yes, understanding "the whole thing" is a good idea, and perhaps modifying the code to make this easier is a useful development goal...) _Mark_ From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: cordones@IMAGE.CS.NYU.EDU (Deus Ex Machina) Date: Thu, 3 Dec 92 16:29:18 PST To: cypherpunks@toad.com Subject: Brand-spanking new key Message-ID: <9212040026.AA29192@IMAGE.CS.NYU.EDU> MIME-Version: 1.0 Content-Type: text/plain Hello everyone. I just finished installing PGP2.0 in a rush...so..here goes my 1024-bit Military grade (he..guess I am a little paranoid..) key. Give it a try and perhaps I will experience some ESP... -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAisdxzYAAAEEALaDepo7QeCT2MCu+02nGuAZIJtoRwbxlwulUT/SehKH7xFW 43UqHZKHwMjDT5S8TESpGLtanhKsgmGa+Pp1X/tEImS2CqEvnPQhy0mjQMqR1WZ7 NfKenvUesXkE6pTpg/8Fk1AwsqRiypUEHoiNeU4k14gceilSg2Z/lrxl5FyxAAUR tCNFbCBab3JybyA8Y29yZG9uZXNAcm9ib2NvcC5ueXUuZWR1Pg== =o+Oh -----END PGP PUBLIC KEY BLOCK----- so..have phun... El Zorro From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Fri, 4 Dec 92 03:10:36 PST To: cypherpunks@toad.com Subject: Re: enjoy enjoy Message-ID: <199212041109.AA24355@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Great one...! When I was taking undergrad social science stats, I came up with a similar one, just one verse though... Pearson-product-moment-correlation coefficients! If you still can't get it then you're mentally deficient Is this really learning or selection by attrition? Pearson-product-moment-correlation coefficients! -gg From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Mitra Date: Thu, 3 Dec 92 19:36:42 PST Subject: Re: Suggest splitting things up In-Reply-To: <9212040235.AA27065@soda.berkeley.edu> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Sure Eric, I'm on SCO unix (i.e. non compatible with everyone else - I cant even get perl running yet), I've added the following lines to my .maildelivery To cypherpunks@toad.com | A inews -0 -a list -n list.cypherpunks Cc cypherpunks@toad.com | A inews -0 -a list -n list.cypherpunks Apparently-To cypherpunks@toad.com | A inews -0 -a list -n list.cypherpunks This catches the three most common address headers, unfortunately the mailing list at cypherpunks doesnt behave like a well-behaved reflecter should and put its own address in the header (most would add "Sender: cypherpunks@toad.com") All this does is pipe messages that match the headers into inews with the args following. Those args are: -0 An extension I added, which makes inews always return 0 (otherwise our braindead delivery agent "mmdf" cycles forever trying to deliver bad messages and creating a HUGE dead.article. -a list Add an "Approved: list" line so that inews will post it to a moderated newsgroup -n list.cypherpunks Stick it in the newsgroup "list.cypherpunks" list.cypherpunks is set up moderated, with the moderater being cypherpunks@toad.com Happy gatewaying, if someone has a better way of doing this then let me know. - Mitra -- Mitra mitra@pandora.sf.ca.us Technical Director, Pandora Systems (415)488-0944 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: ghsvax!hal@uunet.UU.NET (Hal Finney) Date: Fri, 4 Dec 92 09:55:49 PST To: cypherpunks@toad.com Subject: PGP questions Message-ID: <9212041752.AA17033@nano.noname> MIME-Version: 1.0 Content-Type: text/plain It's probably good to discuss how PGP works here, for educational purposes, but I would expect people to get the source code if they really are interested. I can give some pointers here to answers to some of the questions people have asked. Steve Witham asks several questions. I think the crypto glossary which Tim posted a couple of weeks ago tells how RSA works, so I won't reiterate that here. Steve, if you didn't get it, maybe Tim could send it to you. PGP's signature algorithm creates an MD5 message digest of the message, then signs that digest by raising it to the secret exponent "d", mod "n". MD5 is a public-domain message digest algorithm created by RSA Data Security, Inc, which breaks messages into blocks of 64 bytes as input and produces a 16-byte (128-bit) digest. PGP then pads this 16-byte number to be about the size of n, and does the exponentiation. PGP does not do its decryption/signature exponentiation by actually raising the number to the power of d mod n, but by doing a mathematically equivalent operation involving two exponentiations, one mod p and one mod q. Since p and q are half the length of n, and exponentiation takes roughly the third power of the number of bits in the modulus, this reduces the amount of time by a factor of 4. The random number generator has several different modes, and I can only suggest looking at random.c. The data-compression algorithm is not really relevant but is based on zip. The binary-ascii translator is also not important but is a variant on the PEM standard. Steve asks a lot of questions about the speed of different versions. Maybe asking on alt.security.pgp would produce some representative values. I'm not sure whether anyone has a database with all these numbers. I understand that PGP 2.1 may have a faster version of the Upton modmult. Preliminary timings suggest that it's still slightly slower than the Merritt modmult on the Sparc, but if Merritt really is unreliable (I haven't heard about this) then switching to Upton will not involve much of a penalty. PGP is very fast on Sparcs anyway and I don't think making it 10% slower would matter. Profiling indicates that yes, during the RSA encryption phase, most of the time is spent in modmult. An interpreter could be built to do a modular exponentiation using a C implementation of modmult and it would be about as fast. However, that still leaves the generation of the random session key, padding it with random numbers so that it is suitable for RSA operations, converting the RSA-encrypted session key into a format suitable for writing to a file, doing the IDEA encryption, wrapping this all up with control information so that it can be decrypted, looking up key information from a key ring file or some other data file (possibly decrypting it on the fly), converting to ASCII, etc. All these are part of an encryption/decryption cycle and can't really be skipped. Hal 74076.1041@compuserve.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: ghsvax!hal@uunet.UU.NET (Hal Finney) Date: Fri, 4 Dec 92 10:03:39 PST To: cypherpunks@toad.com Subject: Re: Weakness of the PGP scheme ? Message-ID: <9212041755.AA17036@nano.noname> MIME-Version: 1.0 Content-Type: text/plain Vanguard@gribb.hsr.no asks about trying all the IDEA keys. If you will look in idea.h you will see that the IDEA key is 16 bytes long, which is 128 bits. This is long enough to make trying them all impossible. Trying to predict one IDEA key by knowing the previous one also looks hard, as PGP basically cycles IDEA on random input and takes the output as the keys. If you could predict this output it would be similar to breaking IDEA. On the other hand, PGP normally keeps its random information in a small file called randseed.bin. It uses the contents of this file plus the current time of day in seconds as the input to generate the IDEA key. If you stole this file from someone (it's not cryptographically protected, unlike the secret key ring), and you know within several hours or a day when he sent each message, you could probably calculate all possible IDEA keys in a feasible amount of time (by trying all plausible values for the time of day in seconds). This would also let you calculate the new contents of the randseed.bin file. As long as you didn't miss any messages he sent, you could keep doing this and break all of his outgoing messages. You can prevent this by removing your randseed.bin file and substituting an empty file (or one that is less than 16 bytes long) in its place. This will cause PGP to prompt you for random keyboard input each time you send a message, which would make it impossible for the attack above to work. It would mean less convenience, though. The relevant routines are make_random_ideakey() and strong_pseudorandom() in crypto.c, as well as the code in random.c. Hal 74076.1041@compuserv.ecom From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: edgar@spectrx.Saigon.COM (Edgar W. Swank) Date: Sat, 5 Dec 92 14:51:16 PST To: Cypherpunks Subject: First digital money? Message-ID: <5Ps0uB3w165w@spectrx.saigon.com> MIME-Version: 1.0 Content-Type: text/plain Following cross-posted from Extropians: To: gnu.ai.mit.edu!Extropians Date: 02 Dec 92 11:31:59 EST From: Duncan Frissell Subject: If I only had $100K Bankers Trust has started a Global Settlement Fund to allow securities traders to make free funds transfers 24 hours a day. The Chicago Mercantile Exchange now accepts GSF shares in addition to cash and T-bills for settlement purposes. GSF shares will pay interest and there are no transactions charges for transfers. For now, the account minimum is $100,000 and participating institutions must have a link to Bankers Trust's New York operations center. The company plans to open similar funds denominated in Yen and Pounds Sterling. It also plans a BBS system which will allow traders to arrange forex exchanges with the holders of other currency shares 24 hours a day. Bankers Trust has targeted the Fed Wire that does 60 million transactions worth $200 billion a year but is slow and expensive. Now once such a system reaches the *retail* level we'll really have something. Duncan Frissell ******************************************************************************* * DUNCAN FRISSELL Attorney at Law, Writer, and Privacy * * CIS 76630,3577 Consultant since the Nixon * * Internet 76630.3577@compuserve.com Administration * * Easylink 62853962 * * Attmail !dfrissell * * TLX: 402231 FRISSELL NYK * * * * * Clinton Inaugural Sale - Any Question Answered for $9.99 * * * * ******************************************************************************* -- edgar@spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: miron@extropia.wimsey.com (Miron Cuperman) Date: Fri, 4 Dec 92 03:39:29 PST To: cypherpunks@toad.com Subject: Chosen cryptotext and RSA Message-ID: <1992Dec4.102619.25216@extropia.wimsey.bc.ca> MIME-Version: 1.0 Content-Type: text/plain Can chosen crypto-text break RSA? (I.e., having access to the decryption machine - as a black box and finding the decryption exponent.) -- Miron Cuperman | NeXTmail/mime ok | Public key avail AMIX: MCuperman | cybercomputingimmortallaissezfaire | From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Karl L. Barrus Date: Fri, 4 Dec 92 10:02:46 PST To: cypherpunks@toad.com Subject: No Subject Message-ID: <9212041802.AA13345@tree.egr.uh.edu> MIME-Version: 1.0 Content-Type: text/plain FutureNerd Steve Witham writes: >I should be able to verify with my own eyes how cypher technology works. >Otherwise I'm trusting my security to somebody's black box. This is important, which is why its nice to have source code. However, be prepared to invest a little :-) time in the study of PGP's code; I recently printed it out and must have sucked a toner cartridge nearly dry as it took more than 500 pages! Check out 'wc -l *.[ch]' which results in 22720 lines for me. > The signature algorithm (MD5?) > 128 bits? > Is that based on RSA? Get the md5.doc from rsa.com - available via anonymous ftp. It explains the algorithm (which is largely bitwise operations on blocks of the input stream) and even includes source code. > A cryptostrong pseudorandom # generator? > Is this based on RSA? Somebody posted a cryptographically strong prng to sci.crypt recently, but I haven't had a chance to look it over. I have my own rng - a ten sided die, which I haven't had occasion to use, yet. > A binary<-->ascii translator Phil Karn's DES package includes source code for uuencode, which performs this translation. I'm sure it is somewhere in the PGP code as well. There is also RFC 1113. >What's the formula for RSA again? > out = in * something ^ somethingelse mod yetanother?? > I know it can't be, because the key is only one number. Close! That looks like the formula for solving ax mod n = d for x given a, n, d. RSA: pick two primes p and q. Then n=pq. As Hal Finney said, the two primes should be "good" in the sense that p-1 and q-1 have no small prime factors. Obviously, you can't avoid having 2 divide p-1 and q-1, but that should be about it. Also, p and q should differ in length by a few digits otherwise an enemy may begin to try factoring n by starting near sqrt(n). Pick a decryption exponent d. d and phi(n) should be relatively prime, where phi(x) = Euler totient function = # of numbers less than x which are relatively prime to x = x-1 for x prime. For n, phi(n) = (p-1)(q-1). Calculate the inverse of d mod phi(n) and call it e, your encryption exponent (e = d^(-1) mod phi(n)). Publish n and e as your public info, and keep d secret as your decryption key. Somebody encrypts a message by calculating M^e mod n. You decrypt the ciphertext by calculating C^d mod n. For example: p=7, q=11 => n=77 and phi(n)=60. I pick d=13, gcd(13,60) = 1 so it is acceptable. Then e = 13^(-1) mod 60 = 37. Check: 13 37 mod 60 = 1. A message M=20 is encrypted as 20^37 mod 77 = 48. I decrypted the ciphertext 48 like this: 48^13 mod 77 = 20, and I got back the original message. /-----------------------------------\ | Karl L. Barrus | | barrus@tree.egr.uh.edu (NeXTMail) | | elee9sf@menudo.uh.edu | \-----------------------------------/ From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Fri, 4 Dec 92 09:43:36 PST To: VANGUARD@gribb.hsr.no Subject: Weakness of the PGP scheme ? In-Reply-To: Message-ID: <9212041720.AA05323@newsu.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: VANGUARD@gribb.hsr.no >The underlying security of the PGP scheme is based on two different >systems, the RSA asymetric cipher and the IDEA cipher. For standard >encryption the plaintext is encrypted with a IDEA using a "random" >key, then the key is communicated using RSA. Then we have two direct >ways of analysing a message, we might have a run a plaintext attack >on the ciphertext trying out all possible IDEA keys which will tak >a lot of effort, or we might break the RSA key to get the IDEA key. >But I propose an easier attack; Using a Encrypted Ciphertext together >with the public key used for encryption, It would be possible to run >a trial encrypting all possible IDEA keys using the RSA public key >and compare it with the encrypted IDEA key, if a match is found then >you have the IDEA key for this one message. Using an RSA chip that is >capable of performing exponetsiations VERY fast I dont think that >this would be unfeasable. This is quite wrong. This only makes sense if RSA were inherently much faster than IDEA. In fact, IDEA is orders of magnitude slower than RSA; thats the whole reason that we use IDEA session keys encrypted with RSA and not RSA itself to encrypt the message -- RSA is way too slow. The result of this is that trying all possible IDEA keys directly to break the cypher is far far faster than trying to encrypt all possible IDEA keys with RSA. Now, since the security of IDEA depends on it being secure from brute force attacks like trying all possible IDEA keys and seeing which one produces a good message, the result is that if IDEA is secure, PGP is certainly secure from the attack you mention. >The most important factor in this attack is the length of the IDEA >key. But another concern is the generation of the IDEA key, is it >possible knowing the value of the RANDSEED to know all the subsequent >IDEA keys?, or would knowing the last IDEA key drastically reduce the >time needed to search for a subsequent one? If the random number generator is good, then it should not be possible to predict the next session key. If it is bad, all bets are off. I would agree that questions of the quality of the RNG have been inadequitely explored. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Fri, 4 Dec 92 13:23:43 PST To: cypherpunks@toad.com Subject: Sources of Crypto Information In-Reply-To: <9212040228.AA26580@soda.berkeley.edu> Message-ID: <9212042123.AA12247@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Cypherspace Residents, Several people have asked about what PGP is, how RSA works, what digital cash is all about, etc. I'll recap where and how these questions can be answered. 1. Long term, there will be a FAQ, to be coordinated by Hugh Daniel, who recently posted about this. 2. I posted or mentioned the following items to this list very recently: - Crypto Glossary (which explains, albeit briefly, RSA, digital cash, DC-Nets, PGP, etc.). This has been also been submitted for the anonymous ftp site (at soda.berkeley.edu in pub/cypherpunks). - Larry Loen's crypto FAQ he posted to sci.crypt recently. This was also submitted for the ftp site. 3. The documentation for PGP has a good discussion of the issues, how the IDEA cipher works, etc. Read this, please, before asking the entire list how RSA works. 4. "Cypherpunks read crypto books" is my variant of Eric's "Cypherpunks write code." (No point in trying to write code if you don't have any idea what you're doing.) I've described many excellent books and articles. Almost any recent book will give you an excellent list of other books. 5. Hal Finney and Karl Barrus have both written excellent summaries of how digital cash works. Work through their examples! (A personal note: I'm blissfully PERL-illiterate, but I use Mathematica on my Mac, so Karl's examples in Mathematica overjoyed me!) 6. Several weeks ago I posted some articles on the dining cryptographers protocol, as Hal also did. I can send these to anyone who wasn't on the list then. (Ditto for the Crypto Glossary.) 7. Sci.crypt is worth reading, especially if you have a good newsreader like "tin" which allows interesting threads to be quickly identified. Hope this helps. --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: VANGUARD@gribb.hsr.no Date: Fri, 4 Dec 92 06:18:02 PST To: cypherpunks@toad.com Subject: Weakness of the PGP scheme ? Message-ID: MIME-Version: 1.0 Content-Type: text/plain To my knowledge there is done very little cryptographical anlysis on the PGP protocol, and just recently I saw I possible weak point in the PGP scheme. The underlying security of the PGP scheme is based on two different systems, the RSA asymetric cipher and the IDEA cipher. For standard encryption the plaintext is encrypted with a IDEA using a "random" key, then the key is communicated using RSA. Then we have two direct ways of analysing a message, we might have a run a plaintext attack on the ciphertext trying out all possible IDEA keys which will tak a lot of effort, or we might break the RSA key to get the IDEA key. But I propose an easier attack; Using a Encrypted Ciphertext together with the public key used for encryption, It would be possible to run a trial encrypting all possible IDEA keys using the RSA public key and compare it with the encrypted IDEA key, if a match is found then you have the IDEA key for this one message. Using an RSA chip that is capable of performing exponetsiations VERY fast I dont think that this would be unfeasable. The most important factor in this attack is the length of the IDEA key. But another concern is the generation of the IDEA key, is it possible knowing the value of the RANDSEED to know all the subsequent IDEA keys?, or would knowing the last IDEA key drastically reduce the time needed to search for a subsequent one? So far I haven't studied PGP enough to answer all these questions. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: norm@netcom.com (Norman Hardy) Date: Fri, 4 Dec 92 15:51:08 PST To: cypherpunks@toad.com Subject: Re: digital banking Message-ID: <9212042350.AA21011@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain As I understand Chaum's Digi-Cash scheme the bank customer is protected both against bank fraud and merchant fraud but not against collusion between the two. The customer need not be unknown to the bank in order that her purchases with bank notes be unknown to the bank. This is where blind bank signatures come in. Neither need the merchant be unknown to the bank. Remailers are unnecessary to hide connection between the merchant and his customers. The bank knows both but has no way to associate them. This being the case, the bank customer is protected against a false denial of deposit. When one deposits Digi-Cash in a bank he presumably waits for an indication from the bank that the cash was still valid (not previously deposited). The customer retains this indication as a receipt which is signed by a private bank key. A bank's positive reputation is useful but not necessary at this point. Another concern is the false denial of payment by the merchant. If the merchant's customer is willing to reveal to a judge that she paid the merchant, and she retained the note with which she paid, and the bank retains a record of the merchant's deposits then she can argue that it was she that caused the bank to mint the note since only the person for whom the note was minted and the merchant who had cashed it (and the bank) should know its bits. This would require that the bank respond to the judicial query "has bank customer M deposited note x?". From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hollander Date: Fri, 4 Dec 92 17:04:59 PST To: cypherpunks@toad.com Subject: usenix Message-ID: <9212050104.AA18056@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain A list for discussion of the crypto-bus to usenix has been formed. To join, send mail to usenix-crypto-bus-driver@soda.berkeley.edu. e From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nobody@cs.Buffalo.EDU Date: Fri, 4 Dec 92 17:32:06 PST To: cypherpunks@toad.com Subject: Another remailer Message-ID: <9212042350.AA10597@armstrong.cs.Buffalo.EDU> MIME-Version: 1.0 Content-Type: text/plain I have set up another reamiler... the address is babani@cs.buffalo.edu Be warned: There is no PGP ability as of yet. Let me emphisize that: THERE IS NO PGP ABILITY ON THIS REMAILER. I have not gotten the pgp program up and running as of yet. But... if you want to bounce mail through the remailer... it shouldn't be to much of a problem. Just use one of the other remailer keys and encrypt your message with that. Just add the usual lines to your message. For example: ----Begin fake message to a remailer---- :: Request-Remailing-To: remailer@rebma.mn.org --------BEGIN PGPv2.0 MESSAGE------ (endcoded with rebma's key) blah blah --------END PGPv2.0 MESSAGE------- ----End fake message to a remailer------ Report any problems to me or to any of the other remailing sites. -- +==== Internet: babani@cs.buffalo.edu ===+======== Amateur-Radio: N2LYC ======+ ! Bitnet: V078LNGT@ubvms.BITNET | UUCP: rutgers!ub!babani ! ! Alternate: an173@cleveland.freenet.edu | Plsure dpnds on the othrs prmison. ! +When you finally discover all of lifes answers, they'll change the questions.+ From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: fnerd@smds.com (FutureNerd Steve Witham) Date: Fri, 4 Dec 92 17:46:33 PST To: cypherpunks@toad.com Subject: getting .hqx files with ftpmail Message-ID: <9212050131.AB05869@smds.com> MIME-Version: 1.0 Content-Type: text/plain A note for fools like me trying to get Mac .hqx files through "ftpmail"... USE ASCII MODE! Otherwise it defaults to adding an extra layer of "btoa" encoding on the file (or you can switch it to uuencode, but why uuencode an .hqx file--it's already plain text). "btoa" files start like this: xbtoa begin wef9a87eg8a9wery8s7arg87gae8g7waeo87rwe8r(garbage)... as opposed to uuencoded files like: begin fred.txt aewhgp9ergu90ser890syuer98gse98r(garbage)... or .hqx files (this is from memory): (This file has to be decoded with BinHex 2.0) k9wegesz9p8rgy89serg9oser98ser98(garbage)... I don't know where to find "btoa," and ftpmail's help message just says to ask my local wizard. He never heard of it. --- Example request to ftpmail --- connect mac.archive.umich.edu cd mac/util/encryption ascii get macpgp2.0.sit.hqx -fnerd fnerd@smds.com (FutureNerd Steve Witham) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Joe Thomas Date: Sat, 5 Dec 92 14:51:18 PST To: cypherpunks Subject: Hardware RNGs Message-ID: MIME-Version: 1.0 Content-Type: text/plain I just joined the list (rather loudly, I'm afraid), but I've already seen several writers complain about the quality of RNGs and PRNGs for the purposes of cryptography. PGP stores up keystroke-derived random bits in a file, which has been pointed out as a possible security hole. But requiring random keystrokes every time one wishes to send a message seems an inconvenient tradeoff, to say the least. Someone posted a plan for a Zener diode-based hard RNG on sci.crypt a few weeks ago. I'm not much of a solderer normally, but this seems like a good idea if anyone out there has tried it out and tested the output for nonrandomness. (Of course, ideally we'll have alpha-decay-based RNGs --guaranteed random by the laws of physics-- but I'll settle for thermal noise on the cheap for the moment). Anyone tried these yet? More to the point, does anyone have some code patches for PGP to use a hard RNG preferentially over other random bitstreams? (Yeah, it would be pretty easy, but there's no sense in duplicating effort if we could get something standardized, pretty and portable agreed on.) Joe P.S. Sorry about the wasted bandwidth last week. My fingers were moving faster than my brain, but I should have recognized this address as a probable mailing list. Thanks to all who politely directed me to the -request address. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nobody@soda.berkeley.edu Date: Sat, 5 Dec 92 14:50:36 PST To: cypherpunks@toad.com Subject: test Message-ID: <9212052203.AA19366@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain This is a test of my new anon-remailer based on Hal's code. It does not yet feature pgp (pgp is having a hard time compiling on soda, but that will change soon...) To use it, just use the Anon-To: field in the header and mail to hh@soda.berkeley.edu There will soon be an even fancier remailer at soda (and not running out of my account). Details as they become available. sincerely, nobody From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: ghsvax!hal@uunet.UU.NET (Hal Finney) Date: Sat, 5 Dec 92 17:25:29 PST To: cypherpunks@toad.com Subject: Anonymous address problems Message-ID: <9212060122.AA19491@nano.noname> MIME-Version: 1.0 Content-Type: text/plain We've had some discussion of anonymous addressing, which allows someone to post an address at which mail can be sent to them without people being able to find out exactly who they are. I showed how the current remailers could, somewhat clumsily, allow anonymous addresses. The problem is, with a single-remailer anonymous address that remailer sees whom each anonymous address corresponds to, so you have to trust it. Now that other encrypting remailers are up it's possible to have anonymous addresses which go through more than one remailer before going to the final destination. This, I thought, would provide a more secure address since a whole group of remailers would have to be "broken" in order for someone to find out where a given anonymous address leads. However, with the current implementation, there is a security weakness. Whomever owns the last remailer in the chain for your anonymous address can find out who you are. They do this simply by sending an anonymous message with known contents, like "test number 1598293". They then watch all messages going through their remailer, looking for one whose contents match what they sent. If they are the last remailer in the chain, when they see this message go through them, they can look at whom it is being sent to, and so they then know your true name. So, a multi-remailer anonymous address is really no more secure than a single-remailer one. Chaum, in his "mix" paper, avoided this problem by having the anonymous addresses include a random number which each remailer sees as it decrypts the incoming message. (There is always such a number, it turns out, for the RSA encryption to be secure.) He had the mix, as it passes the message through, encrypt the contents with a single-key algorithm (like DES) using this random number as the key. This way the message is transformed at each step and so if it later comes back through the same mix, it won't be recognizeable as the one it sent earlier. So the attack above fails. For this to work, the user has to save the random numbers that were used to construct his anonymous address, and decrypt the message using DES with these as keys before going on to read it or public-key decrypt it as usual. This would be quite a bit less convenient. Chaum goes on to say that these return addresses can only be used once. I was a little puzzled by the exact attack that he is trying to defend against in applying this rule. Chaum doesn't always make the attacks clear, leaving that as an exercise for the reader. I believe the problem is that, say, the last remailer in the chain could send 100 messages to a given anonymous address (all would have different contents). Then, after working its way through the remailer chain, it would see 100 messages going to the same final destination. It could guess that those 100 were the 100 it sent, especially if it repeats this test every few days with different numbers. Chaum's rule of allowing each anonymous address to be used only once makes them much less useful. These complications just go to show that real security doesn't come easy or cheap. There is still work to be done before we achieve the goal of crypto anonymity. Hal 74076.1041@compuserve.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nobody@soda.berkeley.edu Date: Sat, 5 Dec 92 19:21:20 PST To: cypherpunks@toad.com Subject: remailers Message-ID: <9212060320.AA03303@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Remailers are proliferating! Several more will be coming on line soon! Two thoughts: Remailers should keep a directory of other remailers, along with their keys. They should, at random intervals, send messages to other remailers, selected at random. They should have a field like Purpose: traffic-analysis If a remailer on this "ring" sees this field, it will have, say, a 90% chance of remailing to another remailer in the ring, again, encrypted and with the traffic-analsysis field. This will cause a certain amount of random traffic between remailers. A traffic-analysis message could bounce around many times before finally ending up in the great /dev/null. We need two other things: overseas remailers (for those of us who live under US law). Domestic (US) remailers could have their archives searched with a searchwarant. However, if your mail has gone accross the oceans a few times, it would be pretty much impossible to get the neccessary warrants and cooperation in all the countries its been through. I'll set up a European remailer if someone else will. The other thing we need to do is make a list of remailers and their keys and put it up for ftp on soda.berkeley.edu in ~ftp/pub/cypherpunks. In fact, there could be an automatic service, whereby remailers automatically send mail to a remailer at soda, listed their keys and protocols, and the soda remailer automatically updates a remailer directory. e From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: habs@acf3.NYU.EDU (Harry A. B. Shapiro) Date: Sat, 5 Dec 92 19:27:02 PST To: cypherpunks@toad.com Subject: subscribe me Message-ID: <9212060326.AA04183@acf3.NYU.EDU> MIME-Version: 1.0 Content-Type: text/plain subscribe me -- habs@acf3.NYU.EDU habs@gnu.ai.mit.edu habs@well.sf.ca.us habs@panix.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nobody@soda.berkeley.edu Date: Sun, 6 Dec 92 10:30:31 PST To: cypherpunks@toad.com Subject: this is a test Message-ID: <9212061829.AA03378@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain igonore this message... e From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nobody@soda.berkeley.edu Date: Sun, 6 Dec 92 12:44:52 PST To: cypherpunks@toad.com Subject: No Subject Message-ID: <9212062044.AA06744@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Cypherpunks! Like several people (I guess), I am working on an implementation of digital cash. Because of the possible legal repurcussions, I'd prefer to remain anonymous at this time. Thanks to the efforts of the people on this list, this is now possible. My implementation is pretty far along. It uses PGP modules for the arithmetic, so the speed is good. It works on Unix and I should be able to get it working on MSDOS in a day or two. Sorry, I don't have the ability to work on a Mac version. Here are some of the features. The basic cash algorithm is the Chaum system which was posted here. Multiple denominations are supported, using different exponents for each denomination. The program is presented in the context of a package to be used for an email based game like Monopoly where the program would be used to allow cash transfers. One player is the "banker", and he uses a different execution module than the other players. The banker program keeps a database of used note numbers which is used to detect money reuse. The database is maintained using a freeware version of the "dbm" package, so it should be fast even for large note number databases. The mapping between exponents and values is as follows: exponent value 17 1 19 2 23 5 29 10 31 20 37 50 41 100 43 200 47 500 53 1000 59 2000 61 5000 67 10000 and so on, up to a value of 2e9. The exponents are ascending primes starting with 17. This was chosen because you want them to be smallish for fast note checking, but it was too slow to find primes p and q for the bank key such that (p-1)(q-1) was not divisible by any small primes. The program chooses random p and then tests p-1 to make sure it passes the divisibility test, and rejects it if not. Too many were being rejected when I started with an exponent of 3. Starting with 17 rejects about 1/2 the exponents, compared to something like 80% when I started with 3. The "value" fields are presumed to be cents, but could be whatever you like. The code I've written does not do anything other than the basic electronic cash algorithms. It does not do bank account maintenance. It doesn't do PGP encryption. It doesn't send mail. (It does have some functions to scan and check the files created by the program.) Cash generation is a 3 step process. First, the user creates what I call a "withdrawal request" packet. This is a set of triplets of the form (e, s, refx), where e is the exponent from the table above, s is a 16-byte "unique identifier" used solely to link these withdrawal requests with the returned messages from the bank, and refx is r^e * f(x). f(x) is MD5 of x, padded to the size of the bank's modulus n using the PGP routine which pads MD5 signatures. This padding helps make sure the arithmetic is more "mixing". x is the random input to MD5, which I've chosen as 64 bytes since that is the block size MD5 works on. (The output of MD5 is 16 bytes.) r is the blinding factor. This is now 128 bits long; longer r's take too long to calculate r^-1 in the third step, below. (It takes longer for PGP to calculate r^-1 than to do an RSA decryption, for r = n = 1024 bits!) Second, the bank program converts the withdrawal request packet into what I call a "withdrawal" packet, by just RSA-decrypting the third entry using the inverse exponent "d" for the value exponent "e". (These "d" values are calculated at keygen time and stored with the bank's key information in a private file.) I call the return triplet (e, s, rfxd), where e is the value exponent again, s is the same unique identifier, and rfxd is r * f(x)^d. (As I said above, the code I've written does not try to maintain account balances or do any other banking functions. It just does the cash algorithms. There is a routine to scan a withdrawal request and return the total value being requested for withdrawal. The idea was that this could be used as input to a banking program to decide whether to allow the withdrawal.) Third, the "player" (e.g. user) program transforms the withdrawal packet into a "money" packet, by un-blinding it. To do this, it has to recover the x and r which correspond with each triplet. This is done by the use of a dbm database of "pending withdrawal requests" which is written during step 1, above. The database entries are keyed by (e, s) and return the corresponding (x, r) which were generated during step 1. Using x and r, the user transforms (e, s, rfxd) into (e, x, fxd), the digital cash. e is the value exponent, x is the random 64-byte number, and fxd is f(x)^d, the signed version of the MD5'd and padded x. There are also player functions to scan and check a money file (comparing a calculated f(x) to fxd^e), merge money files, and extract some items from a money file into another money file (this last is what is to be used for payment). There are banker functions to check incoming money and compare against the used-note database, and to add incoming money to that database. (The database consists of the 16-byte f(x) values for each note.) I am pretty happy with the basic routines, but the user interface needs work. There are three kinds of files floating around (withdrawal requests, withdrawals, and money files) and I'm worried that this will be confusing to the user. If he accidentally deletes one at the wrong time he could lose money permanently. Or if he accidentally reuses one he could be accused of fraud. I'm not sure what the best model is for the user. The specific issues of creating withdrawal messages and extracting "bills" from a money file are areas where the user interface should be made nice. We want to make it easy for the user to specify exactly what denominations he wants to work with. One possibility is to simply have him input the amount (e.g. $10.55) and the program calculates that that's a 1000, a 50, and a 5, but this isn't really flexible enough. A nice system would be to give him a list of options and let him fill out a form on-screen, but that's hard to do portably. Another idea I've had is that there should be a special money file called the user's "wallet" which is the default place where incoming money from the bank should go. This might help organize things. He still needs to be able to create other money files for paying other people, and remembering to delete them after he sends them. Any suggestions or thoughts on these interface issues, or comments about how this program could or should be integrated into a larger system, would be appreciated. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAisiUPkAAAED/i1Pf1DaubveDsgjh360rNJ7kWkhssobaVmmWa70l4lOTwy/ sGwhJaA+JdScO9g3B66DIAaU0GiNrTS4YEl/b5ohNDZFdqKlxZ7NW9A5JYjUlhGE a53cRwqUXs42kbPbMh/uKxXBgbUnKrKZnWAh29irDWb+G8OEPQrkCJ6S8691AAUR tAl4UGhhZWRydXM= =HVRq -----END PGP PUBLIC KEY BLOCK----- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nobody@ocf.Berkeley.EDU Date: Mon, 7 Dec 92 00:30:49 PST To: cypherpunks@toad.com Subject: yet another remailer Message-ID: <199212070730.AA07386@plague.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain I've set up another remailer, this one on my ocf account. It's also based on Hal's (very easy to use and useful) script and does not yet have encryption because pgp201 is not the most portable thing around. To use, just do the standard thing: send mail to hh@ocf.berkeley.edu with the line: Anon-To: or Request-Remailing-To: and it will do the rest. Have fun! e From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: wendtj@jplpost.Jpl.Nasa.Gov (Jeffrey P Wendt) Date: Mon, 7 Dec 92 09:56:00 PST To: cypherpunks@toad.com Subject: No Subject Message-ID: <9211077237.AA72375@jplpost.jpl.nasa.gov> MIME-Version: 1.0 Content-Type: text/plain ruthere From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Chris Hibbert Date: Mon, 7 Dec 92 19:55:23 PST To: uunet!ghsvax!hal@uunet.UU.NET (Hal Finney) Subject: Re: Anonymous address problems In-Reply-To: <9212060122.AA19491@nano.noname> Message-ID: <9212071859.AA11109@entropy.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain There's a cheap fix for the particular problem you mentioned, Hal. (Of course, that's usually the case, and it's usually too weak a fix to help generally, but I think this one gives us back the ability to use anonymity here.) The cheap fix is to make sure that the last remailer in the chain (the one closest to you) is your own! That way you can ensure no one else checks its translation. No one else can be sure which is the second-to-last hop, so they can't tell who owns the last remailer. Chris From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: fnerd@smds.com (FutureNerd Steve Witham) Date: Mon, 7 Dec 92 08:26:16 PST To: cypherpunks@toad.com Subject: CHATTER Re: Broadcast/Filter vs. "Fetching" Message-ID: <9212071546.AB14663@smds.com> MIME-Version: 1.0 Content-Type: text/plain (I put "CHATTER" in the subject line as a clue that this is general talk off the subject of directly implementing crypto stuff.) Yanek Martinson sent an interesting message to me--I think he meant to post it--in response to my gripe: >> (I mean, while I'm at it, I hate the broadcast-and-filter model of netnews, >> CD ROMs, and cable TV. I want things available for me to go fetch.) > >But if you have the disk space and bandwidth to spare, it really does >make sense to receive everything and then decide what you want. Perhaps our company could make room for a couple days worth of the complete netnews. But, o That's hardly all the information there is. o I could never read it all, and I don't trust computer filters much. o I don't want to be a slave to the newsfeed/use-it-or-lose-it deal; I want to follow threads into the past, at my leisure. I want to let some discussions cook and then come back to them. >In your "fetch" scenario, what if I don't like (strongly) what Joe wrote. >So I can nuke Joe (or his archive) and no-one can "Fetch" the article. This is what I found interesting. You would really like the network (some network) to support distributed redundant archives, preferably with cross- checking. It would be even nicer if information could be stored, with storage cost charged to the owner and/or readers, and yet not have it knowable where the information was. Somehow a backwards mix setup. Put on your crypto thinking caps, kids. >On the other hand with the current set-up, it has already propagated >to hundreds of thousands of sites and it's impossible to stop. Yes. But, say, tens of untraceable sites would be okay. The flip side of 100K x redundancy is the little emily postnews handslap--"ARE YOU SURE?"-- and the rigamarole over creating new groups, and whether all the machines between you and the center of the universe get all the groups, etc. Plus the fact that most sites delete the stuff after a week or two, and all the effects on people's writing that has. >Also, if you want to filter stuff, then you should pay for the CPU >that does the filtering for you. My brain filters my mail! Boy do I pay for it! >Why would you expect someone else >to run your filter on their machine just so you would know if you >wanted to fetch their article. ?? I don't want machine filtering at all. Mostly I want references I can follow up easily. That's what fetching means. >Maybe I did not understand what you meant by "fetching". Hope it's clearer. >Could you describe your idea in more detail? >I absolutely agree that most of what comes in over my >newsfeed is junk, I just don't see a good way of >fixing this problem while retaining the robustness >and widespread communications capability. > >> -fnerd >> quote me...within *reason* of course > >(I guess 4 lines (including the sig) is well within reason) -fnerd quote me fnerd@smds.com (FutureNerd Steve Witham) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nobody@alumni.cco.caltech.edu Date: Mon, 7 Dec 92 19:52:58 PST To: cypherpunks@toad.com Subject: pgp2.1 released Message-ID: <9212072305.AA21821@alumni.cco.caltech.edu> MIME-Version: 1.0 Content-Type: text/plain PGP 2.1 is released. It's on soda.berkeley.edu, for your convenience, in directory pub/cypherpunks. The 2.1 release has the ability to sign a message as leave the message in plaintext. This should be used by all the pseudonyms in the group to prove continuity of authorship. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hollander Date: Mon, 7 Dec 92 19:51:58 PST To: cypherpunks@toad.com Subject: ocf remailer Message-ID: <9212080024.AA22987@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain For various reasons, my remailer on the ocf is going down indefinitely. It was fun while it lasted, I laughed, I cried, but now it's over. e From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: ghsvax!hal@uunet.UU.NET (Hal Finney) Date: Mon, 7 Dec 92 19:51:29 PST To: cypherpunks@toad.com Subject: Anonymous address problems, etc. Message-ID: <9212080059.AA20745@nano.noname> MIME-Version: 1.0 Content-Type: text/plain Chris Hibbert sent me a solution for the problem I mentioned about the last remailer in an anonymous address chain being able to discover the true name for the address. He suggested making your own remailer be the last one in the chain. If you added a little padding, so the second-to-last remailer couldn't tell (from the small size of the encrypted address) that yours was last, this sounds pretty good. And it's another reason to run a remailer, even if you had to do it manually. On the digital cash issue - I think we should get some kind of implementation of digicash (oops, "electronic money") out for people on the list to play with. Then, we should think of some kind of experimental email-based game to play which would use the special characteristics of anonymous cash. Maybe we could use the remailers, too. Players would send cash back and forth to each other as part of the game. Even if the tools are sort of rough at first, this could show where the most work is needed. Can anyone think of a good kind of game that we could play? As Eric Hughes pointed out, the cash doesn't have to be "cash", it could represent "gold" or "carrots" or any other material which exists in limited quantity. I think it was on the extropians list that Eli Brandt pointed out the need for a shorter term than "digital cash" for this cryptographic money. He suggested "cryps". I thought of "emoney" or "ecash" by analogy to "email". Here's another one: "crydets", based on "credits". Or maybe we should call them "Chaums". That way he'd be less likely to sue us for infringing on his patent. ;-) I notice he managed to cleverly name DC-nets after his initials so maybe he'd like this. Hal 74076.1041@compuserve.com P.S. I hear PGP 2.1 is coming out today. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nobody@pmantis.berkeley.edu Date: Mon, 7 Dec 92 19:56:34 PST To: cypherpunks@toad.com Subject: another remailer! Message-ID: <9212080357.AA10697@pmantis.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain I set up another remailer. All in all it took me about 30 min to compile perl and set up Hal's script. It's too easy! Just do the standard thing: mail to hh@pmantis.berkeley.edu with the line in the header Anon-To: or Request-Remailing-To: Have fun! e From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nobody@cicada.berkeley.edu Date: Mon, 7 Dec 92 21:45:33 PST To: cypherpunks@toad.com Subject: another remailer (again?) Message-ID: <9212080541.AA11090@cicada.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Yes, it's the second remailer I've set up today. Gee, at this rate, I'll have the entire CPU power of the United States dedicated to remailing within four months. Just do the usual thing: mail hh@cicada.berkeley.edu with the header line Anon-To: or Request-Remailing-To: and the remailer does the rest. cicada and pmantis have been able to compile pgp201 and so they will soon have encrypted remailer capability. They will also soon be running pgp21 (as soon as I get a chance to compile that). They are very fast machines, so I will probably give them military grade keys. They are also very secure machines. It's too bad about not being able to use the ocf, but those machines are slow anyway and probably wouldn't be able to run pgp ever. My soda remailer should be running pgp fairly soon. And I have 1-3 remailing sites almost ready to go, probably coming on sometime next week. And hughes is working on another remailer at soda, a really fancy one. Have fun everyone! e From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eli Brandt Date: Mon, 7 Dec 92 22:12:22 PST To: cypherpunks@toad.com Subject: Re: Anonymous address problems, etc. In-Reply-To: <9212080059.AA20745@nano.noname> Message-ID: <9212080612.AA05211@toad.com> MIME-Version: 1.0 Content-Type: text/plain > money. He suggested "cryps". I thought of "emoney" or "ecash" by > analogy to "email". Here's another one: "crydets", based on > "credits". Or maybe we should call them "Chaums". I passed over "emoney" et al, because I thought they just sounded lousy. Too brute-force... "crydets" I like, though. BTW, it was "cryp", like "scrip". Any further suggestions before the RFD? :-) Does anyone have a current contact for Chaum, or maybe know the fellow, in order to ask him how, well, PKP he's going to be about the whole thing? > Hal PGP 2 key by finger or e-mail Eli ebrandt@jarthur.claremont.edu From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nobody@soda.berkeley.edu Date: Mon, 7 Dec 92 22:25:37 PST To: cypherpunks@toad.com Subject: remailers, the prime user of bandwidth in the US (well, not yet) Message-ID: <9212080624.AA17822@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Could all remailer operators please mail me (hh@soda.berkeley.edu) the following information so that I can set up a remailer directory? There are so many remailers right now that this needs to be done: 1) address to mail to. for instance, hh@soda.berkeley.edu 2) how it works. what lines to put in the header, how to give it a pgp block, etc. 3) pgp key (if used) 4) how to contact the owner. this may be anonymous. you can easily set up your mail delivery file to have a Purpose: field and check it for "contact-owner" which would then forward the mail to the owner. 4) owner's name and email address (optional). I will compile all of this information and put it up for ftp on soda. e From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Derek Atkins Date: Mon, 7 Dec 92 19:49:44 PST To: cypherpunks@toad.com Subject: Just in case you haven't heard (PGP 2.1 released) Message-ID: <9212080347.AA10257@deathtongue.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- PGP 2.1 Available - ----------------- Pretty Good Privacy (PGP) Version 2.1 is now available, from Europe. This new version of the world's most popular and politically controversial public key encryption program has numerous bug fixes over version 2.0, and several new features. For example, you can now display the MD5 hash of a public key, to facilitate verifying it over the telephone with the owner of that public key. Also, it is now possible to send via email an unencrypted signed message without putting the whole message in Radix-64 format, to make it possible to read without PGP. This is analogous to the PEM MIC-CLEAR signed message functionality. PGP 2.1 incorporates many patches from the user community to port it to more platforms. And it runs faster. Also, a lot of annoying bugs and ergonomic oversights have been fixed. PGP 2.0 fans will find many rough edges have been smoothed out. The filenames are pgp21.zip for the MSDOS executable release, and pgp21src.zip for the source code release. You must have PKUNZIP version 1.1 or later to unzip them, or they won't unzip. The primary initial FTP sites that have it are: Finland: nic.funet.fi (128.214.6.100) Directory: /pub/unix/security/crypt/ Italy: ghost.dsi.unimi.it (149.132.2.1) Directory: /pub/security/ As previously, this prohibited and politically popular program will probably propagate through the same channels as PGP 2.0. Of course, if you live in the USA, you really shouldn't be using it. If you have any questions about where else to get it, contact Hugh Miller, at hmiller@lucpul.it.luc.edu. Hugh can send you the latest evolving list of FTP sites, BBS phone numbers, and other sources. Philip Zimmermann Phil's Pretty Good Software -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBKyLbAuJ13g7/Z/cLAQFxoAP+OqIqZu2zfA7LycuBJmaF0cms6xyYYok+ ifFW5hIKYUDqvVwLQg5kSXRIUY9fbSXaox6bnww+2YCoEacbzMAAVgTiw8TU7QG0 JryTOHsUIihq9JNBOQ5ONfmHzH0w2gaQ5SGEcJK93typoyvNQMtdtVSeIfkl6ImJ vs/OHzY5LiU= =nV70 -----END PGP SIGNATURE----- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Tue, 8 Dec 92 02:48:26 PST To: ebrandt@jarthur.Claremont.EDU Subject: Re: Anonymous address problems, etc. Message-ID: <199212081046.AA21621@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain How about e-marks...? Sort of the next big thing after D-marks (Deutche Marks, you know, German currency). I don's like "crydets" because it seems like it's not straightforward pronounciation, especially when dealing with other languages; too easy to confuse with "credits," and "cry-debts" ("boo-hoo-hoo, another collection notice!")... we need a word which is less ambiguous than that. "Cryp" like "scrip" is also like "Crip," which is a very very unpleasant connotation and might leave a bad taste in the mouth of Latinos in the US. E-Marks. Clear and straightforward, easy to pronounce and not too many syllables or weird spelling tweax. -gg. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: gnu (John Gilmore) Date: Tue, 8 Dec 92 05:31:54 PST To: fnerd@smds.com (FutureNerd Steve Witham) Subject: Captain Midnight returns? In-Reply-To: <9212032155.AB19933@smds.com> Message-ID: <9212081331.AA15358@toad.com> MIME-Version: 1.0 Content-Type: text/plain > ...put it on your crypto feature ring. Has a sort of futuristic ring to it. Hmm, perhaps we should eventually build real Captain Midnight Decoder Rings, which would fit around your finger. When the face of the ring was inserted into a DIN-plug serial port, it would power up, and talk a serial protocol to do the crypto operations needed to sign and decrypt messages, a la Phil Karn's design. There are smart-card microcontrollers with most or all of the right features -- we'd just have to figure out how to pot one into a ring with a truncated DIN-plug. John From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: fnerd@smds.com (FutureNerd Steve Witham) Date: Tue, 8 Dec 92 09:53:58 PST To: cypherpunks@toad.com Subject: peasant_multiply question Message-ID: <9212081715.AA26885@smds.com> MIME-Version: 1.0 Content-Type: text/plain Folks-- I got out my copy of the original RSA paper, and I'm comparing it to the PGP 2.0 code. I have a question about the peasant_modmult routine (the simplest modmult in PGP). Here's pseudocode of what I think it's doing: /* Inputs: modulus, multiplier, multiplicand */ /* Output: prod */ prod = 0; set sniffer to most significant bit of multiplier; nbits = number of significant bits in multiplier; while( nbits-- ) { shift prod left 1; prod = prod - modulus; if( the bit of the multiplier being sniffed = 1 ) { prod = prod + multiplicand; prod = prod - modulus; } move the sniffer to the next bit of the multiplier; } My question is (assuming I'm understanding the code right), how can it work subtracting modulus unconditionally all the time? Won't it make prod negative sometimes, and then keep multiplying the negative number by two until it overflows? Isn't that a problem?? -fnerd quote me fnerd@smds.com (FutureNerd Steve Witham) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: ghsvax!hal@uunet.UU.NET (Hal Finney) Date: Tue, 8 Dec 92 14:53:49 PST To: cypherpunks@toad.com Subject: PGP key generation Message-ID: <9212082250.AA22082@nano.noname> MIME-Version: 1.0 Content-Type: text/plain Steve Witham asks about PGP's "peasant_modmult" routine, how it can subtract the modulus on each addition. It doesn't, but the code is a little misleading (taken from mpilib.c, PGP 2.1): while (bits--) { mp_shift_left(prod); msub(prod,pmodulus); /* turns mult into modmult */ if (sniff_bit(multiplier,bitmask)) { mp_add(prod,multiplicand); msub(prod,pmodulus); /* turns mult into modmult */ } bump_bitsniffer(multiplier,bitmask); } What is confusing is that "msub" looks like "mp_sub". Actually, msub is a macro defined in mpilib.h: #define msub(r,m) if (mp_compare(r,m) >= 0) mp_sub(r,m) /* Prevents r from getting bigger than modulus m */ So, msub actually only subtracts if it's necessary, as would be expected. Jim McGrath asks: > When PGP generates keys doesn't it always pick d and e to have > the same number of bits, ie 446 for the strongest type? d and e are the decryption and encryption exponents. e is chosen to be small, typically the number 17 or slightly larger. d is then about the size of n, your key modulus. p and q, the two primes which are multiplied to get n, are about the same size, usually. PGP does have some code to make sure they aren't too close to the same size (taken from rsagen.c, PGP 2.1): /* See if p and q are far enough apart. Is q-p big enough? */ mp_move(u,q); /* use u as scratchpad */ mp_sub(u,p); /* compute q-p */ if (mp_tstminus(u)) /* p is bigger */ { mp_neg(u); too_close_together = (countbits(u) < (countbits(p)-7)); } else /* q is bigger */ too_close_together = (countbits(u) < (countbits(q)-7)); /* Keep trying q's until we get one far enough from p... */ } while (too_close_together); What this does is make sure that |p-q| is > 1/128 of the larger of p or q. This is designed to make sure that p and q are both very far from the square root of n. I.e. if n were 1024 bits, p and q could both be about 512 bits, but they would be at least about 2^505 from the square root of n, foiling the square root attacks. Hal 74076.1041@compuserve.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: fnerd@smds.com (FutureNerd Steve Witham) Date: Tue, 8 Dec 92 11:38:37 PST To: cypherpunks@toad.com Subject: Re: PGP questions Message-ID: <9212081910.AB28737@smds.com> MIME-Version: 1.0 Content-Type: text/plain >It's probably good to discuss how PGP works here, for educational >purposes, but I would expect people to get the source code if they >really are interested. I can give some pointers here to answers to >some of the questions people have asked. Thanks for the answers, Hal. I have been digging into the original RSA paper and the PGP 2.0 sources. By the way, sorry if my response time is long; I've been traveling for work lately. I suggested leaving the minimum set of compute-intensive routines in C and implementing the higher-level stuff in some higher-level language ("HLL"), possibly interpreted. Hal pointed out some of the crunching jobs other than modmult. Using an HLL has cons as well as pros to it. The main advantage (for my purpose here) is that C code has a lot of noise that gets in the way of understanding. This could also be improved by some coding style changes--for instance, using some object-oriented stuff (data structures that handle more of their own details) and, ahem, fewer #ifdefs... Another advantage of an HLL is ease of trying out different, er, schemes. If I used an HLL, I think it would be one that had very C-like syntax. The main drawback of an HLL is that it's another program that you have to trust. Sometimes inner parts of interpreters and compilers are hard to write so that they are correct *and seem* correct when you look at them. A couple of things they can do are automatic space allocation, garbage collection and "burning" data that's no longer in use ("garbage burning?"). -fnerd quote me fnerd@smds.com (FutureNerd Steve Witham) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Alan Hunter Date: Tue, 8 Dec 92 14:56:40 PST To: cypherpunks@toad.com Subject: Re Anonymous address problems etc Message-ID: <2b25279b.dunaad@dunaad.co.uk> MIME-Version: 1.0 Content-Type: text/plain On Mon, 7 Dec 92 16:59:12 PST, (Hal Finney) ghsvax!hal@uunet.uu.net wrote: > > On the digital cash issue - I think we should get some kind of > implementation of digicash (oops, "electronic money") out for people > on the list to play with. Then, we should think of some kind of > experimental email-based game to play which would use the special > characteristics of anonymous cash. Maybe we could use the remailers, > too. Players would send cash back and forth to each other as part of > the game. Even if the tools are sort of rough at first, this could > show where the most work is needed. > > Can anyone think of a good kind of game that we could play? How about making cypherpunks a subscription mailing list, and paying contributors? Alan From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: "McGrath, James" Date: Tue, 8 Dec 92 13:47:01 PST To: cypherpunks@toad.com Subject: No Subject Message-ID: <9212082145.AA14652@crop.lincoln.cri.nz> MIME-Version: 1.0 Content-Type: text/plain Karl said: > Also, p and q should differ in length by a few digits otherwise > an enemy may begin to try factoring n by starting near sqrt(n). When PGP generates keys doesn't it always pick d and e to have the same number of bits, ie 446 for the strongest type? Is this the same thing? I suppose that if you are allowed leading 0s it isn't a problem at all, but if the first couple of bits were ones in each key, (a 16:1 chance) wouldn't that significantly reduce the power required to factor the PK using this approach? Just a thought, Jim From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Alan Hunter Date: Wed, 9 Dec 92 12:58:03 PST To: cypherpunks@toad.com Subject: Experiments in Digital cash Message-ID: <2b264d98.dunaad@dunaad.co.uk> MIME-Version: 1.0 Content-Type: text/plain On Wed, 9 Dec 92 02:25:49 -0800, "John Draper" wrote: > Cm'on Alan, give us unemployed folks a break. Life's a bitch already > for us unemployed folks. To have to pay to get Cypherpunks mail > would not go very good. Just in case... I meant as an experiment in the use of digital cash and banks. I'm sure that DigiBank Inc would give us all an overdraft facility for starters. Alan From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: gnu (John Gilmore) Date: Thu, 10 Dec 92 03:03:08 PST To: cypherpunks@toad.com Subject: No more PGP keys without signatures, please! In-Reply-To: <9212080624.AA17822@soda.berkeley.edu> Message-ID: <9212101103.AA02644@toad.com> MIME-Version: 1.0 Content-Type: text/plain People continue to post PGP keys that are not vouched for by anyone. E.g. none of the keys for remailers has any signatures. This makes it impossible to trust those remailers, since anyone could have generated such a key and sent it through a remailer saying it was from someone else. If you put up a remailer service, sign its key with your personal key, at least. Preferably get a few other people to sign it (by showing them that they key is really the one used in the remailer, in person). If you generate a key for yourself, don't just post it -- take it to a friend, and cross-sign each others' keys. If you do that a few times, then you can post it, and the receipients are likely to know one of those friends, possibly trusting them to certify your key. John From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Edward Vielmetti Date: Thu, 10 Dec 92 05:01:55 PST To: jih@ox.com Subject: 'token exchange' market in Arizona Message-ID: MIME-Version: 1.0 Content-Type: text/plain For you all. Interesting because it would appear to be a real live marketplace, with real live money, tho no crypto per se in there. --Ed ------- Forwarded Message From: rkeca04@uts.manchester-computing-centre.ac.uk (Thomas Krichel) Subject: Arizona token exchange To: cti-econ@mailbase.ac.uk Date: Thu, 10 Dec 92 11:55:03 GMT Greetings, this is an item from corryfee. Apologies to those who have already seen it. I thought it was sufficiently interesting to pass it on. BTW, the some of the results of the Santa Fe experiment, to which the text refers, will be published in a forthcomming book by John Rust and Dan Friedman "Double Auction Markets: Theory, Institutions, Evidence". Publisher is Addison-Wesley (Santa Fe Institute series On Studies in the Science of Complexity). Cheers, ______ / / Department of Economics / /_ ________ __. _ University of Keele / / /_(_) / / <_(_/|_/_) ST5 5BG _ , _ Great Britain ' ) / / // Tel.: 44 - 782 - 714847 /-< __ o _. /_ _ // Fax: 44 - 782 - 717577 ./ )/ (_<_(__/ /_ > > > > ANNOUNCING THE OPENING OF THE > > ARIZONA TOKEN EXCHANGE (AZTE) > > January 1, 1993 > > Earn cash profits by competing against computerized program traders > > THE CHALLENGE > > Is "artificial intelligence" superior to human intelligence? In > some domains such as chess, computer programs now outperform all > but the very best human players. However in other domains such as > speech, handwriting, and other kinds of pattern recognition, > computers lag far behind human beings. On Wall Street computer > "program traders" are becoming increasingly common, yet there is > substantial controversy over their performance -- they have even > been blamed as a factor in the October 1987 stock market crash. > The purpose of this study, co-sponsored by the University of > Arizona's Economic Science Laboratory and the Santa Fe Institute, > is to compare the performance of human and program traders to see > whether humans can learn to exploit the limitations and > idiosyncracies of computers in repeated interactions. > > THE ARIZONA TOKEN EXCHANGE > > To compare the performance of human and program traders we have > created a computerized market, the Arizona Token Exchange (AZTE), > in which a fictional commodity, "tokens", are traded. The market > is a simplified version of commodity exchanges such as the Chicago > Board of Trade where buyers and sellers are able to call out bids > and asks to buy or sell units of the commodity. In each trading > session on AZTE traders are assigned the role of buyer or seller > and are given an allocation of tokens. A seller's objective is to > sell their tokens for as much as possible above the token cost and > a buyer's objective is to buy tokens as cheaply as possible below > their redemption value. > > By ranking the token costs and redemption values, well-defined > supply and demand curves can be constructed. The intersection of > these curves defines the so-called competitive equilibrium (CE) > price and quantity, at which neoclassical economic theory predicts > all trading will occur. The complication is that in the AZTE, > each trader's token costs and redemption values are private > information and differ from trader to trader. Thus traders in the > AZTE face a complex sequential decision problem: how much should > they bid or ask for their own tokens, how soon should they place a > bid or ask, and under what circumstances should they accept an > outstanding bid or ask of some other trader? An additional > complication is that each trading session runs for a fixed amount > of time. This creates a difficult trade-off, for if traders spend > too much time looking for a good deal, they may find themselves > locked out of the market without trading anything. > > HOW IS TRADER PERFORMANCE EVALUATED? > > In the AZTE there is a well-defined performance measure: trading > efficiency, EFF. This is the ratio of profits a trader actually > earns divided by the profits it would have made if all trades took > place at the competitive equilibrium level. Thus, if a trader's > EFF is greater than 100% they are earning more than their "fair" > share of the profits. The use of EFF is more desirable > performance measure than simply using trading profits, since > profits depend on the token allocations which are allocated at > random from a known distribution. > > After each trading session, participants will earn cash profits > equal to the following linear function of their efficiency: > > $ payments = a + b(EFF-100) > > The term a represents a fixed fee paid for participating in the > trading session and the term b(EFF-100) represents a bonus > (penalty) for trading above (or below) 100% efficiency. Thus, it > is possible to lose money in any particular trading session. > Dollar earnings are cumulated over successive trading sessions and > subjects are eligible to "cash out" at any time after participating > in a minimum number of trading sessions (provided cumulative > earnings are positive). > > THE OPPONENTS: COMPUTER PROGRAM TRADERS > > Unlike real commodities markets where most traders are humans, in > the AZTE all of your opponents will be computer programs. The > opponent programs will be selected from a field of over 30 > different trading strategies including winners of the Santa Fe > Institute's Double Auction Tournament held in March, 1990. The > program traders range in sophistication from simple rules of thumb > (such as Gode-Sunder "Zero-Intelligence" strategy) to sophisticated > optimizing/learning algorithms (such as neural nets and genetic > algorithms) developed from the recent literature on artificial > intelligence. The identities of your opponents will (usually) be > revealed to you at the start of each trading session. You will > also be informed about other market characteristics such as the > number of buyers and sellers, the number of tokens, and the joint > distribution from which token values are drawn. > > SETTING UP AN ACCOUNT > > To trade on the AZTE you will need a Unix or PC-compatible computer > linked to the Internet computer network. We provide the trading > interface software that allows you to log on and trade at any time > you like and for as long as you like (subject to general > restrictions). To qualify for an AZTE trading account you need to > file an application providing information on your address, phone, > and email address, and a release form stating whether or not you > want to remain anonymous in published analyses of the outcome of > this experiment. Upon receipt of the application we will set up a > trading account and access password. Your dollar earnings will > cumulate in your account until you decide to cash out, at which > time we will close your account and mail you a check for the total > amount of your earnings. > > The software and ASCII traders' manual (including the application > form) is available via anonymous ftp on "fido.econ.arizona.edu", in > the azte sub-directory. The manual (azte.man) explains how the > software works and what is required to use it. We suggest you ftp > this first and read through it, then get the appropriate trading > interface for your system. The DOS interface requires VGA graphics > resolution and the use of Clarkson packet drivers for the network > interface card. The Clarkson drivers are also available via ftp on > "fido.econ.arizona.edu". > > If you don't have access to anonymous ftp, we will mail you a > diskette containing the software and trader's manual. To cover the > costs of a diskette and surface mail, send $5.00 to: > > Shawn LaMaster > Manager, Economic Science Systems Development > Economic Science Laboratory > McClelland Hall, Room #116 > University of Arizona > Tucson, Arizona 85719 > (602) 621-6218 > > Internet: lamaster@ziggy.econ.arizona.edu > > We will assist in ftp and setting up the Clarkson packet drivers, > just give us a call. > > > The AZTE software was co-developed by: > > Sean Coates Economic Science Laboratory, University of Arizona > Shawn LaMaster Economic Science Laboratory, University of Arizona > Richard G. Palmer Duke University > John Rust University of Wisconsin > Vernon L. Smith Economic Science Laboratory, University of > Arizona > ------- End of Forwarded Message From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: hughes (Eric Hughes) Date: Thu, 10 Dec 92 08:01:27 PST To: cypherpunks-announce@toad.com Subject: No Subject Message-ID: <9212101601.AA08764@toad.com> MIME-Version: 1.0 Content-Type: text/plain Fourth Meeting When: Saturday, Dec 12, 1992, 12:00 noon Where: Cygnus Support offices Schedule: Noon Schmooze, key exchange 1:00 Business 5:00 Adjourn Agenda: 1. Media coverage. Do we want to deal with the press? If so, how? 2. Reputation Systems. Dean Tribble presenting. 3. Authenticated Diffie-Hellman (STS). Arthur Abraham presenting. 4. Reports Notes: 1. Please be prompt. We will begin the business section at 1:00 sharp. 2. Bring a portable computer and your key rings for PGP key exchange and signing. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: andrew_derry@sfu.ca Date: Thu, 10 Dec 92 09:31:17 PST To: cypherpunks@toad.com Subject: Key swap in Vancouver, BC, Canada, anyone? Message-ID: <9212101730.AA00143@whistler.sfu.ca> MIME-Version: 1.0 Content-Type: text/plain Is anybody in, or comming to, Vancouver, BC that I could swap public keys with? Thanks. --- Andrew Derry | ACS@HCC - Simon Fraser University | Internet: derry@sfu.ca | From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: hughes (Eric Hughes) Date: Thu, 10 Dec 92 11:14:03 PST To: cypherpunks-announce@toad.com Subject: Directions to Cygnus support offices Message-ID: <9212101913.AA13306@toad.com> MIME-Version: 1.0 Content-Type: text/plain Cygnus Support 1937 Landings Drive Mt. View, CA 94043 +1 415 903 1400 switchboard +1 415 903 1418 John Gilmore Take US 101 toward Mt. View. From San Francisco, it's about a 40-minute drive. Get off at the Rengstorff Ave/Amphitheatre Parkway exit. If you were heading south on 101, you curve around to the right, cross over the freeway, and get to a stoplight. If you were heading north on 101, you just come right off the exit to the stoplight. The light is the intersection of Amphitheatre and Charleston Rd. Take a right on Charleston; there's a right-turn-only lane. Follow Charleston for a short distance. You'll pass the Metaphor/Kaleida buildings on the right. At a clump of palm trees and a "Landmark Deli" sign, take a right into Landings Drive. At the end of the road, turn left into the complex with the big concrete "Landmark" sign. Follow the road past the deli til you are in front of the clock tower that rises out of one of the buildings, facing you. Enter through the doors immediately under the clock tower. They'll be open between noon and 1PM at least. (See below if you're late.) Once inside, take the stairs up, immediately to your right. At the top of the stairs, turn right past the treetops, and we'll be in 1937 on your left. The door is marked "Cygnus". If you are late and the door under the clock tower is locked, you can walk to the deli (which will be around the building on your left, as you face the door). Go through the gate in the fence to the right of the deli, and into the back lawns between the complex and the farm behind it. Walk forward and right around the buildings until you see a satellite dish in the lawn. Go up the stairs next to the dish, which are the back stairs into the Cygnus office space. We'll prop the door (or you can bang on it if we forget). Or, you can find the guard who's wandering around the complex, who knows there's a meeting happening and will let you in. They can be beeped at 965 5250, though you'll have trouble finding a phone. Don't forget to eat first, or bring food at noon! I recommend hitting the burrito place on Rengstorff (La Costen~a) at about 11:45. To get there, when you get off 101, take Rengstorff (toward the hills) rather than Amphitheatre (toward the bay). Follow it about ten blocks until the major intersection at Middlefield Road. La Costen~a is the store on your left at the corner. You can turn left into the narrow lane behind the store, which leads to a parking lot, and enter by the front door, which faces the intersection. To get to the meeting from there, just retrace your route on Rengstorff, go straight over the freeway, and turn right at the stoplight onto Charleston; see above. See you there! John Gilmore From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Thu, 10 Dec 92 12:59:53 PST To: cypherpunks@toad.com Subject: Re: Tapes of Cypherpunks meeting? In-Reply-To: <9212101813.AA19425@smds.com> Message-ID: <9212102058.AA18076@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Steve Witham writes: > Would it be possible to pay someone to video (or at least audio) > tape this meeting (& others)--or at least the scheduled speakers? > I can imagine privacy concerns... Maybe someone could > get ready to do it and then ask the attendees whether it's okay, > or under what arrangement. There will definitely be people there > with somewhat informed opinions on whether to trust me. I doubt this will ever happen. Videotaping is a hassle, is even more of a hassle when it comes to distributing the tapes, and is very disruptive. People start mugging for the camera, or avoid speaking at all. All in all, a bad idea. --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Marc.Ringuette@GS80.SP.CS.CMU.EDU Date: Thu, 10 Dec 92 11:03:58 PST To: cypherpunks@toad.com Subject: Re: 'token exchange' market in Arizona Message-ID: <9212101903.AA12887@toad.com> MIME-Version: 1.0 Content-Type: text/plain I participated in SFI's "Double Auction Tournament" a couple of years ago, placing second. Computer programs participated in a stock market game, with individual buyers and sellers competing with each other to make profit from fictional tokens. The emphasis of the contest was on computer trading strategies, not on monetary systems or computer security. This new "token exchange" sounds like a continuation of the original contest in which there will be an opportunity to compete and refine strategies over a longer term. It will probably be run from a central server with minimal concern over security; these are economists interested in stock market systems, not computer security people. In the original contest, there was a prize pool of $10,000 divided among the 30 contestants, with no contestant winning more than about $500. It seems likely that they'll have a similar bankroll for this one, as an inducement for people to compete. -- Marc Ringuette (mnr@cs.cmu.edu) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: fnerd@smds.com (FutureNerd Steve Witham) Date: Thu, 10 Dec 92 12:26:02 PST To: cypherpunks@toad.com Subject: CHATTER Broadcast/Filter vs. "Fetching" Message-ID: <9212101749.AA19315@smds.com> MIME-Version: 1.0 Content-Type: text/plain Yanek Martinson basically says that the information that comes over the netnews right now is small enough that you could archive a couple weeks' worth on a gigabyte disk and put the rest on four DAT tapes per year. True, but that's only the current rate of this particular channel. Plus, most of the time I'd have to go back to tape. But the real problem here is that I haven't explained what I want instead. I want all the archives of all the information in all media that have ever been published and stored electronically (including on video and audio tape) available at a second's notice. That's the volume and access-time part of it. The other part is, how do I find what I want? Yanek responds to me: >>...I don't trust computer filters much. > >So how would you expect to know to "fetch" it? Because I read one thing, and it says "in response to your article number so-and-so," or, "Hey, folks, there's a great book on this over here." In other words, following mentions in other things I see--things written mostly by humans, at least at this point, but also published indexes (manual or automatic) and guides. That plus maybe a couple of low-bandwidth subscription setups like magazines, and maybe one or two discussion groups like this one that I would give full time attention to. >> ...support distributed redundant archives, > >That's the current setup. > >> preferably with cross-checking. > >What exactly do you mean by this? That when I requested something, automatically a couple of storage sites would be asked for its MD5 checksum, and my machine would check them against each other and the actual data I got. > >> It would be even nicer if information could be stored, with >> storage cost charged to the owner and/or readers, > >I don't think this would work too well. Just because I answer someone's >question on a newsgroup, I would not want to receive a bill for the >storage. The DAT system you describe has all the potential readers pay for the storage. If they want to, then fine, but if not, and you don't want to either, that's fine, let your answer evaporate. Someone always *is* paying. >> and the rigamarole over creating new groups, and whether all the machines >> between you and the center of the universe get all the groups, etc. > >Then get Len Rose's satellite dish (I did) and you can be pretty sure >you get all the newsgroups. What's that cost, including electronics, modem, etc? Also, you didn't answer about the difficulty of creating groups. -fnerd store me now and quote me later fnerd@smds.com (FutureNerd Steve Witham) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: fnerd@smds.com (FutureNerd Steve Witham) Date: Thu, 10 Dec 92 12:26:15 PST To: cypherpunks@toad.com Subject: crypto credits Message-ID: <9212101749.AB19315@smds.com> MIME-Version: 1.0 Content-Type: text/plain >need for a shorter term than "digital cash" for this cryptographic >money. He suggested "cryps". I thought of "emoney" or "ecash" by >analogy to "email". Here's another one: "crydets", based on >"credits". Or maybe we should call them "Chaums".... How about "crypto credits" or "quatloos?" (And you're right about David Chaum, Dining Cryptographers and Digi Cash.) -fnerd quote me fnerd@smds.com (FutureNerd Steve Witham) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: fnerd@smds.com (FutureNerd Steve Witham) Date: Thu, 10 Dec 92 12:24:49 PST To: cypherpunks@toad.com Subject: Tapes of Cypherpunks meeting? Message-ID: <9212101813.AA19425@smds.com> MIME-Version: 1.0 Content-Type: text/plain >Fourth Meeting > >When: Saturday, Dec 12, 1992, 12:00 noon >Where: Cygnus Support offices Would it be possible to pay someone to video (or at least audio) tape this meeting (& others)--or at least the scheduled speakers? I can imagine privacy concerns... Maybe someone could get ready to do it and then ask the attendees whether it's okay, or under what arrangement. There will definitely be people there with somewhat informed opinions on whether to trust me. This brings up a fun concept: encrypted digital video and audio. Would it be hard to do IDEA encryption at the standard CD rate? There are schemes to compress video to that rate--how available are they? How much investment in equipment and crunch time do you need? How easy is it to interrupt the bit streams in and out of a DAT recorder? How cheap is the decoder? At present I would prefer VHS. from out of nowhere -fnerd fnerd@smds.com (FutureNerd Steve Witham) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Robert Brooks Date: Thu, 10 Dec 92 14:36:21 PST To: cypherpunks@toad.com Subject: A/V compression Message-ID: <9212102233.AA15517@hprrb.rose.hp.com> MIME-Version: 1.0 Content-Type: text/plain > > This brings up a fun concept: encrypted digital video and audio. > Would it be hard to do IDEA encryption at the standard CD rate? > There are schemes to compress video to that rate--how available > are they? How much investment in equipment and crunch time do > you need? How easy is it to interrupt the bit streams in and out > of a DAT recorder? How cheap is the decoder? > I picked this up off the net a while ago. Sounds like the CL451 might be programmable to do encryption/decryption, too. Background: MPEG is a compression standard for compressing VHS-quality video and stereo audio into a 1.5Mbit/s stream. If anyone's interested in funding/collaborating on a project involving this, let's talk. --- >From eletanjm@nuscc.nus.sg Fri Jul 10 21:06:25 1992 >Relay-Version: version Notes 2.8.4 1990/05/09; site hprpcd.rose.hp.com >From: eletanjm@nuscc.nus.sg (TAN JIN MENG) >Date: Sat, 11 Jul 1992 04:06:25 GMT >Date-Received: Sun, 12 Jul 1992 01:35:12 GMT >Subject: NEW MPEG I CHIP >Message-ID: <1992Jul11.040625.17239@nuscc.nus.sg> >Organization: National University of Singapore >Path: hprpcd!hprdash!hpergfg2!hpda!hpcc05!hplextra!hpscdc!sdd.hp.com!nigel.msen.com!yale.edu!jvnc.net!nuscc!eletanjm >Newsgroups: comp.multimedia >Lines: 23 > >Has anyone seen a demo or read about the new MPEG chipset from C-Cube >systems? > >I heard it's great! > >Some facts I know (or think I know) > >* CL450 - is a decoder only >* CL451 - due out later this year is full encoder/decoder codec >* core is a RISC based processor with 36bit bus splittable into > 4 data streams. 4 separate acc/mul units (ie SIMD). >* Can stream a full resolution video at ISA bus rates. >* Microcode and C compiler development kit. >* CL451 currently runs at 66MHz using fairly old .8 micron > technology ==> we can expect to see even higher speed devices. >* CL451 is pipelinable - ie can put multiple CL451 in tandem to > perform any amount of processor intensive activities. (eg real > time edge/motion detection, special effects etc). >* CL451 is a single chip solution. Just add VRAM. > >* Largest demand so far - for Karaoke!! C-Cube has Jap. backers. > >jin meng > > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Robert Brooks ~ ~ Hewlett Packard Company ~ ~ rb@hprpcd.rose.hp.com ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Robert Brooks ~ ~ Hewlett Packard Company ~ ~ rb@hprpcd.rose.hp.com ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: whitaker@eternity.demon.co.uk (Russell E. Whitaker) Date: Thu, 10 Dec 92 15:12:06 PST To: cypherpunks@toad.com Subject: MEETING: Cypherpunks UK (Sunday) Message-ID: <6042@eternity.demon.co.uk> MIME-Version: 1.0 Content-Type: text/plain Announcing - on incredibly short notice! - the first meeting of Cypherpunks UK... Chris Tame, of FOREST and the Libertarian Alliance, has generously offered the use of the meeting room at his offices for our gathering, this Sunday, 13 December 1992, from 1200 onwards (at least until 1800), at: FOREST 4th Floor 2 Grosvenor Gardens London SW1W 0DH 071-823-6550 This is just around the corner from Victoria Station, at the end of the mansion block near Hobart Place. There's a dark green cabbie shelter across the street from the entrance, and some British Telecom payphones. Can't miss it, really. However, if you have trouble, call the telephone number above, or call my pager, on 081-812-2661. If it helps, we're in the direction of Buckingham Palace, which is (very) partially visible from our windows. If you wish to attend, you should bring a 3.5" DOS-formatted diskette (sorry! My UN*X machine is an Intergraph workstation, and I can't use it for crypto) with a copy of your PGP 2.0+ public key. I'll sign it there. Mac users: if you don't have Apple File Exchange (what!?), I'll be extra nice and take your keys anyway ( ;-)) for AFE conversion on my IIcx. Not to fear. It might not be a bad idea to copy your public key on each of several diskettes, so you've got a copy to distribute to each of the others. Don't trust me to copy *your* key to others! As a matter of fact, as there are plenty of power points in the meeting room, you should bring your laptop, and/or a desktop PC: when someone hands you a disk-with-key, you can sign her key, and hand her back her diskette, with your own pubkey added. Otherwise, we might come close to a (n(n-1))/2 situation... ;-) This should be a lively meeting. Among the topics likely to be discussed are: o The proliferation of PGP public keys in the U.K. o The local development of anonymous remailers and a proposed automatic public key repository o Electronic networking/email security for the novice o Pro-active proliferation of PGP 2.1+ to interesting European, African, and Asian sites - ftp placement - BBS distribution - sneakernet across borders .. and much more! Mark Turner, from Demon Internet Systems, is likely to be on hand to demo DIS for non-DIS users. We've set up our own local, high-quality newsgroups: demon.security demon.security.keys and set up the /pub/ibmpc/pgp archives on gate.demon.co.uk (expanding recently to include all versions of PGP, and "fellow traveller" files). There will be other people here whom I think you will find interesting... be seeing you! Semper vigilans, Russell Earl Whitaker whitaker@eternity.demon.co.uk Communications Editor 71750.2413@compuserve.com EXTROPY: The Journal of Transhumanist Thought AMiX: RWHITAKER Board member, Extropy Institute (ExI) ================ PGP 2.0 public key available ======================= From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nobody@cicada.berkeley.edu Date: Thu, 10 Dec 92 23:20:55 PST To: cypherpunks@toad.com Subject: remailers Message-ID: <9212110717.AA07396@cicada.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain This is another call for info from remailer operators. I only heard from a few of you. Please send me info about how to use your remailer, including the public key. I will be setting up a special mailing list for remailer operators so we can discuss the technical issues of remailing, so if you mail me, you get on the list (if you want to). Remember, the more remailers there are and the more they are used, the safer it is for each individual remailer operator. And people won't use them unless they know how. And they won't know how unless there's a directory of them. e hh@soda.berkeley.edu From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nobody@rosebud.ee.uh.edu Date: Thu, 10 Dec 92 21:24:21 PST To: cypherpunks@toad.com Subject: No Subject Message-ID: <9212110524.AA22910@toad.com> MIME-Version: 1.0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Update on the digital cash project I am having some problems with the port to MSDOS, mostly due to implicitly assuming 32-bit integers in a few places. Probably I won't get it working until next weekend. To recap, the program provides Chaum-style digital cash via two executables, one for the "players" and one for the "banker". The banker creates a public key which has a single modulus n and multiple exponents, the prime numbers starting with 17. He sends n to the players and all is ready. Players withdraw money by running their programs and specifying the denominations they want to withdraw. For example, you could withdraw a 1, two 5's, a 10 and a 20. This would create a file with 5 entries to be sent to the bank. PGP should be used to encrypt and ascii-encode this file (for privacy) and it should be mailed to the banker. The banker receives this file and runs his program to RSA-sign the values in each of the withdrawal-request entries. This is the "blinded cash" that Chaum describes. Again, PGP should be used for mailing this back to the user. The player then has to "unblind" the file to make it "real" digital cash. This also changes it so that the bank won't recognize it when it is deposited. He uses his version of the program to do this, producing an actual digital money file with the five "digital bills" in it. To pay another user, he runs another function to extract the desired bills from this file. Suppose he wants to extract a 1 and a 5. This leaves a 5, a 10 and a 20 in the original file, and creates a new digital cash file with a 1 and a 5. He would then use PGP again to encrypt this for safety and mail it to the person he wants to pay. That person can run a "check" function on the incoming digital money to make sure it has a proper bank signature on it and is not a forgery. He would then mail it directly to the bank so that it could get credited to his account. The banker runs his program which checks the signatures on the incoming money, looks in a database file to make sure these bills haven't been used before, and adds these bills to the database. (The database stores 16 bytes per bill.) He should then record the deposit and perhaps send a confirmation to the depositor (my program doesn't get involved with that). I hope this gives a clearer picture of how the electronic money program works. It is a simple implementation but I think many systems would work similarly. I appreciated the suggestion to use cash as part of the list management itself. Rather than paying people who post, I wonder if it would be better to make people pay to post. Many people have complained about the volume. :) Unfortunately, I suspect that this would involve too much overhead for the mailing list maintainer. Maybe the thing to do is to just get the software out there and let people decide what they want to do with it (if anything). I'm probably going to take a couple more weeks to clean up the user interface and get these bugs out, then I'll try sending it someone to be put on the cypherpunks ftp archive. It's nice to be able to finally sign these messages! - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.1 mQCNAisiUPkAAAED/i1Pf1DaubveDsgjh360rNJ7kWkhssobaVmmWa70l4lOTwy/ sGwhJaA+JdScO9g3B66DIAaU0GiNrTS4YEl/b5ohNDZFdqKlxZ7NW9A5JYjUlhGE a53cRwqUXs42kbPbMh/uKxXBgbUnKrKZnWAh29irDWb+G8OEPQrkCJ6S8691AAUR tAl4UGhhZWRydXM= =HVRq - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBKyZADQrkCJ6S8691AQHneQP8DRdkOFfG9TwjGDJAX4IxymvzAITqYIJC aMhytyzqFwP6Dku955ZHEPL1SDpNCU8DwK7eKDOgvHRS3m+kihs1l6VR3Gf0AgGw 7jjRJlt7hcqfT16fLHVXtn27A16rUhl2hKrD702wjGzX+MN7mS/8MW2kchVfvQYX M/McOuwuIjs= =/HGX -----END PGP SIGNATURE----- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: mark@coombs.anu.edu.au (Mark) Date: Thu, 10 Dec 92 17:24:57 PST To: cypherpunks@toad.com Subject: Re: Questions about US/Canadian Laws about public encryption In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain David Banisar quotes: >> (1) Is feeding public data or telephone networks with crypted data >> illegal or those who posted articles on the subject were just >> wishing it were made illegal ??? One might ask that they prove it is encrypted and not merely garbage your pumping down the line to defeat traffic analysis attacks. I dont think it's illegal so send garbage down a line assuming your paying for it and noone is being defrauded by your use of the medium. If you have good enough cryptography they cant prove it's encrypted. If they managed to decode it to something that looks like text but isnt the original cleartext then they are just grabbing at straws and not 'decrypting'. If you choose to put the "standard" bytes in front and behind every block to make it *look* like it's encrypted with a well known algorithm thats your business. To me proving it's encrypted amounts to decrypting it which is what your trying to protect against. If they can prove the algorithm is weak then you can just pay the fine and choose another method. Mark mark@coombs.anu.edu.au From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: mark@coombs.anu.edu.au (Mark) Date: Thu, 10 Dec 92 17:31:26 PST To: cypherpunks@toad.com Subject: Re: Questions about US/Canadian Laws about public encryption In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain On a discussion of devices one can attach to a phone line to encrypt your comms: rcain@netcom.com (Robert Cain) writes: >There may be U.S. national security >laws broad enough to stop a potential seller of such a device and I >have been told that under such laws (of which I know little by definition) >a stop order can be issued by a court which you must obey but can't even >open because it carries a top secret seal and furthermore you cannot even >discuss it without looking at Leavenworth. So it is entirely possible that >hidden laws exist to prevent sale of such devices, have been used and we >would not know it under the umbrella of U.S. national security. So much for "ignorance of the law is no excuse". They want it both ways? Secret laws and you obeying them? Sounds like the rules my roomies make up as we play any board game. (aka cheating :) Mark mark@coombs.anu.edu.au From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: George A. Gleason Date: Fri, 11 Dec 92 02:22:14 PST To: mark@coombs.anu.edu.au Subject: Re: Questions about US/Canadian Laws about public encryption Message-ID: <199212111020.AA28057@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Any attempt at "secret law" in the US would be pretty straightforward to defeat on the basis that it denies due process and a whole lot else besides. Secret court orders! Retch! Next person to get one should run not walk to the offices of the nearest big newspaper or radio/TV station and do a live on-air interview. Then the govt has to take on the press as well, and by that time it's kinda too late. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tribble@xanadu.com (E. Dean Tribble) Date: Fri, 11 Dec 92 10:10:54 PST To: uunet!well.sf.ca.us!gg@uunet.UU.NET Subject: Questions about US/Canadian Laws about public encryption In-Reply-To: <199212111020.AA28057@well.sf.ca.us> Message-ID: <9212111720.AA24204@xanadu.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain Any attempt at "secret law" in the US would be pretty straightforward to defeat on the basis that it denies due process and a whole lot else besides. Secret court orders! Retch! Next person to get one should run not walk to the offices of the nearest big newspaper or radio/TV station and do a live on-air interview. Then the govt has to take on the press as well, and by that time it's kinda too late. This worls in theory, but practice can be much more confusing. For instance, the warrant used to invade Steve Jackson Games was sealed, so they couldn't see what was being looked for. If you face a Grand Jury, then you can't take the 5th (thus drug crimes are being pursued by Grand Juries). Etc. I'm not prophesying gloom and doom (at least not here :-), merely pointing out that what makes sense, what seems ethical, what the theory of the law says, and what the practice of the law says are all different, and it's quite easy to be wrong. dean From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nobody@pmantis.berkeley.edu Date: Fri, 11 Dec 92 14:58:27 PST To: cypherpunks@toad.com Subject: Chaum's "The Dining Cryptographers Problem" (VERY LONG) Message-ID: <9212112258.AA09353@pmantis.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain The following article is brought to you by the Information Liberation Front (ILF), a group dedicated to the timely distribution of important information. The ILF encourages you to use this article for educational purposes only and to seek out the original article. Minor spelling errors and slight alterations of formulas may have gotten past the OCR process. We apologize for the length, but feel this is one of the key articles in this area. J. Cryptology (1988) 1:65-75 The Dining Cryptographers Problem: Unconditional Sender and Recipient Untraceability David Chaum Centre for Mathematics and Computer Science, Kruislan 413, 1098 SJ Amsterdam, The Netherlands Abstract. Keeping confidential who sends which messages, in a world where any physical transmission can be traced to its origin, seems impossible. The solution presented here is unconditionally or cryptographically secure, depending on whether it is based on one-time-use keys or on public keys, respectively. It can be adapted to address efficiently a wide variety of practical considerations. Key words. Untraceability, Unconditional Security, Pseudonymity. Introduction Three cryptographers are sitting down to dinner at their favorite three-star restaurant. Their waiter informs them that arrangements have been made with the maitre d'hotel for the bill to be paid anonymously. One of the cryptographers might be paying for the dinner, or it might have been NSA (U.S. National Security Agency). The three cryptographers respect each other's right to make an anonymous payment, but they wonder if NSA is paying. They resolve their uncertainty fairly by carrying out the following protocol: Each cryptographer flips an unbiased coin behind his menu, between him and the cryptographer on his right, so that only the two of them can see the outcome. Each cryptographer then states aloud whether the two coins he can see--the one he flipped and the one his left-hand neighbor flipped--fell on the same side or on different sides. If one of the cryptographers is the payer, he states the opposite of what he sees. An odd number of differences uttered at the table indicates that a cryptographer is paying; an even number indicates that NSA is paying (assuming that the dinner was paid for only once). Yet if a cryptographer is paying, neither of the other two learns anything from the utterances about which cryptographer it is. To see why the protocol is unconditionally secure if carried out faithfully, consider the dilemma of a cryptographer who is not the payer and wishes to find out which cryptographer is. (If NSA pays, there is no anonymity problem.) There are two cases. In case (1) the two coins he sees are the same, one of the other cryptographers said "different," and the other one said "same." If the hidden outcome was the same as the two outcomes he sees, the cryptographer who said "different" is the payer; if the outcome was different, the one who said "same" is the payer. But since the hidden coin is fair, both possibilities are equally likely. In case (2) the coins he sees are different; if both other cryptographers said "different," then the payer is closest to the coin that is the same as the hidden coin; if both said "same," then the payer is closest to the coin that differs from the hidden coin. Thus, in each subcase, a nonpaying cryptographer learns nothing about which of the other two is paying. The cryptographers become intrigued with the ability to make messages public untraceably. They devise a way to do this at the table for a statement of arbitrary length: the basic protocol is repeated over and over; when one cryptographer wishes to make a message public, he merely begins inverting his statements in those rounds corresponding to 1 's in a binary coded version of his message. If he notices that his message would collide with some other message, he may for example wait a number of rounds chosen at random from a suitable distribution before trying to transmit again. 1. Generalizing the Approach During dinner, the cryptographers also consider how any number of participants greater than one can carry out a version of the protocol. (With two participants, only nonparticipant listeners are unable to distinguish between the two potential senders.) Each participant has a secret key bit in common with, say, every other participant. Each participant outputs the sum, modulo two, of all the key bits he shares, and if he wishes to transmit, he inverts his output. If no participant transmits, the modulo two sum of the outputs must be zero, since every key bit enters exactly twice; if one participant transmits, the sum must be one. (In fact, any even number of transmitting participants yields zero, and any odd number yields one.) For j rounds, each participant could have a j-bit key in common with every other participant, and the ith bit of each such key would be used only in the ith round. Detected collision of messages leads to attempted retransmission as described above; undetected collision results only from an odd number of synchronized identical message segments. (Generalization to fields other than GF(2) is possible, but seems to offer little practical advantage.) Other generalizations are also considered during dinner. The underlying assumptions are first made explicit, including modeling key-sharing arrangements as graphs. Next, the model is illustrated with some simple examples. The potential for cooperations of participants to violate the security of others is then looked at. Finally, a proof of security based on systems of linear equations is given. 1.1. Model Each participant is assumed to have two kinds of secret: (a) the keys shared with other participants for each round; and (b) the inversion used in each round (i.e., a 1 if the participant inverts in that round and a 0 if not). Some or all of a participant's secrets may be given to other participants in various forms of collusion, discussion of which is postponed until Section 1.3. (For simplicity in exposition, the possibility of secrets being stolen is ignored throughout.) The remaining information about the system may be described as: (a) who shares keys with whom; and (b) what each participant outputs during each round (the modulo two sum of that participant's keys and inversion). This information need not be secret to ensure untraceability. If it is publicly known and agreed, it allows various extensions discussed in Sections 2.5 and 2.6. The sum of all the outputs will, of course, usually become known to all participants. In the terminology of graphs, each participant corresponds to a vertex and each key corresponds to an edge. An edge is incident on the vertices corresponding to the pair of participants that shares the corresponding key. From here on, the graph and dinner-table terminologies will be used interchangeably. Also, without loss of generality, it will be assumed that the graph is connected (i.e., that a path exists between every pair of vertices), since each connected component (i.e., each maximal connected subgraph) could be considered a separate untraceable-sender system. An anonymity set seen by a set of keys is the set of vertices in a connected component of the graph formed from the original graph by removing the edges concerned. Thus a set of keys sees one anonymity set for each connected partition induced by removing the keys. The main theorem of Section 1.4 is essentially that those having only the public information and a set of keys seeing some anonymity set can learn nothing about the members of that anonymity set except the overall parity of their inversions. Thus, for example, any two participants connected by at least one chain of keys unknown to an observer are both in the same anonymity set seen by the observer's keys, and the observer gains nothing that would help distinguish between their messages. 1.2. Some Examples A few simple consequences of the above model may be illustrative. The anonymity set seen by the empty set (i.e., by a nonparticipant observer) is the set of all vertices, since the graph is assumed connected and remains so after zero edges are removed. Also, the anonymity sets seen by the full set of edges are all singleton sets, since each vertex's inversion is just the sum of its output and the corresponding key bits. If all other participants cooperate fully against one, of course no protocol can keep that singleton's messages untraceable, since untraceability exists only among a set of possible actors, and if the set has only one member, its messages are traceable. For similar reasons, if a participant believes that some subset of other participants will fully cooperate against him, there is no need for him to have keys in common with them. A biconnected graph (i.e., a graph with at least two vertex-disjoint paths between every pair of vertices) has no cut-vertices (i.e., a single vertex whose removal partitions the graph into disjoint subgraphs). In such a graph, the set of edges incident on a vertex v sees (apart from v) one anonymity set containing all other vertices, since there is a path not containing v between every pair of vertices, and thus they form a connected subgraph excluding v; each participant acting alone learns nothing about the contribution of other participants. 1.3. Collusion of Participants Some participants may cooperate by pooling their keys in efforts to trace the messages of others; such cooperation will be called collusion. For simplicity, the possibilities for multiple collusions or for pooling of information other than full edges will be ignored. Colluders who lie to each other are only touched on briefly, in Section 2.6. Consider collusion in a complete graph. A vertex is only seen as a singleton anonymity set by the collection of all edges incident on it; all other participants must supply the key they share with a participant in order to determine that participant's inversions. But since a collusion of all but one participant can always trace that participant merely by pooling its members' inversions as already mentioned, it gains nothing more by pooling its keys. The nonsingleton anonymity set seen by all edges incident on a colluding set of vertices in a complete graph is the set of all other vertices; again, a collusion yields nothing more from pooling all its keys than from pooling all its inversions. Now consider noncomplete graphs. A full collusion is a subset of participants pooling all of their keys. The pooled keys see each colluder as a singleton anonymity set; the colluders completely sacrifice the untraceability of their own messages. If a full collusion includes a cut- set of vertices (i.e., one whose removal partitions the graph), the collusion becomes nontrivial because it can learn something about the origin of messages originating outside the collusion; the noncolluding vertices are partitioned into disjoint subgraphs, which are the anonymity sets seen by the pooled keys. Members of a partial collusion pool some but not all of their keys. Unlike the members of a full collusion, each member of a partial collusion in general has a different set of keys. For it to be nontrivial, a partial collusion's pooled keys must include the bridges or separating edges of a segregation or splitting of the graph (i.e., those edges whose removal would partition the graph). Settings are easily constructed in which the pooled keys see anonymity sets that partition the graph and yet leave each colluder in a nonsingleton partition seen by any other participant. Thus, colluders can join a collusion without having to make themselves completely traceable to the collusion's other members. 1.4. Proof of Security Consider, without loss of generality, a single round in which say some full collusion knows some set of keys. Remove the edges known to the collusion from the key-sharing graph and consider any particular connected component C of the remaining graph. The vertices of C thus form an anonymity set seen by the pooled keys. Informally, what remains to be shown is that the only thing the collusion learns about the members of C is the parity sum of their inversions. This is intuitively apparent, since the inversions of the members of C are each in effect hidden from the collusion by one or more unknown key bits, and only the parity of the sum of these key bits is known (to be zero). Thus the inversions are hidden by a one-time pad, and only their parity is revealed, because only the parity of the pad is known. The setting is formalized as follows: the connected component C is comprised of rn vertices and n edges. The incidence matrix M of C is defined as usual, with the vertices labeling the rows and the edges labeling the columns. Let K, I, and A be stochastic variables defined on GF(2)^n, GF(2)^m, and GF(2)^m, respectively, such that K is uniformly distributed over GF(2)^n, K and I are mutually independent, and A = (MK) cross I. In terms of the protocol, K comprises the keys corresponding to the edges, I consists of the inversions corresponding to the vertices, and A is formed by the outputs of the vertices. Notice that the parity of A (i.e., the modulo two sum of its components) is always equal to the parity of I, since the columns of M each have zero parity. The desired result is essentially that A reveals no more information about I than the parity of 1. More formally: Theorem. Let a be in GF(2)^n. For each i in GF(2)^n, which is assumed by I with nonzero probability and which has the same parity as a, the conditional probability that A = a given that I = i is 2^(1 - m). Hence, the conditional probability that I = i given that A = a is the a priori probability that I = i. Proof. Let i be an element of GF(2)^n have the same parity as a. Consider the system of linear equations (MK) cross i = a, in k an element of GF(2)^n. Since the columns of M each have even parity, as mentioned above, its rows are linearly dependent over GF(2)^m. But as a consequence of the connectedness of the graph, every proper subset of rows of M is linearly independent. Thus, the rank of M is m - 1, and so each vector with zero parity can be written as a linear combination of the columns of M. This implies that the system is solvable because i cross a has even parity. Since the set of n column vectors of M has rank m - 1, the system has exactly 2^(n - m + 1) solutions. Together with the fact that K and I are mutually independent and that K is uniformly distributed, the theorem follows easily. 2. Some Practical Considerations After dinner, while discussing how they can continue to make untraceable statements from this respective homes, the cryptographers take up a variety of other topics. In particular, they consider different ways to establish the needed keys; debate adapting the approach to various kinds of communication networks; examine the traditional problems of secrecy and authentication in the context of a system that can provide essentially optimal untraceability; address denial of service caused by malicious and devious participants; and propose means to discourage socially undesirable messages from being sent. 2.1. Establishing Keys One way to provide the keys needed for longer messages is for one member of each pair to toss many coins in advance. Two identical copies of the resulting bits are made, say each on a separate optical disk. Supplying one such disk (which today can hold on the order of 10^10 bits) to a partner provides enough key bits to allow people to type messages at full speed for years. If participants are not transmitting all the time, the keys can be made to last even longer by using a substantially slower rate when no message is being sent; the full rate would be invoked automatically only when a 1 bit indicated the beginning of a message. (This can also reduce the bandwidth requirements discussed in Section 2.2.) Another possibility is for a pair to establish a short key and use a cryptographic pseudorandom-sequence generator to expand it as needed. Of course this system might be broken if the generator were broken. Cryptanalysis may be made more difficult, however, by lack of access to the output of individual generators. Even when the cryptographers do not exchange keys at dinner, they can safely do so later using a public- key distribution system (first proposed by [4] and [3]). 2.2 Underlying Communication Techniques A variety of underlying communication networks can be used, and their topology need not be related to that of the key-sharing graph. Communication systems based on simple cycles, called rings, are common in local area networks. In a typical ring, each node receives each bit and passes it round-robin to the next node. This technology is readily adapted to the present protocols. Consider a single-bit message like the "I paid" message originally sent at the dinner table. Each participant exclusive-or's the bit he receives with his own output before forwarding it to the next participant. When the bit has traveled full circle, it is the exclusive-or sum of all the participants' outputs, which is the desired result of the protocol. To provide these messages to all participants, each bit is sent around a second time by the participant at the end of the loop. Such an adapted ring requires, on average, a fourfold increase in bandwidth over the obvious traceable protocols in which messages travel only halfway around on average before being taken off the ring by their recipients. Rings differ from the dinner table in that several bit- transmission delays may be required before all the outputs of a particular round are known to all participants; collisions are detected only after such delays. Efficient use of many other practical communication techniques requires participants to group output bits into blocks. For example, in high-capacity broadcast systems, such as those based on coaxial cable, surface radio, or satellites, more efficient use of channel capacity is obtained by grouping a participant's contribution into a block about the size of a single message (see, e.g., [5]). Use of such communication techniques could require an increase in bandwidth on the order of the number of participants. In a network with one message per block, the well-known contention protocols can be used: time is divided evenly into frames; a participant transmits a block during one frame; if the block was garbled by collision (presumably with another transmitted block), the participant waits a number of frames chosen at random from some distribution before attempting to retransmit; the participants' waiting intervals may be adjusted on the basis of the collision rate and possibly of other heuristics [5]. In a network with many messages per block, a first block may be used by various anonymous senders to request a "slot reservation" in a second block. A simple scheme would be for each anonymous sender to invert one randomly selected bit in the first block for each slot they wish to reserve in the second block. After the result of the first block becomes known, the participant who caused the ith 1 bit in the first block sends in the ith slot of the second block. 2.3. Example Key-Sharing Graphs In large systems it may be desirable to use fewer than the m(m - 1)/2 keys required by a complete graph. If the graph is merely a cycle, then individuals acting alone learn nothing, but any two colluders can partition the graph, perhaps fully compromising a participant immediately between them. Such a topology might nevertheless be adequate in an application in which nearby participants are not likely to collude against one another. A different topology assumes the existence of a subset of participants who each participant believes are sufficiently unlikely to collude, such as participants with conflicting interests. This subset constitutes a fully connected subgraph, and the other participants each share a key with every member of it. Every participant is then untraceable among all the others, unless all members of the completely connected subset cooperate. (Such a situation is mentioned again in Section 3.) If many people wish to participate in an untraceable communication system, hierarchical arrangements may offer further economy of keys. Consider an example in which a representative from each local fully connected subgraph is also a member of the fully connected central subgraph. The nonrepresentative members of a local subgraph provide the sum of their outputs to their representative. Representatives would then add their own contributions before providing the sum to the central subgraph. Only a local subgraph's representative, or a collusion of representatives from all other local subgraphs, can recognize messages as coming from the local subgraph. A collusion comprising the representative and all but one nonrepresentative member of a local subgraph is needed for messages to be recognized as coming from the remaining member. 2.4. Secrecy and Authentication What about the usual cryptologic problems of secrecy and authentication? A cryptographer can ensure the secrecy of an anonymous message by encrypting the message with the intended recipient's public key. (The message should include a hundred or so random bits to foil attempts to confirm a guess at its content [1].) The sender can even keep the identity of the intended recipient secret by leaving it to each recipient to try to decrypt every message. Alternatively, a prearranged prefix could be attached to each message so that the recipient need only decrypt messages with recognized prefixes. To keep even the multiplicity of a prefix's use from being revealed, a different prefix might be used each time. New prefixes could be agreed in advance, generated cryptographically as needed, or supplied in earlier messages. Authentication is also quite useful in systems without identification. Even though the messages are untraceable, they might still bear digital signatures corresponding to public-key "digital pseudonyms" [1]; only the untraceable owner of such a pseudonym would be able to sign subsequent messages with it. Secure payment protocols have elsewhere been proposed in which the payer and/or the payee might be untraceable [2]. Other protocols have been proposed that allow individuals known only by pseudonyms to transfer securely information about themselves between organizations [2]. All these systems require solutions to the sender untraceability problem, such as the solution presented here, if they are to protect the unlinkability of pseudonyms used to conduct transactions from home. 2.5. Disruption Another question is how to stop participants who, accidentally or even intentionally, disrupt the system by preventing others from sending messages. In a sense, this problem has no solution, since any participant can send messages continuously, thereby clogging the channel. But nondisupters can ultimately stop disruption in a system meeting the following requirements: (1) the key-sharing graph is publicly agreed on; (2) each participant's outputs are publicly agreed on in such a way that participants cannot change their output for a round on the basis of other participants' outputs for that round; and (3) some rounds contain inversions that would not compromise the untraceability of any nondisrupter. The first requirement has already been mentioned in Section 1.1, where it was said that this information need not be secret; now it is required that this information actually be made known to all participants and that the participants agree on it. The second requirement is in part that disrupters be unable (at least with some significant probability) to change their output after hearing other participants' outputs. Some actual channels would automatically ensure this, such as broadcast systems in which all broadcasts are made simultaneously on different frequencies. The remainder of the second requirement, that the outputs be publicly agreed on, might also be met by broadcasting. Having only channels that do not provide it automatically, an effective way to meet the full second requirement would be for participants to "commit" to their outputs before making them. One way to do this is for participants to make public and agree on some (possibly compressing and hierarchical, see Section 2.6) one-way function of their outputs, before the outputs are made public. The third requirement is that at least some rounds can be contested (i.e., that all inversions can be made public) without compromising the untraceability of non-disrupting senders. The feasibility of this will be demonstrated here by a simple example protocol based on the slot reservation technique already described in Section 2.2. Suppose that each participant is always to make a single reservation in each reserving block, whether or not he actually intends to send a message. (Notice that, because of the "birthday paradox," the number of bits per reserving block must be quadratic in the number of participants.) A disrupted reserving block would then with very high probability have Hamming weight unequal to the number of participants. All bits of such a disrupted reserving block could be contested without loss of untraceability for nondisrupters. The reserved blocks can also be made to have such safely contestable bits if participants send trap messages. To lay a trap, a participant first chooses the index of a bit in some reserving block, a random message, and a secret key. Then the trapper makes public an encryption, using the secret key, of both the bit index and the random message. Later, the trapper reserves by inverting in the round corresponding to the bit index, and sends the random message in the resulting reserved slot. If a disrupter is unlucky enough to have damaged a trap message, then release of the secret key by the trapper would cause at least one bit of the reserved slot to be contested. With the three requirements satisfied, it remains to be shown how if enough disrupted rounds are contested, the disrupters will be excluded from the network. Consider first the case of a single participant's mail computer disrupting the network. If it tells the truth about contested key bits it shares (or lies about an even number of bits), the disrupter implicates itself, because its contribution to the sum is unequal to the sum of these bits (apart from any allowed inversion). If, on the other hand, the single disrupter lies about some odd number of shared bits, the values it claims will differ from those claimed for the same shared bits by the other participants sharing them. The disrupter thereby casts suspicion on all participants, including itself, that share the disputed bits. (It may be difficult for a disrupter to cast substantial suspicion on a large set of participants, since all the disputed bits will be in common with the disrupter.) Notice, however, that participants who have been falsely accused will know that they have been--and by whom--and should at least refuse to share bits with the disrupter in the future. Even with colluding multiple disrupters, at least one inversion must be revealed as illegitimate or at least one key bit disputed, since the parity of the outputs does not correspond to the number of legitimate inversions. The result of such a contested round will be the removal of at least one edge or at least one vertex from the agreed graph. Thus, if every disruptive action has a nonzero probability of being contested, only a bounded amount of disruption is possible before the disrupters share no keys with anyone in the network, or before they are revealed, and are in either case excluded from the network. The extension presented next can demonstrate the true value of disputed bits, and hence allows direct incrimination of disrupters. 2.6. Tracing by Consent Antisocial use of a network can be deterred if the cooperation of most participants makes it possible, albeit expensive, to trace any message. If, for example, a threatening message is sent, a court might order all participants to reveal their shared key bits for a round of the message. The sender of the offending message might try to spread the blame, however, by lying about some odd number of shared bits. Digital signatures can be used to stop such blame-spreading altogether. In principle, each party sharing a key could insist on a signature, made by the other party sharing, for the value. of each shared bit. Such signatures would allow for contested rounds to be fully resolved, for accused senders to exonerate themselves, and even for colluders to convince each other that they are pooling true keys. Unfortunately, cooperating participants able to trace a message to its sender could convince others of the message's origin by revealing the sender's own signatures. A variation can prevent a participant's signatures from being used against him in this way: instead of each member of a pair of participants signing the same shared key bit, each signs a separate bit, such that the sum of the signed bits is the actual shared key bit. Signatures on such "split" key bits would still be useful in resolving contested rounds, since if one contester of a bit shows a signature made by the second contester, then the second would have to reveal the corresponding signature made by the first or be thought to be a disrupter. In many applications it may be impractical to obtain a separate signature on every key bit or split key bit. The overhead involved could be greatly reduced, however, by digitally signing cryptographic compressions of large numbers of key bits. This might of course require that a whole block of key bits be exposed in showing a signature, but such blocks could be padded with cryptographically generated pseudorandom (or truly random) bits, to allow the exposure of fewer bits per signature. The number of bits and amount of time required to verify a signature for a single bit can be reduced further by using a rooted tree in which each node is the one-way compression function of all its direct descendants; only a digital signature of each participant's root need be agreed on before use of the keys comprising the leaves. 3. Relation to Previous Work There is another multiparty-secure sender-untraceability protocol in the literature [1]. To facilitate comparison, it will be called a mix-net here, while the protocol of the present work is called a dc-net. The mix-net approach relies on the security of a true public-key system (and possibly also of a conventional cryptosystem), and is thus at best computationally secure; the dc-net approach can use unconditional secrecy channels to provide an unconditionally secure untraceable- sender system, or can use public-key distribution to provide a computationally secure system (as described in Section 2.1). Under some trust assumptions and channel limitations, however, mix-nets can operate where dc-nets cannot. Suppose that a subset of participants is trusted by every other participant not to collude and that the bandwidth of at least some participants' channels to the trusted subset is incapable of handling the total message traffic. Then mix-nets may operate quite satisfactorily, but dc-nets will be unable to protect fully each participant's untraceability. Mix-nets can also provide recipient untraceability in this communication environment, even though there is insufficient bandwidth for use of the broadcast approach (mentioned in Section 2.4). If optimal protection against collusion is to be provided and the crypto-security of mix-nets is acceptable, a choice between mix-nets and dc-nets may depend on the nature of the traffic. With a mail-like system that requires only periodic deliveries, and where the average number of messages per interval is relatively large, mix-nets may be suitable. When messages must be delivered continually and there is no time for batching large numbers of them, dc-nets appear preferable. 4. Conclusion This solution to the dining cryptographers problem demonstrates that unconditional secrecy channels can be used to construct an unconditional sender-untraceability channel. It also shows that a public-key distribution system can be used to construct a computationally secure sender-untraceability channel. The approach appears able to satisfy a wide range of practical concerns. Acknowledgments I am pleased to thank Jurjen Bos, Gilles Brassard, Jan-Hendrik Evertse, and the untraceable referees for all their help in revising this article. It is also a pleasure to thank, as in the original version that was distributed at Crypto 84, Whitfield Diffie, Ron Rivest, and Gus Simmons for some stimulating dinner-table conversations. References [1] Chaum, D., Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms, Communications of the ACM, vol. 24, no. 2, February 1981, pp. 84-88. [2] Chaum, D., Security Without Identification: Transaction Systems to Make Big Brother Obsolete, Communications of the ACM, vol. 28, no. 10, October 1985, pp. 1030-1044. [3] Diffie, W., and Hellman, M.E., New Directions in Cryptography, IEEE Transactions on Information Theory, vol. 22, no. 6, November 1976, pp. 644-654. [4] Merkle, R.C., Secure Communication over Insecure Channels, Communications of the ACM, vol. 21, no. 4, 1978, pp. 294-299. [5] Tanenbaum, A.S., Computer Networks, Prentice Hall, Englewood Cliffs, New Jersey, 1981. [End of Transmission] -- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eli Brandt Date: Fri, 11 Dec 92 15:39:32 PST To: cypherpunks@toad.com Subject: YA remailer Message-ID: <9212112339.AA11270@toad.com> MIME-Version: 1.0 Content-Type: text/plain I have a Hal-standard remailer running at this address, ebrandt@jarthur.claremont.edu -- haven't compiled PGP on this silly Sequent box yet, so no ARA's. PGP 2 key by finger or e-mail (and finger works now) Eli ebrandt@jarthur.claremont.edu From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Bill O'Hanlon Date: Fri, 11 Dec 92 18:27:14 PST To: cypherpunks@toad.com Subject: keys for me and remailer@rebma.mn.org Message-ID: MIME-Version: 1.0 Content-Type: text/plain I don't know how much use this is, since no one has signed my key, but here it is, plus the key for the remailer here at rebma, signed by me. If anyone is going to be in the Minneapolis area, lemme know. Here's mine: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.1 mQCNAirR6jkAAAEEAOMZFXG8bGGSpctmszxLug8IoLi55pUy+gR81K6ZBfLOmrTh XCeuSBZ+yi6IZXuabOTsKo9r6wHVAvumZlfMvcp9Jbasp6Lc756aacsatHYsiQR4 7feUmp/coOyZ4ZfAXCmapc3dozYB9vWoWMhQy8QmWhotR8zTLRlm7A4meZALAAUR tCBXYXJyaW9yIDx3bW9AcmVibWEubW4ub3JnPiBrZXkgMg== =3/XA -----END PGP PUBLIC KEY BLOCK----- And here's the remailers: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.1 mQCNAisUI2QAAAEEAKgm07Hsje5KpmXYd5azk0R6AES+qK7LcofnVGojUs7GBghD WbwrmW8oOEOhRorlShRALKeYspV4xYIw4WDkJcJxuf1B254scz1urF/Eem3zPW9b yPAx7W/cGwvs6SouZvFcSDq4v1zApvGE9hP4szPzHeGmVr0NVNeaDK0guoCpAAUR tCBSZW1haWxlciAocmVtYWlsZXJAcmVibWEubW4ub3JnKYkAlQIFECsUJGEYkFR3 jlSfhwEB1zgD/1LG9DttNEVPFddxkULPw+AkkbmSolrqJUmVx/3y3QS1AtW+vVqF 0yhgWgvg770b7+xMnwzO/I1nh0FK2shd1Jkx4FVCA5ctyqUzVFjk1NE6VaaRc5Bv BD1nUxtUheR0WXDc50f+ANHgRNkx22MGRvphseMyXq/Ok88opSn7DIrO =nBQt -----END PGP PUBLIC KEY BLOCK----- -- Bill O'Hanlon wmo@rebma.mn.org From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Sat, 12 Dec 92 09:50:58 PST To: cypherpunks@toad.com Subject: (fwd) EFFector Online 4.00 Message-ID: <9212121749.AA20077@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Organization: Netcom - Online Communication Services (408 241-9760 guest) Cypherpunks, Here's the latest EFFector Online, which happens to have stuff about two of us, John Gilmore and me, and which mentions Tom Jennings! No mention of our little group, yet, but I expect we can't hide for long. --Tim May From: rita@eff.org (Rita Marie Rouvalis) Subject: EFFector Online 4.00 Followup-To: comp.org.eff.talk Originator: rita@eff.org Keywords: crypto, nsa, pioneer wards Organization: Electronic Frontier Foundation Date: Fri, 11 Dec 1992 20:00:04 GMT ########## ########## ########## | ########## ########## ########## | GILMORE VS. THE NSA #### #### #### | ######## ######## ######## | ######## ######## ######## | THE CRYPTO ANARCHIST MANIFESTO #### #### #### | ########## #### #### | 2nd PIONEER AWARDS DEADLINE LOOMS ########## #### #### | ===================================================================== EFFector Online December 11, 1992 Issue 4.00 A Publication of the Electronic Frontier Foundation ISSN 1062-9424 ===================================================================== ACCESSING THE NSA JOHN GILMORE FILES SUIT WITH THE NATIONAL SECURITY AGENCY At the beginning of July 1992, John Gilmore filed a FOIA request with NSA asking for access to parts of cryptologic treatises written by NSA personnel: Military Cryptanalysis, Parts III and IV, by William Friedman (WF-3/4); and Military Cryptanalytics, Parts III-VI, by William Friedman and Lambros Callimahos (LC3-6). Parts I and II of each of these treatises had already been declassified and published. At the time of the request, it was not definitely known whether the parts requested by Gilmore had been re-classified. Under the FOIA, agencies are required to communicate responses to requesters within statutorily prescribed time periods. Failure to comply with the time limits for response constitutes a denial of the request, giving the requester the right to appeal. When NSA violated the first applicable time period, Gilmore filed an administrative appeal with the NSA's FOIA appeals authority. There is also a time limit for response to such appeals. After this time limit passed without a response from the NSA's appeals authority, Gilmore filed a complaint in federal court in the Northern District of California on Sept. 4, 1992, as permitted by the FOIA. Gilmore's complaint alleged three claims: First, that the NSA improperly withheld these documents from him, and had no legal basis for withholding; second, that the NSA's failure to comply with the FOIA time limits constituted a form of improper withholding; and third, that the NSA in general engages in an illegal pattern or practice of routinely violating the FOIA time limits, which should be declared illegal and enjoined. In the period between the initial FOIA request to NSA, and the filing of the complaint in federal court, Gilmore obtained copies of two of the withheld documents: Military Cryptanalysis Parts III and IV, by Friedman. These copies were discovered in libraries accessible to the general public and were provided by these libraries without any kind of restriction. Gilmore intended to get expert opinion on the national security risk posed by disclosure of these documents. He also reasoned that their very availability in such libraries demonstrated that there could be no legal basis for withholding them from a FOIA requester. At the time the documents were obtained, Gilmore had not received any indication from NSA that the documents were classified. It was therefore possible that the documents were not, in fact, classified. In addition, FOIA requests for documents generally trigger agency declassification review. Thus, even if the documents were in fact classified at the time of the request, it was possible that NSA would decide that they should no longer be classified, and release them to Gilmore. After the complaint was filed, Gilmore not only served the complaint upon NSA, he also served a number of discovery requests upon NSA, seeking to discover information about both the history of these documents and about NSA's FOIA processing procedures. In early October, after NSA had received the complaint and the discovery requests, NSA finally sent its responses to the FOIA request. NSA informed Gilmore that the documents were not going to be released to him. NSA said that it had located WF-3/4 and LC-3, but that LC-4/5/6 had never been completed because of the death of Lambros Callimahos. First, NSA asserted that the three documents which did exist were classified. WF-3/4 were classified CONFIDENTIAL, the lowest level of classification under Executive Order 12,356 governing classified information. LC-3 was classified SECRET, the middle level of classification. Under the FOIA, an agency may withhold documents if they are properly classified for reasons of national security. Second, NSA asserted that the documents could also be withheld under a different exemption in the FOIA. Under the (b)(3) exemption, documents may be withheld if there exists a statute which authorizes an agency to withhold them. NSA pointed to several statutes which arguably covered this material. One of these statutes, 18 U.S.C. Section 798, makes it a federal crime knowingly to disclose classified cryptologic or communications intelligence information to unauthorized persons. At this point, it became clear to Gilmore that there was a problem. He now knew for a fact that the documents he had were classified (WF-3/4) and that it would be a crime for him to disseminate them. He could no longer continue with his plan of showing them to other persons for fear of criminal prosecution. He also feared that should NSA ever discover that he possessed them, he would be subjected to search and seizure and the copies confiscated. (Note that although the First Amendment Privacy Protection Act generally protects the press against search and seizure for materials intended for publication where the crime involves mere possession or dissemination of information, it does not apply to any materials covered by the espionage statutes, of which 18 U.S.C. Section 798 is one.) NSA did not, however, know that he had them. Gilmore decided that the best course of action was to submit copies of WF-3/4 to the federal district court under seal. By so doing, he would ensure that at least these copies would be kept out of the NSA's hands, since it was unlikely that a federal judge would relinquish possession of documents material to pending litigation. Thus, on November 12, Gilmore made an ex parte application to file these documents under seal with Judge Thelton Henderson, the federal judge hearing his case. Gilmore also concurrently filed a motion for leave to amend his original complaint in order to address the constitutional and other issues arising from his possession of the documents and the criminality of disseminating documents found in libraries open to the general public. It is important to realize that the criminal statute at issue here does not recognize improper classification as a defense. Under existing law, the government need only show that the documents were classified by the government, and that they are cryptologic- or communications-intelligence-related. It remains unclear precisely what the specific requirement under the statute is, i.e., whether "knowingly" means actual knowledge of classification, or merely some reason to know. (That same day, NSA filed two motions of its own: a motion for a protective order blocking Gilmore's discovery requests, and a motion for summary judgment asking the court to dispose of the case on the ground that NSA was entitled to judgment as a matter of law. In support of its summary judgment motion, NSA filed a sworn declaration by Michael Smith, Chief of Policy, explaining why the documents should be withheld, and why NSA's FOIA processing procedures were not illegal.) NSA was served with papers indicating that WF-3/4 had been received by the district court. This was the first time that NSA knew that Gilmore possessed the documents. They reacted strongly. John Martin, the Justice Department lawyer representing NSA, asked that Gilmore surrender his copies to NSA, saying that NSA was very upset and might send its own agents or FBI agents to get the copies from Gilmore. He also wanted to know where Gilmore got them. Martin also suggested that Gilmore might be criminally liable under the espionage statutes relating to possession of national defense information. NSA regained its composure the next day, realizing that it did not know exactly what Gilmore had. Although NSA had been served with papers indicating what Gilmore had done, Gilmore had not sent them copies of the documents. Thus they could not know for sure whether the documents he had were the ones they considered classified. Gilmore agreed to send copies of his copies to NSA for their review, after which NSA would decide what to do. During this period, tension was high. Gilmore considered filing an ex parte motion for a temporary restraining order against NSA and the U.S. Attorney General to prevent them from both moving against him personally and against any copies of the documents presently on library shelves. This motion was drafted but never filed. On the day before Thanksgiving, NSA announced that WF-3/4 would be declassified, and effectively renounced any claim that it could withhold them from the public. NSA gave no official reason for its action. NSA is currently reviewing the third document, LC-3, to see how much of it can be released now that WF-3/4 have been declassified. (NSA had asserted in its summary judgment papers that LC-3 was based on WF-3/4.) NSA's review is to be completed by January 15, 1993, at which time it will release an edited version of LC-3 to Gilmore. It is anticipated that this edited version of LC-3 will be analyzed by Gilmore and his experts, and that Gilmore and NSA will engage in settlement negotiations to determine whether NSA has satisfied Gilmore's request. The settlement discussions will also include Gilmore's claims regarding NSA's FOIA processing procedures. The parties have stipulated that if no settlement is reached the litigation will proceed. A status conference has been set for February 9. NSA will, if necessary, file an amended motion for summary judgment by February 12. Following opposition and reply briefs, the hearing on all motions will take place on March 22. [John Gilmore is a member of the EFF Board of Directors. He can reached as gnu@cygnus.com. Gilmore's lawyer, Lee Tien, can be reached as tien@toad.com.] -==--==--==-<>-==--==--==- THE CRYPTO ANARCHIST MANIFESTO by Timothy C. May (tcmay@netcom.com) A specter is haunting the modern world, the specter of crypto anarchy. Computer technology is on the verge of providing the ability for individuals and groups to communicate and interact with each other in a totally anonymous manner. Two persons may exchange messages, conduct business, and negotiate electronic contracts without ever knowing the True Name, or legal identity, of the other. Interactions over networks will be untraceable, via extensive re- routing of encrypted packets and tamper-proof boxes which implement cryptographic protocols with nearly perfect assurance against any tampering. Reputations will be of central importance, far more important in dealings than even the credit ratings of today. These developments will alter completely the nature of government regulation, the ability to tax and control economic interactions, the ability to keep information secret, and will even alter the nature of trust and reputation. The technology for this revolution--and it surely will be both a social and economic revolution--has existed in theory for the past decade. The methods are based upon public-key encryption, zero-knowledge interactive proof systems, and various software protocols for interaction, authentication, and verification. The focus has until now been on academic conferences in Europe and the U.S., conferences monitored closely by the National Security Agency. But only recently have computer networks and personal computers attained sufficient speed to make the ideas practically realizable. And the next ten years will bring enough additional speed to make the ideas economically feasible and essentially unstoppable. High-speed networks, ISDN, tamper-proof boxes, smart cards, satellites, Ku-band transmitters, multi-MIPS personal computers, and encryption chips now under development will be some of the enabling technologies. The State will of course try to slow or halt the spread of this technology, citing national security concerns, use of the technology by drug dealers and tax evaders, and fears of societal disintegration. Many of these concerns will be valid; crypto anarchy will allow national secrets to be traded freely and will allow illicit and stolen materials to be traded. An anonymous computerized market will even make possible abhorrent markets for assassinations and extortion. Various criminal and foreign elements will be active users of CryptoNet. But this will not halt the spread of crypto anarchy. Just as the technology of printing altered and reduced the power of medieval guilds and the social power structure, so too will cryptologic methods fundamentally alter the nature of corporations and of government interference in economic transactions. Combined with emerging information markets, crypto anarchy will create a liquid market for any and all material which can be put into words and pictures. And just as a seemingly minor invention like barbed wire made possible the fencing-off of vast ranches and farms, thus altering forever the concepts of land and property rights in the frontier West, so too will the seemingly minor discovery out of an arcane branch of mathematics come to be the wire clippers which dismantle the barbed wire around intellectual property. Arise, you have nothing to lose but your barbed wire fences! -==--==--==-<>-==--==--==- Date: Wed, 02 Dec 92 21:31:47 -0800 From: haynes@cats.UCSC.EDU (Jim Haynes) Newsgroups: comp.dcom.telecom Subject: Historical Note on Telecom Privacy Apropos of all the talk on FBI wiretapping, cellular eavesdropping, etc., I found this passage in "Old Wires and New Waves"; Alvin F. Harlow; 1936. He's writing about unscrupulous telegraph operators in the early days. They would use information in telegrams for personal gain, or delay messages or news for personal gain, or sell news reports to non-subscribers of the press association. "Pennsylvania passed a law in 1851, making telegrams secret, to prevent betrayal of private affairs by operators. When, therefore, an operator was called into court in Philadelphia a little later, and ordered to produce certain telegrams which would prove an act of fraud, he refused to do so, saying that the state law forbade it. The circuit court, shocked at this development, proceeded to override the law, saying: It must be apparent that, if we adopt this construction of the law, the telegraph may be used with the most absolute security for purposes destructive to the well-being of society - a state of things rendering its absolute usefulness at least questionable. The correspondence of the traitor, the murderer, the robber and the swindler, by means of which their crimes and frauds could be the more readily accomplished and their detection and punishment avoided, would become things so sacred that they never could be accessible to the public justice, however deep might be the public interest involved in their production. The judge therefore ordered the operator to produce the telegrams." -==--==--==-<>-==--==--==- THE SECOND ANNUAL INTERNATIONAL EFF PIONEER AWARDS: CALL FOR NOMINATIONS Deadline: December 31,1992 In every field of human endeavor,there are those dedicated to expanding knowledge,freedom,efficiency and utility. Along the electronic frontier, this is especially true. To recognize this,the Electronic Frontier Foundation has established the Pioneer Awards for deserving individuals and organizations. The Pioneer Awards are international and nominations are open to all. In March of 1992, the first EFF Pioneer Awards were given in Washington D.C. The winners were: Douglas C. Engelbart of Fremont, California; Robert Kahn of Reston, Virginia; Jim Warren of Woodside, California; Tom Jennings of San Francisco, California; and Andrzej Smereczynski of Warsaw, Poland. The Second Annual Pioneer Awards will be given in San Francisco, California at the 3rd Conference on Computers, Freedom, and Privacy in March of 1993. All valid nominations will be reviewed by a panel of impartial judges chosen for their knowledge of computer-based communications and the technical, legal, and social issues involved in networking. There are no specific categories for the Pioneer Awards, but the following guidelines apply: 1) The nominees must have made a substantial contribution to the health, growth, accessibility, or freedom of computer-based communications. 2) The contribution may be technical, social, economic or cultural. 3) Nominations may be of individuals, systems, or organizations in the private or public sectors. 4) Nominations are open to all, and you may nominate more than one recipient. You may nominate yourself or your organization. 5) All nominations, to be valid, must contain your reasons, however brief, on why you are nominating the individual or organization, along with a means of contacting the nominee, and your own contact number. No anonymous nominations will be allowed. 6) Every person or organization, with the single exception of EFF staff members, are eligible for Pioneer Awards. 7) Persons or representatives of organizations receiving a Pioneer Award will be invited to attend the ceremony at the Foundation's expense. You may nominate as many as you wish, but please use one form per nomination. You may return the forms to us via email to pioneer@eff.org You may mail them to us at: Pioneer Awards, EFF, 155 Second Street Cambridge MA 02141. You may FAX them to us at: +1 617 864 0866 Just tell us the name of the nominee, the phone number or email address at which the nominee can be reached, and, most important, why you feel the nominee deserves the award. You may attach supporting documentation. Please include your own name, address, and phone number. We're looking for the Pioneers of the Electronic Frontier that have made and are making a difference. Thanks for helping us find them, The Electronic Frontier Foundation -------EFF Pioneer Awards Nomination Form------ Please return to the Electronic Frontier Foundation via email to: pioneer@eff.org via surface mail to EFF 155 Second Street, Cambridge, MA 02141 USA; via FAX to +1 617 864 0866 Nominee: Title: Company/Organization: Contact number or email address: Reason for nomination: Your name and contact information: Extra documentation attached: DEADLINE: ALL NOMINATIONS MUST BE RECEIVE BY THE ELECTRONIC FRONTIER FOUNDATION BY MIDNIGHT, EASTERN STANDARD TIME U.S., DECEMBER 31,1992. -==--==--==-<>-==--==--==- MEMBERSHIP IN THE ELECTRONIC FRONTIER FOUNDATION If you support our goals and our work, you can show that support by becoming a member now. Members receive our bi-weekly electronic newsletter, EFFector Online, the @eff.org newsletter and special releases and other notices on our activities. But because we believe that support should be freely given, you can receive these things even if you do not elect to become a member. Our memberships are $20.00 per year for students, $40.00 per year for regular members. You may, of course, donate more if you wish. Our privacy policy: The Electronic Frontier Foundation will never, under any circumstances, sell any part of its membership list. We will, from time to time, share this list with other non-profit organizations whose work we determine to be in line with our goals. If you do not grant explicit permission, we assume that you do not wish your membership disclosed to any group for any reason. ---------------- EFF MEMBERSHIP FORM --------------- Mail to: The Electronic Frontier Foundation, Inc. 155 Second St. #40 Cambridge, MA 02141 I wish to become a member of the EFF I enclose:$__________ $20.00 (student or low income membership) $40.00 (regular membership) $100.00(Corporate or company membership. This allows any organization to become a member of EFF. It allows such an organization, if it wishes to designate up to five individuals within the organization as members.) I enclose an additional donation of $ Name: Organization: Address: City or Town: State: Zip: Phone:( ) (optional) FAX:( ) (optional) Email address: I enclose a check [ ] . Please charge my membership in the amount of $ to my Mastercard [ ] Visa [ ] American Express [ ] Number: Expiration date: Signature: Date: I hereby grant permission to the EFF to share my name with other non-profit groups from time to time as it deems appropriate [ ] . Initials: Your membership/donation is fully tax deductible. ===================================================================== EFFector Online is published by The Electronic Frontier Foundation 155 Second Street, Cambridge MA 02141 Phone: +1 617 864 0665 FAX: +1 617 864 0866 Internet Address: eff@eff.org Reproduction of this publication in electronic media is encouraged. Signed articles do not necessarily represent the view of the EFF. To reproduce signed articles individually, please contact the authors for their express permission. ===================================================================== This newsletter is printed on 100% recycled electrons. -- Rita Rouvalis Electronic Frontier Foundation rita@eff.org eff@eff.org CIS:70007,5621 (617)864-0665 -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nobody@soda.berkeley.edu Date: Sat, 12 Dec 92 14:25:21 PST To: cypherpunks@toad.com Subject: no subject (file transmission) Message-ID: <9212122224.AA04784@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Cypherpunks! Like several people (I guess), I am working on an implementation of digital cash. Because of the possible legal repurcussions, I'd prefer to remain anonymous at this time. Thanks to the efforts of the people on this list, this is now possible. My implementation is pretty far along. It uses PGP modules for the arithmetic, so the speed is good. It works on Unix and I should be able to get it working on MSDOS in a day or two. Sorry, I don't have the ability to work on a Mac version. Here are some of the features. The basic cash algorithm is the Chaum system which was posted here. Multiple denominations are supported, using different exponents for each denomination. The program is presented in the context of a package to be used for an email based game like Monopoly where the program would be used to allow cash transfers. One player is the "banker", and he uses a different execution module than the other players. The banker program keeps a database of used note numbers which is used to detect money reuse. The database is maintained using a freeware version of the "dbm" package, so it should be fast even for large note number databases. The mapping between exponents and values is as follows: exponent value 17 1 19 2 23 5 29 10 31 20 37 50 41 100 43 200 47 500 53 1000 59 2000 61 5000 67 10000 and so on, up to a value of 2e9. The exponents are ascending primes starting with 17. This was chosen because you want them to be smallish for fast note checking, but it was too slow to find primes p and q for the bank key such that (p-1)(q-1) was not divisible by any small primes. The program chooses random p and then tests p-1 to make sure it passes the divisibility test, and rejects it if not. Too many were being rejected when I started with an exponent of 3. Starting with 17 rejects about 1/2 the exponents, compared to something like 80% when I started with 3. The "value" fields are presumed to be cents, but could be whatever you like. The code I've written does not do anything other than the basic electronic cash algorithms. It does not do bank account maintenance. It doesn't do PGP encryption. It doesn't send mail. (It does have some functions to scan and check the files created by the program.) Cash generation is a 3 step process. First, the user creates what I call a "withdrawal request" packet. This is a set of triplets of the form (e, s, refx), where e is the exponent from the table above, s is a 16-byte "unique identifier" used solely to link these withdrawal requests with the returned messages from the bank, and refx is r^e * f(x). f(x) is MD5 of x, padded to the size of the bank's modulus n using the PGP routine which pads MD5 signatures. This padding helps make sure the arithmetic is more "mixing". x is the random input to MD5, which I've chosen as 64 bytes since that is the block size MD5 works on. (The output of MD5 is 16 bytes.) r is the blinding factor. This is now 128 bits long; longer r's take too long to calculate r^-1 in the third step, below. (It takes longer for PGP to calculate r^-1 than to do an RSA decryption, for r = n = 1024 bits!) Second, the bank program converts the withdrawal request packet into what I call a "withdrawal" packet, by just RSA-decrypting the third entry using the inverse exponent "d" for the value exponent "e". (These "d" values are calculated at keygen time and stored with the bank's key information in a private file.) I call the return triplet (e, s, rfxd), where e is the value exponent again, s is the same unique identifier, and rfxd is r * f(x)^d. (As I said above, the code I've written does not try to maintain account balances or do any other banking functions. It just does the cash algorithms. There is a routine to scan a withdrawal request and return the total value being requested for withdrawal. The idea was that this could be used as input to a banking program to decide whether to allow the withdrawal.) Third, the "player" (e.g. user) program transforms the withdrawal packet into a "money" packet, by un-blinding it. To do this, it has to recover the x and r which correspond with each triplet. This is done by the use of a dbm database of "pending withdrawal requests" which is written during step 1, above. The database entries are keyed by (e, s) and return the corresponding (x, r) which were generated during step 1. Using x and r, the user transforms (e, s, rfxd) into (e, x, fxd), the digital cash. e is the value exponent, x is the random 64-byte number, and fxd is f(x)^d, the signed version of the MD5'd and padded x. There are also player functions to scan and check a money file (comparing a calculated f(x) to fxd^e), merge money files, and extract some items from a money file into another money file (this last is what is to be used for payment). There are banker functions to check incoming money and compare against the used-note database, and to add incoming money to that database. (The database consists of the 16-byte f(x) values for each note.) I am pretty happy with the basic routines, but the user interface needs work. There are three kinds of files floating around (withdrawal requests, withdrawals, and money files) and I'm worried that this will be confusing to the user. If he accidentally deletes one at the wrong time he could lose money permanently. Or if he accidentally reuses one he could be accused of fraud. I'm not sure what the best model is for the user. The specific issues of creating withdrawal messages and extracting "bills" from a money file are areas where the user interface should be made nice. We want to make it easy for the user to specify exactly what denominations he wants to work with. One possibility is to simply have him input the amount (e.g. $10.55) and the program calculates that that's a 1000, a 50, and a 5, but this isn't really flexible enough. A nice system would be to give him a list of options and let him fill out a form on-screen, but that's hard to do portably. Another idea I've had is that there should be a special money file called the user's "wallet" which is the default place where incoming money from the bank should go. This might help organize things. He still needs to be able to create other money files for paying other people, and remembering to delete them after he sends them. Any suggestions or thoughts on these interface issues, or comments about how this program could or should be integrated into a larger system, would be appreciated. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAisiUPkAAAED/i1Pf1DaubveDsgjh360rNJ7kWkhssobaVmmWa70l4lOTwy/ sGwhJaA+JdScO9g3B66DIAaU0GiNrTS4YEl/b5ohNDZFdqKlxZ7NW9A5JYjUlhGE a53cRwqUXs42kbPbMh/uKxXBgbUnKrKZnWAh29irDWb+G8OEPQrkCJ6S8691AAUR tAl4UGhhZWRydXM= =HVRq -----END PGP PUBLIC KEY BLOCK----- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: nobody@rebma.rebma.mn.org Date: Sat, 12 Dec 92 14:04:53 PST To: cypherpunks@toad.com Subject: no subject (file transmission) Message-ID: MIME-Version: 1.0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Update on the digital cash project I am having some problems with the port to MSDOS, mostly due to implicitly assuming 32-bit integers in a few places. Probably I won't get it working until next weekend. To recap, the program provides Chaum-style digital cash via two executables, one for the "players" and one for the "banker". The banker creates a public key which has a single modulus n and multiple exponents, the prime numbers starting with 17. He sends n to the players and all is ready. Players withdraw money by running their programs and specifying the denominations they want to withdraw. For example, you could withdraw a 1, two 5's, a 10 and a 20. This would create a file with 5 entries to be sent to the bank. PGP should be used to encrypt and ascii-encode this file (for privacy) and it should be mailed to the banker. The banker receives this file and runs his program to RSA-sign the values in each of the withdrawal-request entries. This is the "blinded cash" that Chaum describes. Again, PGP should be used for mailing this back to the user. The player then has to "unblind" the file to make it "real" digital cash. This also changes it so that the bank won't recognize it when it is deposited. He uses his version of the program to do this, producing an actual digital money file with the five "digital bills" in it. To pay another user, he runs another function to extract the desired bills from this file. Suppose he wants to extract a 1 and a 5. This leaves a 5, a 10 and a 20 in the original file, and creates a new digital cash file with a 1 and a 5. He would then use PGP again to encrypt this for safety and mail it to the person he wants to pay. That person can run a "check" function on the incoming digital money to make sure it has a proper bank signature on it and is not a forgery. He would then mail it directly to the bank so that it could get credited to his account. The banker runs his program which checks the signatures on the incoming money, looks in a database file to make sure these bills haven't been used before, and adds these bills to the database. (The database stores 16 bytes per bill.) He should then record the deposit and perhaps send a confirmation to the depositor (my program doesn't get involved with that). I hope this gives a clearer picture of how the electronic money program works. It is a simple implementation but I think many systems would work similarly. I appreciated the suggestion to use cash as part of the list management itself. Rather than paying people who post, I wonder if it would be better to make people pay to post. Many people have complained about the volume. :) Unfortunately, I suspect that this would involve too much overhead for the mailing list maintainer. Maybe the thing to do is to just get the software out there and let people decide what they want to do with it (if anything). I'm probably going to take a couple more weeks to clean up the user interface and get these bugs out, then I'll try sending it someone to be put on the cypherpunks ftp archive. It's nice to be able to finally sign these messages! - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.1 mQCNAisiUPkAAAED/i1Pf1DaubveDsgjh360rNJ7kWkhssobaVmmWa70l4lOTwy/ sGwhJaA+JdScO9g3B66DIAaU0GiNrTS4YEl/b5ohNDZFdqKlxZ7NW9A5JYjUlhGE a53cRwqUXs42kbPbMh/uKxXBgbUnKrKZnWAh29irDWb+G8OEPQrkCJ6S8691AAUR tAl4UGhhZWRydXM= =HVRq - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBKyZADQrkCJ6S8691AQHneQP8DRdkOFfG9TwjGDJAX4IxymvzAITqYIJC aMhytyzqFwP6Dku955ZHEPL1SDpNCU8DwK7eKDOgvHRS3m+kihs1l6VR3Gf0AgGw 7jjRJlt7hcqfT16fLHVXtn27A16rUhl2hKrD702wjGzX+MN7mS/8MW2kchVfvQYX M/McOuwuIjs= =/HGX -----END PGP SIGNATURE----- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Bill O'Hanlon Date: Sat, 12 Dec 92 15:44:58 PST To: cypherpunks@toad.com Subject: Remailer problem at rebma fixed Message-ID: MIME-Version: 1.0 Content-Type: text/plain My apologies to those who have used PGP with the remailer at rebma over the past week. I upgraded to pgp2.1, and I failed to notice that the PGPPASS environment variable has given way to the -z password option. Users of Hal's remailer scripts take notice. I ran the mail through that had failed, so there might be duplicates of messages sent out, since some people might have resent the message if they didn't see it go by (that is, if they sent it to something where they'd see the result, such as the cypherpunks list.) Sorry for the inconvenience. -Bill -- Bill O'Hanlon wmo@rebma.mn.org From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Sun, 13 Dec 92 11:35:50 PST To: cypherpunks@toad.com Subject: dc-nets implementation (protocol spec) Message-ID: <9212131931.AA13443@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain I am writing a dc-net implementation. What follows is some design discussion, a protocol specification that defines the interaction, message format, and file formats, followed by notes, and plans for future enhancements. A basic familiarity with the concept of dc-nets is assumed, for people new to this, see Chaums's article on the topic, posted here recently. I am assuming interaction through e-mail because this is, right now, the most accessible medium. A more efficient approach would be to use a true broadcast media, such as coax cable, or satellite. But coax only works for local areas, and not everyone has satellite uplink capability. In the future, I envision all or most local area networks running their own small dc-nets that use ethernet broadcast, these being linked hierarchically to medium-level dc-nets that use any internet type of communication medium (udp datagrams, tcp connections, smtp, usenet news, shared ftp space, etc) or other regional communication such as radio (amateur packet radio, spread-spectrum, or even CB) , and these finally being linked into global dc-nets that use satellite broadcast. This type of system would achieve the truly anonymous global communication system, similar to what Vinge describes in True Names: He dumped the last twenty-four hours of the world bulletin board into his home memory space and began checking through it. The bulletin board was ideal for untraceable reception of messages: anyone on Earth could leave a message [...] If a user copied the entire board, and /then/ searched it, there was no outside record of exactly what information he was interested in. There were also simple ways to make nearly untraceable entries on the board. DC-nets will remove the "nearly" from the last sentence. The system I am writing is for research purposes only, I would like to have about 6 to 8 people running it, and then observe it in action. I am not aware of any existing, operational dc-net. If you know of one, please let me know. I would not like to develop a new, incompatible protocol if it is not fundamentally better than something existing. The dc-net system is independent of how the keys are distributed/created. This system assumes that there is already a key stream existing between any two users, that it can use. There are several methods by which keys can be distributed. The most secure would probably be to use a hardware RNG to generate a one-time pad, which is then trasfered by some secure means (exchanged on floppies in person, or put on a 4GB DAT tape (4mm, $20 or less) and sent by some courier service, etc). Another possibility is to use Diffie-Hellman protocol to agree on a set of keys. The simplest method, and one I chose to use in this project, is to generate a random key stream, encrypt it with the other person's public key, sign it with yours, and send it through e-mail. See the next message for details on message formats used for this. Again, the core dc-net system described in this message is in no way dependent on this form of key exchange. Any other key distribution method can be "dropped in" without changing anything. The design document follows: -------------------------------------------------------------------------- ALGORITHM (pseudocode): This algorithm is executed independently by each participant. The list of participants, RBSIZE, and MSGSIZE must be agreed on beforehand. There must be an existing keystream, or a way to receive one. Begin Round (increment round number) Stage 1 (reservation): Take RBSIZE bits off everyone's pad, xor all together. For every message you need to send, reverse a random bit. Sign with your public key, and transmit to all. When received everyone's block, xor all together. If result is all zeros, round ends. Go on to the next round. Stage 2 (transmission): For every '1' bit in reservation block: Begin Message (increment message number) Take MSGSIZE bits off everyone's pad, xor all together. If the bit was reserved by you, xor with your message. Sign with your public key, transmit to all. When received everyone's block, xor all together, getting message. If message was yours, verify it, mark it as sent. If not, it is a message from someone else. Process as an incoming message. End Message (go to next set bit of reservation block if any) End Round (go to next round, optionally delay to save bandwidth) ---------------------------------------------------------------------------- MESSAGE FORMAT: (messages are sent as signed, armored, non-encrypted PGP messages) Subject: dc-net transmission DCNET ; ROUND ; PARTICIPANT ; STAGE [MSG ] ---------------------------------------------------------------------------- FILE FORMATS: dcnet//myname your own participant name for that network dcnet//participants list of participants and addresses in the following format: :
dcnet//pad/ one-time pad for the user, straight 8-bit binary data optionally pgp-encrypted with your public key, signed to prevent disclosure and tampering; these options not implemented yet dcnet//spool// spool where you store responses received, until you receive all of them. Your own responses are stored there too dcnet//outgoing/* messages you need to send, one message per file. should be stored encrypted too. dcnet//incoming program that will process any messages received from this network. In the simplest case this would be a shell script that puts the message to the user's mailbox. But it could also drop it into another net's outgoing directory if it matches some criteria, or it could be posted to a newsgroup, or anything else you want to do. dcnet//log this file contains log of transmissions received times and sizes. it should only contain public information, so it can be posted for analysis of net efficiency, bandwidth used, etc. ------------------------------------------------------------------------ NOTES: I must thank the ILF (Information Liberation Front) for their timely post of Chaum's article. I had started with the two-person example provided in the cypherpunks glossary, and independently extended it to apply to any number of participants, and had progressed up to the idea of hierarchial dc-nets, and was struggling with the question of collision detection, when the article was posted. Chaum's reservation blocks are an elegant and efficient solution. His formal proof of security is also reassuring. RBSIZE is the number of bits in the reservation block. This should be much larger than number of participants, to minimize the chance of two participants randomly reserving the same bit (in which case the transmission has to be retried in the next round). A convenient number to use is 1024 bites (128bytes), if the number of users is small. When operating in idle mode (no messages to be sent), RBSIZE bits are sent to each participant each round. So the total bandwidth used is, assuming 1kbit RBSIZE, 25 participants, and two rounds an hour, about 150 kilobytes per day sent and received by each participant, or about 14 bits per second. This is quite insignificant, considering today's communication equipment. MSGSIZE is the size of a message. This should be about the size of an average message, not the largest one. Making this too large will waste bandwidth. I will use message size of 5kilobytes. This is quite small, but enough for research purposes. This will make the messages several screenfuls long. Longer messages can be split into parts, and reassembled. For example, this message would be split into two parts. For each message that is sent, the number of bytes that every every participant must send and receive is MSGSIZE times the number of participants (using the above assumptions, 125 kilobytes). Using a true broadcast media would dramatically reduce these bandwidth requirements, making large-scale systems with many participants feasible. This implementation uses a to distinguish between separate dc-nets a user may be participating in. A netname can be any string, subject to filename limitations. Keeping them alphanumeric and under 14 chars should work on most machines.. They might also be case insensitive. Netnames do not have to be globally unique, one person just can not be on two nets of the same name. Persons are referenced to by , which would normally be the username but can be an arbitrary string subject to the same limitations. Two perople with the same participand name can not be on one dc-net. Are any of you amateur radio (HAM) operators? I would be interested if this system could be run over packet radio. Are there any regulations against encrypted traffic? ---------------------------------------------------------------------- FUTURE ENHANCEMENTS: In addition to mail-based interaction, usenet newsgroups, ethernet broadcasts, shared ftp access, and tcp connections should be supported. A protocol for dynamically adding participants to the net, removing oneself from the net, or changing the address should exist. A way to deal with malfunctions, such as not receiving a message from a participant. Currently the net will wait forever, for that one message to arrive. A time-out should probably established, after which everyone will re-send their contribution without including the missing person. This is potentially dangerous, since it is equivalent to disclosing that participant's key streams. Since one-time pad is used, this will not compromise earlier communication, but the person must be notified if they ever come back on-line to not use that portion of key again. Support for encrypted and signed storage of keystreams and outgoing messages. A protocol for routing messages between hierarchical dc-nets. Automatic splitting of messages longer than MSGSIZE. A way to indicate the message size in the allocation block, so communications would not be wasted on small messages, and large messages would not have to be split into pieces. ----------------------------------------------------------------------- PLEASE send any comments, criticism, or ideas to: -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tribble@xanadu.com (E. Dean Tribble) Date: Sun, 13 Dec 92 15:48:50 PST To: uunet!tree.egr.uh.edu!barrus@uunet.UU.NET Subject: Electronic P.O.Boxes In-Reply-To: <9212132255.AA13304@tree.egr.uh.edu> Message-ID: <9212132330.AA04018@xanadu.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain The new remailers will support pseudonymous return addresses, but they're not ready yet. dean From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Karl L. Barrus Date: Sun, 13 Dec 92 14:56:08 PST To: hpengwyn@cix.compulink.co.uk Subject: Electronic P.O.Boxes In-Reply-To: Message-ID: <9212132255.AA13304@tree.egr.uh.edu> MIME-Version: 1.0 Content-Type: text/plain John, Thanks for the comments. Right now (as far as I know) the only way to be able to receive "anonymous replies" is for you to include in your message the appropriate header. This is the method I use: create the necessary remailing request to your real mail address, and include that with the instructions on how to use it. For example: ----here is a sample letter---- Hello, This is an anonymous letter and you don't know who I am. To reply, cut everything below the marks, add your text on the end, and send the whole thing to this address: -----cut here----- :: Encrypted: PGP ----cut here---- ----end of the sample letter---- It works! /-----------------------------------\ | Karl L. Barrus | | barrus@tree.egr.uh.edu (NeXTMail) | | elee9sf@menudo.uh.edu | \-----------------------------------/ From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Sun, 13 Dec 92 18:29:13 PST To: cypherpunks@toad.com Subject: Re: Random numbers (and big primes, too!) In-Reply-To: <9212131408.AA00292@britt> Message-ID: <9212140227.AA04427@netcom2.netcom.com> MIME-Version: 1.0 Content-Type: text/plain David Clunie writes: > It would seem to me that someone somewhere should produce a "random > number server" available via a well-known internet port number. Some > natural phenomenon not readily available to all could be used to generate > such numbers and one could just connect and ask for a number. It would be > interesting to try to devise means by which interception or sequencing > could be prevented. Announcing a New Service: "Primes 'r Us" Your full-service crypto dealer. -specializing in selling large primes to those gullible enough to use them -discounts for really big primes! -we can sell you random numbers, too...and we promise not to tell what you bought! Now you can be spared the hassle of generating primes for your RSA algorithms. Now you can let "someone else do the driving." Better yet, Primes 'r Us can handle all your cryptographic needs...we'll generate your primes, computer your keys, and supply your random numbers! -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Sun, 13 Dec 92 15:42:04 PST To: cypherpunks@toad.com Subject: one-time-pad distribution for dc-nets Message-ID: <9212132337.AA20132@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain As mentioned in my previous message, dc-nets need a one-time pad keystream. Of the many methods of accomplishing this, for my experimental dc-net I chose not the most secure method, but the simplest to implement. Recognizing that dc-net users will want to use various key-distribution mechanisms (true one-time pad, with the keys trasnfered over a secure out-of-band channel, diffey-hellmann, etc) I designed the dc-net to be as independent of the key distribution method as possible. The dc-net just reads the keystream from a file, and calls a program when it is about to run out of keys, and needs more. This message describes the method of key distribution I will use. I assume that all participants know each others' public keys, and have verified such by independent means, or they are signed by mutually trusted certifiers. PGP encryption is used to send randomly generated one-time pad. Two participants send keys to each other whenever the remaining key stream reaches below an agreed-upon threshold, then the keys are combined in a pre-determined way (no matter which one sent his message first, the result will be the same). Keys are transferred in large chunks, larger than the normal message size, so that these trasfers would not have to be too frequent. ----------------------------------------------------------------------- MESSAGE FORMAT: (messages are sent as signed, armored encrypted PGP messages) Subject: dc-net transmission DCNET ; PARTICIPANT ; KEYCHUNK ----------------------------------------------------------------------- ALGORITHM: When remaining keystream for on dcnet falls below MINTHRESHOLD, increment keychunk number (n), generate CHUNKSIZE random bits, encrypt and sign them, and send them to the other person. Wait for the other participant's message. Decrypt it, and verify the signature. Compare the two key chunks (the one you sent, and the one you received), and order them by placing the one with lower value first. Append them in the above order to the key file. ------------------------------------------------------------------------ NOTES: If both persons use the same MINTHRESHOLD and CHUNKSIZE, then they should send their messages at approximately the same time, but there is no guarantee of which one will arrive first. If a keychunk is received before one has been sent, one is generated and sent, and then compared to the received key. For the sake of simplicity, I will assume everyone will use the same CHUNKSIZE and MINTHRESHOLD. This is not a requirement, and the proper operation of the system in now way depends on this. The purpose of MINTHRESHOLD is to provide a safety margin, so that key exchange would not interfere with the regular operation of the dc-net. In choosing CHUNKSIZE and MINTHRESHOLD, the basic tradeoff is space versus time. Maximizing these values will reduce the number of transmissions, possibly making more efficient bulk transmission methods possible. But, it will increase the storage requirements of each participant. Each participant will need to store at most (MINTHRESHOLD+CHUNKSIZE) * Each participant will need to obtain new keys approximately every RBSIZE/CHUNKSIZE of idle rounds, or MSGSIZE/CHUNKSIZE of messages transmitted. For this project I will choose a CHUNKSIZE of 75K, allowing for 600 idle rounds, or 15 messages transmitted. MINTHRESHOLD will be 150K. The storage requirements will be about 2 megabytes of a net of 8 participants, or about 5 megabytes for a net of 25 participants. ---------------------------------------------------------------------- FUTURE ENCHANCEMENTS: A more efficient bulk-transfer method may be used, such as dropping the chunks off to a known ftp site. As soon as the chunk is picked up, it is deleted. Many ftp sites have such "temporary", "incoming", or "dropoff" directories. Many sites could be agreed on, in case one fails. All participants should not use the same site, so as not to cause too much load on any single machine. Some method of randomizing the key transfer could be used, so all participants would not run out of keys at the same time, causing unneccessary load on the mail transport system. If a broadcast medium is used, an efficient variant of Diffey-Hellmann can be used, in which each participant needs to generate only one secret random number, and publish the corresponding public value. Then every one can combine it with their secret value, in a way that results in each pair of participants having a common secret key unknown to anyone else. If feasible, one-time-pads can be transferred in person, using floppy disks. -------------------------------------------------------------------- Again, I would appreciate any ideas, comments, suggestions at: -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Sun, 13 Dec 92 16:18:58 PST To: cypherpunks@toad.com Subject: Yes they exist (re: Electronic P.O.Boxes) Message-ID: <9212140014.AA21225@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain Such systems do exist. I have info on one handy, but I know at least one other based on the same software exists in finland. This one seems to be still using pgp2.0, I don't know when they will upgrade to pgp2.1. These remailers assign you a pseudony like anon.19, and anyone can send mail to anon.19@pax.tpa.com.au and the mail will be forwarded to you. Here's the file you can get by sending an empty message to anon.info@pax.tpa.com.au. PAX - Public Access Unix (Adelaide,South Australia) - Anonymous Posting Host ============================================================================ Last modified: Fri Nov 20 18:55:52 CST 1992 Information about Anonymous & Privacy-Enhanced Posting. ======================================================= PAX is conducting research into the viability of anonymous privacy- enhanced mail as a means of providing practical, secure and confidential electronic mail and news. An experimental server has been setup and you are encouraged to use it. There are many anonymous posting services in existence which provide anonymous electronic mail and posting to specific newsgroups where posting is sometimes harmful to one's health or reputation ! Such services allow you to: - post anonymously to those news groups - reply anonymously to posts by email - converse anonymously with another anonymous user, neither of you knowing your real identities Privacy-enhanced electronic mail refers to the concept of encrypting one's mail prior to sending it off into the ether, presumably to someone at the other end capable of decrypting it. If one uses a so-called "public key" method of encryption, then one can make one's "public" key widely known so that anyone can encrypt mail to you, but only you can decrypt it using your "secret" key. There is much development going on in this area, but one quite popular public-domain implementation is Philip Zimmermann's "Pretty Good Privacy 2.0" which makes use of a number of cryptographic methods including the RSA algorithm in places (See Legal Issues later on). PGP allows you to: - exchange public keys with another individual - encode messages to them that only they can read - receive messages from them that only you can read These tools are all very well for the specific purposes for which they were designed, but unfortunately your anonymous message or post is not actually anonymous until it gets to the machine that host's the service. Anyone in between, including your own administrators, can in theory read your post, even though they won't know to whom it is directed. What is more they can also read replies addressed back to you. This can be highly embarrassing at best, and result in dismissal or disconnection at worst if your thoughts, beliefs or activities are disapproved of by the powers that be, even if they are perfectly legal. PAX's privacy-enhanced anonymous services were conceived in the belief that free speech and privacy are fundamental rights and that it is high time the networks to which we are connected provided such services on a routine basis. Seeing as they don't we have to make a start somewhere. This service provides: - conventional anonymous mailing and posting services via a "normal" alias assigned in the usual fashion - the ability to post to ANY newsgroup that is carried out of PAX (which includes most non-regional groups) - PGP 2.0 based privacy-enhanced mail & posting, including: - ability to register your "public" key with PAX, so that PAX can send encrypted messages to you - local generation of a unique public key which is sent to you, so that you can send encrypted messages to PAX - any encoded messages from you mailed to a user or newsgroup are decrypted at PAX before being passed on in anonymous form - any anonymous replies to your "pgp" alias are encrypted before being mailed to you For example, once you have obtained your PGP 2.0 software (as described later) and got it going, and once you have generated and registered your public key and received PAX's key in response, you will be able to post to any newsgroup without anyone beyond your machine having access to the plaintext of your post. Furthermore, if another user has registered in the same manner, and you know their anonymous alias or are responding to one of their anonymous posts, even though you don't know who they are and haven't exchanged keys to communicate directly, the PAX service will automatically decrypt any encrypted messages from you and re-encrypt them before passing them on to the other person ! How to use it. ============== All transactions are handled by email, and commands are selected by the name of the alias to which you mail, not by the subject or body of the message (which are ignored unless sending or posting a message). The separator between the "anon" and the command is a dot (period,'.') and nothing else will work ! Not '-', not '_', not ":", only a dot. The site to address mail is "pax.tpa.com.au". If this fails for some reason, you may need to address it to the specific host (at present) ie. "flash.pax.tpa.com.au". "Normal" (unencrypted) commands: - To get information (this message): mail anon.info@pax.tpa.com.au - To see what your "normal" alias is, or get one: mail anon.ping@pax.tpa.com.au - To send a reply to another anonymous user: mail anon.###@pax.tpa.com.au NB: - eg. mail anon.36@pax.tpa.com.au - don't be creative ... anon.036 won't work - an attempt is made to strip off signature lines by discarding everything after a line starting with "--" or "__" - To send a post to a newsgroup: mail anon.post.groupname@pax.tpa.com.au NB: - eg. "mail anon.post.talk.abortion" will send a post to "talk.abortion" - only the Subject field from your post is used, the rest of the header is discarded - the newsgroup is selected by the alias; Newsgroup header fields are discarded; hence cross-posting isn't feasible - signatures are stripped as above "PGP" (encryption) commands: - To register your public key with PAX: (ABSOLUTELY NECESSARY) mail anon.key@pax.tpa.com.au NB: - first you have to make install pgp and make a key then send it in a "anon.key" command - the body of the message MUST contain an ascii encoded public key generated by PGP V2.0. You may use your regular public key that you give to other people if you wish. The user ID name must be unlikely to conflict with one PAX already has, so use your full name, or include your email address or something. If you want you can use a unique key just for PAX - it makes no difference. If PAX already has a key of the same user-id it will reject yours. Note that this means that you need different key user-id's on different machines (or mail addresses anyway). # makes new keys & adds to your "keyring" pgp -kg Enter a user ID for your public key: First M. Last of somefirm # extract key in ascii form suitable for a message body pgp -kxa "First M. Last of somefirm" savedfile pubring # send it to PAX mail anon.key@pax.tpa.com.au > yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: John Styles Date: Sun, 13 Dec 92 11:52:18 PST To: cypherpunks@toad.com Subject: Electronic P.O.Boxes Message-ID: MIME-Version: 1.0 Content-Type: text/plain Do any of the remailer schemes proposed address the problem of the ability to have replies sent to you without the replier knowing to whom they are replying - this being akin to P.O.Boxes / Magazine box numbers and equivalents. A sample use might be. I wish to send someone a message so I request a box from someone e.g. --- mail to someone@somewhere AllocateBoxTo:hpengwyn@cix.compulink.co.uk --- This would send a code to you identifying a unique box and allowing you to identify yourself (presumably you would want the ability to send this reply by remailer so you are not identifying yourself to the box holder). It would also send a code to you for you to pass on to repliers to your message. You would then post and/or send the message to the person/people you wished to communicate with (this need not be from the same account) passing on the second of these two codes and an address to send messages to (this would presumably be the box holding company unless you wanted the replier not to kno- w who was running the box, as well as not knowing who it is for). They would reply by sending this code and a message to the address given (possibly anonymously of course). This message (probably encrypted) would be held for you - allowing you to receive messages from accounts not even set up at the time you requested the box. You would then get the replies by sending a message e.g. --- mail to someone@somewhere GetReplies
--- Maybe the scheme discussed previously can do all of this (except the ability to have accounts set up after replies have been sent to you) if so please explain how. [I have only recently joined the list] Thanks, John From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Sun, 13 Dec 92 16:39:37 PST To: dclunie@pax.tpa.com.AU (David Clunie) Subject: Re: Random numbers In-Reply-To: <9212131408.AA00292@britt> Message-ID: <9212140035.AA21752@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > It would seem to me that someone somewhere should produce a "random > number server" available via a well-known internet port number. Some > natural phenomenon not readily available to all could be used to generate > such numbers and one could just connect and ask for a number. It would be I would not trust someone to generate random numbers for me. For all you know, they may be recording the date, time, and who is requesting the number, and selling the information to the highest bidder (guess who?). From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Sun, 13 Dec 92 17:04:43 PST To: cypherpunks@toad.com Subject: ps -laxww for randmoness? Message-ID: <9212140100.AA22531@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain How about using ps -laxww as a source of randomness? Of course it would be run throug something like MD5 to get rid of the structure. This would not be good on a multi-user system because ps command may have been modified to log the person invoking it, time, and output to somewhere. But on a personal workstation that you trust, it could be a pretty good source of unpredictable data. This is not my original idea, I think it was suggested in one of the multiple precision math packages I looked at recently. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: wcs@anchor.ho.att.com Date: Sun, 13 Dec 92 19:08:48 PST To: cypherpunks@toad.com Subject: Re: Random numbers (and big primes, too!) Message-ID: <9212140308.AA00536@anchor.ho.att.com> MIME-Version: 1.0 Content-Type: text Timothy May writes: > Announcing a New Service: "Primes 'r Us" > Your full-service crypto dealer. > -specializing in selling large primes to those gullible enough to use them Actually, I may decide to talk my wife into running such a service. It will have at least one customer (me), and any more who want to buy primes or key pairs, given the level of trust we can provide (moderate, but...). Why, you ask? Well, she's about to buy a new computer for her business, as well as personal use, and the amount you can depreciate or expense depends on the percentage of time you've used the machine for business. Calculating primes can take a *large* percentage of your idle time, and what matters for tax purposes are the percentages and whether you do or don't make a profit for the year, not *which* activities of the same business are profitable... Signed, Pat Pending P.S. Yeah, I know, now that I've told you guys the secret, the bottom will drop out of the market because you can generate primes faster on your Cray than we can on a 386. Sigh.... From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Sun, 13 Dec 92 22:51:01 PST To: cypherpunks@toad.com Subject: A minor experimental result Message-ID: <9212140649.AA12228@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain One of the purposes of setting up remailers is to experiment with them, see what kind of emergent behavior appears, see what kind of flaws and obstacles arise, see how they break, etc. Here's one: the compromise of my "anonymity" by one of the folks running a remailer. (Who and where don't matter, just the phenomenon itself.) I used a single bounce without any encryption to send a message and got a query from the owner of the remailer saying "I couldn't help looking through my remailer archives and noticing...." and requesting more information from me!! Hoist by my own petard! Several lessons: * Multiple bounces help, even without encryption, as then the remailer sysop can't be sure who originated the message. * Encryption is of course even more desirable, though a hassle (especially for Mac users). * Remailer sysops should make a point to _not_ look at their remailer archives. In fact, they should discard them immediately (for their own legal protection, and for slightly greater trust amongst users, though this is a hazy area...). (Recall that the "mix" on which our software-based remailers are loosely patterned are "memoryless," i.e., the tamper-resistant modules that implement the receive-decrypt-store-forward protocol have no memory of the mapping between incoming and outgoing messages. In fact, the outside world cannot possibly compromise the protocols to get at this information.) So, my laziness in using only a single bounce, combined with the curiosity of a remailer sysop, breaks the anonymity. Neither surprising nor profound, but I thought you folks would like to know. --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Hal <74076.1041@CompuServe.COM> Date: Sun, 13 Dec 92 20:43:46 PST To: CYPHERPUNKS Subject: dcnets... Message-ID: <921214043710_74076.1041_DHJ56-1@CompuServe.COM> MIME-Version: 1.0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- I thought I would reply here to Yanek's message about dc-nets since it is a topic that should be of interest to the list. I think it's great that someone is going to start experimenting with these systems. The sooner we start playing with this technology, the better. I have a few general comments about the system. First, I like the idea of splitting the key information management from the communication management. That way people can choose their level of security, all the way up to one-time pads if they want. However, I think there should be another system chosen for exchanging key information initially than using PGP to send large one-time pads. Dc-nets really eat up the bandwidth. Yanek estimates using 125 kb per message sent! And having to send one-time key information around doubles the bandwidth. Also, Eric Hughes pointed out to me in private mail once that a system like this for key information exchange is only computationally secure. You are basically relying on RSA and IDEA not to be broken. As long as you're doing that for this initial experiment, why not save yourself a lot of trouble. Just exchange an IDEA (or DES) seed, then cycle it repeatedly through IDEA (or DES), taking the low order bit or few bits as new random ones. If two people have the same seed, they will generate the same random bits. And if IDEA is secure, your bits should be secure. If they aren't, PGP isn't secure. PGP has code to do this. I think it's in the IDEA.C module. Also see strong_pseudorandom in CRYPTO.C. So, I'd suggest that the key exchange part just exchange a short key and then a program generates the new random bits as needed for the messaging. Keep the key stuff separate, though, so people really can do one-time pads if they want to eventually. Another point is the amount of messaging people will do. I think the system should be enhanced to allow people to send and receive messages to/from non-DC-net participants. Otherwise you have 10 or 20 people who hardly know each other. What will they have to say to each other? You won't get a good picture of message loads. I don't foresee everybody in the world being hooked into interlocking DC-nets any time soon (if ever). But I do think there will be DC-nets for some interested people. They will achieve anonymity amongst the group for messages sent beyond the group. In other words, it will be known that a message comes from a certain DC-net group, but it will be impossible to tell which person in the group sent it. Likewise, messages could be sent to a DC-net group without it being known to whom they are sent. I think this capability should be added very soon to the DC-net software. It sounds like the software may include automatic message-sending capability and if so, something which just recognized a special message header and took it as "Request-Remailing-To:" should be easy to add. Likewise, incoming messages to the Dc-net (which would be sent to some random person in the group) should be easily forwardable to the DC-net system from outside. I don't have a clear picture of the user interface from Yanek's description so I'm not sure how easy/hard these would be to do. One other thing I'd mention: the mechanism of reserving a slot and then sending a message is discussed at some length in the Ph.D. thesis of Jurgen Bos. Tim May kindly sent me an excerpt from the thesis which included this discussion; I think it may have been part of the original cypherpunk meeting handout. Bos compares several message reservation schemes and discusses which are the best. It might be good for Yanek to take a look at this document. Yanek asks about sending encrypted traffic over amateur bands. This is definately illegal in the U.S. The reason is that the amateur bands can't be used for commercial purposes, so the FCC demands to be able to know everything that is being sent to make sure this rule is being complied with. However, there are some commercial packet-radio systems starting up and presumably they won't be subject to this limitation. It may not be practical to incorporate all of these suggestions at first, but I do think that using PGP to exchange a RNG seed would be better than using it to exchange one-time pads. I'm looking forward to seeing the system in operation. Hal 74076.1041@compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBKyvk8qgTA69YIUw3AQHyuQP/fXIkyCWR5GCiZsiRvMThcJK5xMbOQEIF ow9S9xQ+7kiiJuF4dVp7NRyNTBjO2tBiQDh4JRKb4Pl7LGq+KKYQSTDzGgEo7hOw dkgujwxbCAXjn2XEMewRHprZMPV4XB+iGIZzQ4piqubzWg8hOV8sMhduGaHKnhGc MlhbbmhToOc= =+cPN -----END PGP SIGNATURE----- Distribution: CYPHERPUNKS >INTERNET:CYPHERPUNKS@TOAD.COM From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: dclunie@pax.tpa.com.AU (David Clunie) Date: Sun, 13 Dec 92 16:09:59 PST To: cypherpunks@toad.com Subject: Re: Random numbers Message-ID: <9212131408.AA00292@britt> MIME-Version: 1.0 Content-Type: text/plain > It has lately been discussed different ways to construct pure > random number generators by means of radiactive decay. I must admit > that this is a very good way to produce such numbers, but for a > number of reasons it is impractical to use such a device. (High > radiation levels are needed too produce a significant amount of data.) > It would seem to me that someone somewhere should produce a "random number server" available via a well-known internet port number. Some natural phenomenon not readily available to all could be used to generate such numbers and one could just connect and ask for a number. It would be interesting to try to devise means by which interception or sequencing could be prevented. david From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: dclunie@pax.tpa.com.AU (David Clunie) Date: Sun, 13 Dec 92 16:10:48 PST To: cypherpunks@toad.com Subject: Re: Paranoia and Cypherpunks Message-ID: <9212131419.AA00298@britt> MIME-Version: 1.0 Content-Type: text/plain > > Headline: "CIA chief hints change needed in ban on probing Americans" > > Excerpts: > WASHINGTON--CIA Director Robert Gates says changes might be > needed in the U.S. law that forbids the agency from collecting > information about Americans or U.S. companies. > Such changes might enable the CIA to better support the > Justice Department and other law enforcement agencies, he said in an > interview with the Associated Press. Juding by what I read in "The Puzzle Palace" the other day, I gather no such ban exists on the NSA doing this. Hardly seems to matter much whether one has two "Big Brothers" watching over use or just one ! And the budget of the NSA is a hell of a lot bigger than the CIA. david From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: "DrZaphod" Date: Mon, 14 Dec 92 10:31:47 PST To: cypherpunks@toad.com Subject: A Quote for the List Message-ID: <19576.drzaphod@ncselxsi> MIME-Version: 1.0 Content-Type: text/plain Here's a quote I snagged off an h/p bbs... thought it was particularly true of cipher-technology as well as computing in general. >>> As life moves to this electronic frontier, politicians and corporations are starting to exert increasing control over the new digital realm, policing information highways with growing strictness. Before we even realise we're there, we may find ourselves boxed into a digital ghetto, denied simple rights of access, while corporations and government agencies make out their territory and roam free. So who will oppose the big guys? Who's going to stand up for our digital civil liberties? Who has the techno-literacy necessary to ask a few pertinent questions about what's going down in cyberspace? Perhaps the people who have been living there the longest might have a few answers. -Mark Bennett <<< TTFN! DrZaphod [AC/DC] / [DnA][HP] [drzaphod@ncselxsi.uucp] Technicolorized From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Liam David Gray Date: Mon, 14 Dec 92 10:32:18 PST To: cypherpunks@toad.com Subject: Re: A minor experimental result In-Reply-To: <9212140649.AA12228@netcom.netcom.com> Message-ID: <4f=97Zm00Uh7Q1WlJ_@andrew.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain Excerpts from Cypherpunks: 13-Dec-92 A minor experimental result by Timothy C. May@netcom.com: > > * Multiple bounces help, even without encryption, as then the remailer > sysop can't be sure who originated the message. > Tim, Please tell me if this makes sense: If I wanted to be obnoxious, I could set myself up as a remailer, then screen all incoming messages to see whether they came from other known remailers. If not, then I can archive the message, have a look at it, and maybe compromise the original sender. Is this so? In this case, everyone wanting to use a remailer should in principle *own* a remailer, and you'd probably want your own to be the first remailer. Then, to avoid compromise of the recipient, maybe you'd want yours to be the last remailer. So why not use your own remailer exclusively? To take this to an extreme, set up a remailer and then use this *all* the time for the mail you originate. Does this gain you anything? Just curious. I'm new on the list and might be missing something. Thanks in advance for replies from anyone. Liam Gray From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Mon, 14 Dec 92 10:31:18 PST To: 74076.1041@CompuServe.COM (Hal) Subject: Re: dcnets... In-Reply-To: <921214043710_74076.1041_DHJ56-1@CompuServe.COM> Message-ID: <9212141634.AA01103@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > I have a few general comments about the system. First, I like the > idea of splitting the key information management from the communication > management. That way people can choose their level of security, all > the way up to one-time pads if they want. I tried to make the system as modular as possible, so any part could be improved or changed with minimal effects on the rest of the system. > Dc-nets really eat up the bandwidth. Yanek estimates using 125 > kb per message sent! And having to send one-time key information This is due to two factors. First, right now there is no way to specify the size of a message. Every message is assumed to be 5K so bandwidth is wasted for any message smaller than that. As I mentioned in "FUTURE ENHANCEMENTS" section, I will make message size be part of the reservation block structure, so small messages will be transferred more efficiently. Second, I am using point-to-point transmission. When I want to broadcast a message, I need to send it individually to each participant. Use of a broadcast media such as ethernet multicast or satellite or radio will dramatically decrease communications load. > as you're doing that for this initial experiment, why not save yourself > a lot of trouble. Just exchange an IDEA (or DES) seed, then cycle it > repeatedly through IDEA (or DES), taking the low order bit or few bits This is a good idea. I will do it this way unless anyone else can see any problems with this. > Another point is the amount of messaging people will do. I think the > system should be enhanced to allow people to send and receive messages > to/from non-DC-net participants. If a broadcast system could be used, anyone that can receive the broadcast will be able to reconstruct the messages, even if they are not participating in the net. If this project works successfully, I will try it using usenet as the medium. So anyone can scan alt.dcnets and get the message. > and if so, something which just recognized a special message header and > took it as "Request-Remailing-To:" should be easy to add. Likewise, Yes it is easy to add. Eventually you will be able to request forwarding to a mail address (or a mix-net remailer), an anonymous post to a usenet newsgroup, or retransmission to another dc-net. The only small problem is that everyone gets the message, and I don't want the message sent out 15 times. So there must be some way to decide who does the remailing. I could just have one person act as the forwarder, but it would be more interesting (and harder to break) if the net somehow dynamically assigned a random forwarder for each message. > incoming messages to the Dc-net (which would be sent to some random > person in the group) should be easily forwardable to the DC-net system Yes. Mix-net remailers could also be participants in a dc-net, so a message could be sent without anyone even knowing which remailer it came from, for people that want untraceability but don't want to or can't participate in a net themselves. > from outside. I don't have a clear picture of the user interface from > Yanek's description so I'm not sure how easy/hard these would be to do. Very easy. To send out a message on a dc-net you just drop it into it's outgoing directory, the next round it gets transmitted. Any messages received are piped to "incoming" program in that dcnet's directory. That program initially will just put the message in your mailbox, but you can make it do anything, such as drop it in another dc-net's incoming directory, or remail it, or post it somewhere. > One other thing I'd mention: the mechanism of reserving a slot and then > sending a message is discussed at some length in the Ph.D. thesis of > Jurgen Bos. Tim May kindly sent me an excerpt from the thesis which > included this discussion; I think it may have been part of the original > cypherpunk meeting handout. Can someone forward it to me? > Yanek asks about sending encrypted traffic over amateur bands. This > is definately illegal in the U.S. The reason is that the amateur bands > can't be used for commercial purposes, so the FCC demands to be able > to know everything that is being sent to make sure this rule is being But the messages become public. Anyone can see what the message is, they just can't see who it came from. If all messages are transmitted as plaintext, it is fairly easy to see that no commercial traffic is occurring. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Hal <74076.1041@CompuServe.COM> Date: Mon, 14 Dec 92 10:31:00 PST To: CYPHERPUNKS Subject: Remailers. Message-ID: <921214165323_74076.1041_DHJ77-1@CompuServe.COM> MIME-Version: 1.0 Content-Type: text/plain Tim's message brings up a point I've been wanting to mention. The prototype remailer software keeps log files of all messages passed through it. There are different reasons why people running the software might wish to have these logs. One purpose is for debugging; the remailers don't produce much in the way of error messages and the log files can be useful for tracking down errors. A few weeks ago, for example, one user was having difficulty sending messages through my remailer, and he posted here about it. I was able to confirm that his messages had come in and been sent out. However, another possible reason is for the case of abusive messages. I had one message go through that appeared to be directed towards the sender's boss, and was rather unfriendly in tone. The remailers give the outgoing messages the superficial appearance of having come from me. This message wasn't that bad, but there's nothing to stop someone from sending a really vicious, racially or sexually harrassing message, and I am very concerned that I could get in trouble for that. What I've generally done is to delete the log files every few days, usually after a quick perusal to see if there are any messages which the recipient might object to. Sometimes if I see a message which is of an illegal format so that it didn't get sent, (like forgetting the ":" in "Request-Remailing-To:") I'll send a message to the sender telling him what he did wrong. I feel that people who run remailers should set their own policies as far as the confidentiality of the messages they forward. Running a remailer can be somewhat risky in the current climate and the operators can legitimately seek whatever level of protection they are comfortable with. However, I think it would be good if the users of the remailers could get some information about what the privacy policies are. Maybe some remailers will simply not keep logs; maybe others will keep logs but not look at them unless a specific circumstance arises, and so on. Eric Hollander has been creating a list of remailers; perhaps he could solicit this kind of information from the operators and publish it along with the remailer addresses and keys. Hal 74076.1041@compuserve.com Distribution: CYPHERPUNKS >INTERNET:CYPHERPUNKS@TOAD.COM From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eli Brandt Date: Mon, 14 Dec 92 13:18:36 PST To: cypherpunks@toad.com Subject: Re: Remailers. In-Reply-To: <921214165323_74076.1041_DHJ77-1@CompuServe.COM> Message-ID: <9212142118.AA03045@toad.com> MIME-Version: 1.0 Content-Type: text/plain > Eric Hollander has been creating a list of remailers; > perhaps he could solicit this kind of information from the operators > and publish it along with the remailer addresses and keys. (Hey, everybody send your remailer information in!) I have been deleting the logs every so often, unread since I debugged the remailer. If someone asks me if their message made it, I'll look at them. If someone gives me evidence of blackmail or the like, I'll look at them. Otherwise, to the bit bucket they go. As usual, you should encrypt your message if you want it to be secure. This is a multi-user system. Furthermore, I may read the remail logs from time to time as I tweak the software. (eg add PGP, if I can fix the "keygen error"...) It may be worth pointing out that this gives me a plausible reason to stonewall if someone comes asking about something *I* sent through my remailer. > Hal Eli ebrandt@jarthur.claremont.edu From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: andrew_derry@sfu.ca Date: Mon, 14 Dec 92 13:48:53 PST To: cypherpunks@toad.com Subject: Re: A minor experimental result Message-ID: <9212142148.AA13622@whistler.sfu.ca> MIME-Version: 1.0 Content-Type: text/plain > If I wanted to be obnoxious, I could set myself up as a remailer, >then screen all incoming messages to see whether they came from other >known remailers. If not, then I can archive the message, have a look at >it, and maybe compromise the original sender. > > Is this so? Seems quite possible to me.. I think that's why it was suggested a while back that as many remailers be set up as possible. That way, one could use several in a row and virtually eliminate the problem. > In this case, everyone wanting to use a remailer should in principle >*own* a remailer, and you'd probably want your own to be the first >remailer. Then, to avoid compromise of the recipient, maybe you'd want >yours to be the last remailer. So why not use your own remailer >exclusively? I don't think you'd have to worry much about compromising the recipient, if you encrypt the message with with her public key (except possibly traffic analysis, which I doubt poses a problem to very many people, and which can be overcome anyways). > To take this to an extreme, set up a remailer and then use this >*all* the time for the mail you originate. Does this gain you anything? Well, it would probably be ok if a lot of other people used your remailer.. but if you were the only one, I doubt it would be very effective. --- Andrew Derry - derry@sfu.ca | ACS@HCC - Simon Fraser University | Standard disclaimers apply | From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Mon, 14 Dec 92 15:43:24 PST To: yanek@novavax.nova.edu Subject: ps -laxww for randmoness? In-Reply-To: <9212140100.AA22531@novavax.nova.edu> Message-ID: <9212141856.AA13053@maggie.shearson.com> MIME-Version: 1.0 Content-Type: text/plain >From: yanek@novavax.nova.edu (Yanek Martinson) >How about using ps -laxww as a source of randomness? Its a rather bad source. Operations of a computer system are suprisingly low on entropy. I'd guess that, if I needed to and had enough resources, I could break such a generator without more than a few months work, and even get the system to break it semi-automatic. No one here seems to think in terms of cryptanalysis and how people do it when they come up with their schemes. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hollander Date: Mon, 14 Dec 92 15:50:57 PST To: Eli Brandt Subject: Re: Remailers. In-Reply-To: <9212142118.AA03045@toad.com> Message-ID: <9212142349.AA29938@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain Since it is possible to archive, I think we should all operate under the assumption that archiving is being done. And if we are operating under that assumption, there is nothing wrong with archiving. This is why multiple, encrypted, and possibly overseases boucnes are so important. The security of remailing doesn't depend on trusting the operators. It relies on there being at least one operator who won't reveal show his logs. If one of your bounces happens to be through your own remailer, you can gaurantee this. e From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: whitaker@eternity.demon.co.uk (Russell E. Whitaker) Date: Mon, 14 Dec 92 13:18:54 PST To: cypherpunks@toad.com Subject: MEETING: 2nd Cypherpunks UK Message-ID: <6405@eternity.demon.co.uk> MIME-Version: 1.0 Content-Type: text/plain [I thought a month's notice on this (second) meeting would draw a little more interest. Our first meeting, 13 December 92, was a good start. -- Russell ;-) ] 2nd Meeting, Cypherpunks UK --------------------------- Chris Tame, of FOREST and the Libertarian Alliance, has generously offered the use of the meeting room at his offices for our gathering, Sunday, 10 January 1993, from 1300 onwards, at: FOREST 4th Floor 2 Grosvenor Gardens London SW1W 0DH 071-823-6550 This is just around the corner from Victoria Station, at the end of the mansion block near Hobart Place. There's a dark green cabbie shelter across the street from the entrance, and some British Telecom payphones. Can't miss it, really. However, if you have trouble, call the telephone number above, or call my pager, on 081-812-2661. If it helps, we're in the direction of Buckingham Palace, which is (very) partially visible from our windows. If you wish to attend, you should bring a 3.5" DOS-formatted diskette (sorry! My UN*X machine is an Intergraph workstation, and I can't use it for crypto) with a copy of your PGP 2.0+ public key. I'll sign it there. Mac users: if you don't have Apple File Exchange (what!?), I'll be extra nice and take your keys anyway ( ;-)) for AFE conversion on my IIcx. Not to fear. It might not be a bad idea to copy your public key on each of several diskettes, so you've got a copy to distribute to each of the others. Don't trust me to copy *your* key to others! As a matter of fact, as there are plenty of power points in the meeting room, you should bring your laptop, and/or a desktop PC: when someone hands you a disk-with-key, you can sign her key, and hand her back her diskette, with your own pubkey added. [Note to the novice: don't hand another person your secret key... the one named secring.pgp.] This should be a lively meeting. Among the topics likely to be discussed are: o The proliferation of PGP public keys in the U.K. o The local development of anonymous remailers and a proposed automatic public key repository at Demon Internet Systems o Electronic networking/email security for the novice o Pro-active proliferation of PGP 2.1+ to interesting European, African, and Asian sites - ftp placement - BBS distribution - sneakernet across borders o The use of HPACK in securing local file installations .. and much more! Mark Turner, from Demon Internet Systems, is likely to be on hand to demo DIS for non-DIS users. We've set up our own local, high-quality newsgroups: demon.security demon.security.keys and established the /pub/ibmpc/pgp archives on gate.demon.co.uk (expanding recently to include all versions of PGP, and "fellow traveller" files). Hope to see you there! Semper vigilans, Semper vigilans, From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: miron@extropia.wimsey.com (Miron Cuperman) Date: Mon, 14 Dec 92 13:55:56 PST To: cypherpunks@toad.com Subject: Re: A minor experimental result In-Reply-To: <9212140649.AA12228@netcom.netcom.com> Message-ID: <1992Dec14.211716.13061@extropia.wimsey.bc.ca> MIME-Version: 1.0 Content-Type: text/plain lg2g+@andrew.cmu.edu (Liam David Gray) writes: > If I wanted to be obnoxious, I could set myself up as a remailer, >then screen all incoming messages to see whether they came from other >known remailers. If not, then I can archive the message, have a look at >it, and maybe compromise the original sender. This is possible only if encryption is not used. With encryption, only the first remailer knows the sender (but not the plaintext or recipient) and only the last remailer knows the recipient (but not the sender or plaintext). -- Miron Cuperman | NeXTmail/mime ok | Public key avail AMIX: MCuperman | cybercomputingimmortallaissezfaire | From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Marc.Ringuette@GS80.SP.CS.CMU.EDU Date: Mon, 14 Dec 92 19:04:59 PST To: cypherpunks@toad.com Subject: Re: Remailers. Message-ID: <9212150304.AA06890@toad.com> MIME-Version: 1.0 Content-Type: text/plain > It relies on there being at least one operator who won't reveal > his logs. If one of your bounces happens to be through your own > remailer, you can guarantee this. Let's be clear on exactly how useful it is to route your messages through your own remailer. It's not as useful as it first appears. If the Awful Nasties convince all of the remailers downstream of yours to give up their logs, they trace the message back to your machine. You then might choose to say, "Hey man, it wasn't my message, it was just my remailer. And I'm not giving you the logs." But if you're going to use this excuse, you needn't really have routed your message through your remailer at all; you just need to be operating a remailer and routinely refuse to divulge its logs. -- Marc Ringuette (mnr@cs.cmu.edu) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Tue, 15 Dec 92 07:56:18 PST To: avalon@coombs.anu.edu.au Subject: Re: ps -laxww for randmoness?timeofday for randmoness In-Reply-To: <9212151530.AA05832@coombs.anu.edu.au> Message-ID: <9212151555.AA10507@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > gettimeofday(&tv, NULL); > rand = tv.tv_usec + tv.tv_sec; Someone trying to break your code could find out approximately when the number was generated, then they would have a much smaller search space to try. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Karl L. Barrus Date: Tue, 15 Dec 92 09:43:54 PST To: cypherpunks@toad.com Subject: remailer extension (contact field) Message-ID: <9212151743.AA20003@tree.egr.uh.edu> MIME-Version: 1.0 Content-Type: text/plain I've added a contact field to my remailer. To contact me (the operator of remailer03 ) you can use the following header: ----cut here---- :: Contact: ----cut here---- Note the colon after contact and the blank line at the end. Encryption of this header is supported as well; you can reach me by encrypting this contact header and doing the usual. For those interested - here are the changes to maildelivery and remail.pl (I haven't been able to study the remailer code much, and am just learning perl, so this can probably be improved.) Changes to maildelivery, before the * on the last line Add the following: (I spaced everything out in the file) Contact "" pipe R remail.pl Contact "" file A archive.remail Add to remail.pl, before the block that begins if (/^Request-Remailing-To:/ || /^Anon-To:/) if (/^Contact:/) { chop ; s/^.*// ; $addressee = $_ ; $addressee = "my.id@some.other.machine" ; } I don't know perl well enough to figure out what can or can't be deleted (specifically the $addressee = $_ line, etc.) /-----------------------------------\ | Karl L. Barrus | | barrus@tree.egr.uh.edu (NeXTMail) | | elee9sf@menudo.uh.edu | \-----------------------------------/ From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: wendtj@jplpost.Jpl.Nasa.Gov (Jeffrey P Wendt) Date: Tue, 15 Dec 92 20:14:52 PST To: cypherpunks@toad.com Subject: Inf0 Message-ID: <9211157244.AA724460817@jplpost.jpl.nasa.gov> MIME-Version: 1.0 Content-Type: text/plain Does anyone know of companies that will sell Tempest shielding to a private citizen, and if so; what regulations and licensing are required to own this equipment. Thanks in advance, JPW ----------------------------------------------------------- JPL: 03-90 - 12-31-92. Goldin + Peace + Politics = Layoff Anyone out there looking for an AA? ----------------------------------------------------------- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: ahawks@nyx.cs.du.edu (zoiks!) Date: Tue, 15 Dec 92 15:58:07 PST To: cypherpunks@toad.com Subject: subscribe Message-ID: <9212152358.AA16200@nyx.cs.du.edu> MIME-Version: 1.0 Content-Type: text/plain Please subscribe me to the list...Heard about it from alt.cp, Mondo, Paco Xander Nathan, and my own FutureCulture list... -- ahawks@nyx.cs.du.edu FutureCulture: In/f0rmation ahawks@mindvox.phantom.com future-request@nyx.cs.du.edu From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) Date: Tue, 15 Dec 92 23:15:59 PST To: avalon@coombs.anu.edu.au Subject: Re: ps -laxww for randmoness? In-Reply-To: <9212151530.AA05832@coombs.anu.edu.au> Message-ID: <9212160715.AA09133@tsx-11.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain From: avalon@coombs.anu.edu.au (Darren Reed) Date: Wed, 16 Dec 92 2:30:49 EST Has anyone tried using the microsecond counter from unix as a random source ? Its obviously *not* going to be good if you want a continuous stream of random numbers, but if you need them just 'every now and then', what about it ? This should be in an FAQ: Unixes have different levels of granularity in the microsecond counter; some systems may only have a 10 ms (that's 10000 microsecond) resolution to their clock. So you can't necessarily depend on a getting lot of bits of randomness from this method. - Ted From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: avalon@coombs.anu.edu.au (Darren Reed) Date: Tue, 15 Dec 92 07:31:35 PST To: cypherpunks@toad.com Subject: Re: ps -laxww for randmoness? In-Reply-To: <9212141856.AA13053@maggie.shearson.com> Message-ID: <9212151530.AA05832@coombs.anu.edu.au> MIME-Version: 1.0 Content-Type: text/plain In some email I received from Perry E. Metzger, Sie wrote: > > > >From: yanek@novavax.nova.edu (Yanek Martinson) > > >How about using ps -laxww as a source of randomness? > > Its a rather bad source. Operations of a computer system are > suprisingly low on entropy. I'd guess that, if I needed to and had > enough resources, I could break such a generator without more than a > few months work, and even get the system to break it semi-automatic. > > No one here seems to think in terms of cryptanalysis and how people do > it when they come up with their schemes. Well whenever I try to come up with some nifty crypto scheme, I always seem to think it is too easy to break if you know its being used but then I dont like doing too much 'expensive' crypting and I usually find some cheap algo which uses a more expensive one for key trading. Has anyone tried using the microsecond counter from unix as a random source ? Its obviously *not* going to be good if you want a continuous stream of random numbers, but if you need them just 'every now and then', what about it ? Something like this would be used: struct timeval tv; long rand; ... gettimeofday(&tv, NULL); rand = tv.tv_usec + tv.tv_sec; ... Very unlikely to get a duplicate, esp. if you dont need the number more often than 1 per second. darren From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: "Mark W. Eichin" Date: Tue, 15 Dec 92 23:46:40 PST To: tytso@ATHENA.MIT.EDU Subject: re: ps -laxww for randmoness? In-Reply-To: <9212160715.AA09133@tsx-11.MIT.EDU> Message-ID: <9212160740.AA04597@tweedledumber.cygnus.com> MIME-Version: 1.0 Content-Type: text/plain Don Davis, of MIT Project Athena, did some research a number of years back on getting good (physical) randomness out of a unix workstation. If I recall correctly, the general idea was to look for trends and biases, find explanations for them, and then filter them out or normalize against them. Sources of "real" nondeterminism came from things like variations in hard drive behavior (such as actual seek time, which shows up indirectly in the paging system because it does or does not cause time delays due to missed sectors...) I don't have a reference handy, but if noone comes up with one I'll send him email and see if he has it online. In other words, 'ps -laxww' itself is relatively useless -- but the underlying data does actually have randomness; you may have to dig pretty hard for it, though. _Mark_ SUB: Re: ps -laxww for randmoness? SUM: , tytso (Theodore Ts'o)->avalon@coombs.anu.edu.au, cypherpunks@toad.com From: avalon@coombs.anu.edu.au (Darren Reed) Date: Wed, 16 Dec 92 2:30:49 EST Has anyone tried using the microsecond counter from unix as a random source ? Its obviously *not* going to be good if you want a continuous stream of random numbers, but if you need them just 'every now and then', what about it ? This should be in an FAQ: Unixes have different levels of granularity in the microsecond counter; some systems may only have a 10 ms (that's 10000 microsecond) resolution to their clock. So you can't necessarily depend on a getting lot of bits of randomness from this method. - Ted From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: avalon@coombs.anu.edu.au (Darren Reed) Date: Tue, 15 Dec 92 09:05:15 PST To: yanek@novavax.nova.edu (Yanek Martinson) Subject: Re: timeofday for randomnessness ? In-Reply-To: <9212151555.AA10507@novavax.nova.edu> Message-ID: <9212151704.AA15303@coombs.anu.edu.au> MIME-Version: 1.0 Content-Type: text/plain In some email I received from Yanek Martinson, Sie wrote: > > > gettimeofday(&tv, NULL); > > rand = tv.tv_usec + tv.tv_sec; > > Someone trying to break your code could find out approximately when > the number was generated, then they would have a much smaller search > space to try. Thats why you change key 'regularly'...even randomly ? Then they have to 'guess' when you change keys. It might be easy to tell when an application starts, but how can you tell exactly or even approximately how long ago someone picked a menu that changed their key or it was otherwise changed ? By using the microsecound counted as a random number, its almost completely random unless you take steps to actually make less so. But a table of the required million entries and 'init' strings wouldn't be too hard for todays computers, hence the use of the time in seconds to 'bump' the offset a bit. For example, if you use a simple xor table for encoding/decoding, its pretty easy to decode. If you change the table after it has been used, every time, then the required time to break the entire message is significantly larger than it would otherwise have been. Can anyone do some maths on exactly how long it would take given a fixed table size (contains random data) ? And also with key/ table changes at a fixed/random interval ? (seems 1:1 :( but I maybe wrong). darren From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: strat@intercon.com (Bob Stratton) Date: Wed, 16 Dec 92 01:44:48 PST To: wendtj@jplpost.jpl.nasa.gov Subject: Inf0 In-Reply-To: <9211157244.AA724460817@jplpost.jpl.nasa.gov> Message-ID: <9212160945.AA16858@intercon.com> MIME-Version: 1.0 Content-Type: text/plain >>>>> wendtj@jplpost.jpl.nasa.gov (Jeffrey P Wendt) writes: Jeffrey> Does anyone know of companies that will Jeffrey> sell Tempest shielding to a private citizen, and if Jeffrey> so; what regulations and licensing are required to Jeffrey> own this equipment. I believe that InterPact, a company operated by Winn Schwartau that also publishes the "Security Insider Report", does this type of work, They're in Houston, I think. --strat From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: treason@gnu.ai.mit.edu Date: Wed, 16 Dec 92 07:34:13 PST To: cypherpunks@toad.com Subject: remailers Message-ID: <9212161534.AA18300@spiff.gnu.ai.mit.edu> MIME-Version: 1.0 Content-Type: text/plain Does anyone have a ongoing list of remailers addresses and functions that they could send me? I haven't had time to compile a list myself, but would appreciate itt greatly if I could get one. Treason From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: karn@qualcomm.com (Phil Karn) Date: Wed, 16 Dec 92 11:48:04 PST To: treason@gnu.ai.mit.edu Subject: Re: tempest devices and use Message-ID: <9212161918.AA03733@servo> MIME-Version: 1.0 Content-Type: text/plain >It is illegal to use any device as a tempest shield, including lead, >tesla coils or any other materials that can possibly interfere with tempest >reception! You need a government license to use these, and then you must have >reason to have such a device(this is how banks can use such things.) Eh? The specific purpose of TEMPESTing a computer that handles classified information is to contain any incidental information- bearing electromagnetic emissions so they cannot be received at a distance. But shielding is not only a security issue, it is also highly desirable to minimize interference to users of the radio spectrum (e.g., broadcast TV sets and radios). Now the FCC Part 15 rules (which govern "incidental radiation devices" such as computers) are much less stringent than TEMPEST, but this is only an economic tradeoff because full TEMPEST-level shielding of a computer can be very expensive. In fact, many classified shops have instead built "screen rooms" (or entire screened buildings, such as those at the NSA) so they can use standard commercial-grade computer hardware. Anyone is free to add as much shielding to their computer equipment or their entire buildings as they want. There's absolutely nothing illegal about it; in fact it's highly commendable to do so. The FCC (and your neighbors) will thank you for it. Now if you wanted to "mask" your computer's RF emanations with some sort of RF noise source (such as a Tesla coil) that's another story. Most transmitters require licenses for the obvious reason that they can interfere with other users of the radio spectrum. But this has nothing to do with your right (or even duty) to shield your computers. Unfortunately the TEMPEST rules themselves are classified, so we really don't know how much shielding is necessary, or what one can pick up from an unshielded system, or exactly how you'd do it. Obviously this is an attempt to protect NSA's own SIGINT methods. But there is, to coin a phrase, "equal protection under the laws of physics". Star Warriors' claims notwithstanding, they're the same for everyone, black (classified) or white, and they're open for all to discover and apply on their own. Phil From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: treason@gnu.ai.mit.edu Date: Wed, 16 Dec 92 08:46:30 PST To: cypherpunks@toad.com Subject: remailers Message-ID: <9212161646.AA18468@spiff.gnu.ai.mit.edu> MIME-Version: 1.0 Content-Type: text/plain I don't know if this message got through, but I'll repost it just in case... What I would like is a list of remailers with maybe a description of the fucntions(non-standard mail) like pgp abilities or whatever. A list of remailers would be good in itself. treason From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: treason@gnu.ai.mit.edu Date: Wed, 16 Dec 92 10:18:50 PST To: cypherpunks@toad.com Subject: tempest devices and use Message-ID: <9212161818.AA18643@spiff.gnu.ai.mit.edu> MIME-Version: 1.0 Content-Type: text/plain For those who are interested in tempest devices and such... It is currently legal to create/buy and use tempest devices for any citizen under any circumstances. It is also legal to sell such devices, with the exception of selling to non US citizens and governments. This is the good news. The bad news is: It is illegal to use any device as a tempest shield, including lead, tesla coils or any other materials that can possibly interfere with tempest reception! You need a government license to use these, and then you must have reason to have such a device(this is how banks can use such things.) I have a few tempests, one with a range of about 200 yards using aricraft vdo's. If anyone wants a file discussing the legal issues of the tempest, please ask, and I'll forward it here. treason@gnu From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Wed, 16 Dec 92 11:16:00 PST To: treason@gnu.ai.mit.edu Subject: Re: tempest devices and use Message-ID: <9212161854.AA08014@maggie.shearson.com> MIME-Version: 1.0 Content-Type: text/plain > From: treason@gnu.ai.mit.edu > > For those who are interested in tempest devices and such... > > It is currently legal to create/buy and use tempest devices for any citizen > under any circumstances. It is also legal to sell such devices, with the > exception of selling to non US citizens and governments. This is the good > news. > > The bad news is: > > It is illegal to use any device as a tempest shield, including lead, > tesla coils or any other materials that can possibly interfere with tempest > reception! You need a government license to use these, and then you must have > reason to have such a device(this is how banks can use such things.) > > I have a few tempests, one with a range of about 200 yards using aricraft > vdo's. If anyone wants a file discussing the legal issues of the tempest, > please ask, and I'll forward it here. This particular bit of garbage is so malodorous that it can't be left unchallenged. There are no rules saying that you can't shield your computer equipment; in fact, there are FCC rules that say that you HAVE to shield it, though you aren't required to do as well as tempest specs, which, to my knowledge, are not even public knowledge. Put up or shut up, Mr. "Treason". Give us one lick of evidence that you know what you are talking about. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: treason@gnu.ai.mit.edu Date: Wed, 16 Dec 92 12:44:26 PST To: cypherpunks@toad.com Subject: tempest file Message-ID: <9212162044.AA19398@spiff.gnu.ai.mit.edu> MIME-Version: 1.0 Content-Type: text/plain I don't know what is in the file entirely, but it looked like the one I have read on the legality of using tempest shields and such. I have other files on the issue as well, I would like you guys to tell me whats you think, and if I should post the others as well. treason@gnu - You have free will, but you will go to hell if you use it! From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: treason@gnu.ai.mit.edu Date: Wed, 16 Dec 92 16:26:15 PST To: cypherpunks@toad.com Subject: files Message-ID: <9212170026.AA20674@spiff.gnu.ai.mit.edu> MIME-Version: 1.0 Content-Type: text/plain Of course half the problems with realistic discussions are aroused by idiots flaming without checking their sources.... treason From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Wed, 16 Dec 92 17:34:17 PST To: cypherpunks@toad.com Subject: INFO: TEMPEST companies Message-ID: <9212170133.AA11380@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain Lindgren RF Enclosures 400 Gigh Grove Blvd. Glendale Heights, IL 60139 Contact: Wayne Martin 708-307-7200 FAX: 708-307-7571 "LT" Series Shielding System is a complete line of modular enclosures, equipment cabinets and custom enclosures available in virtually all shielding materials. The system features exclusive Double Electrically Isolated construction for maximum attenuation. All enclosures are fully tested and guaranteed. Aplication assistance available. Secure Systems & Services Div. of The R/H Factor Corp. 13990 Goldmark Dr., Ste.401 Dallas, TX 75240 Contact: Ray Helsop 214-907-9288 FAX: 214-669-9160 TEMPEST Products, Systems & Services are for Military/Industrial firms concerned with threat of information security and protection by [sic] electronic eavesdroppoing; also commercial EMI/RFI, reduced emissions products. We provide TEMPEST service and support, data encryption, F.I.S.A. Facility Information Security Assessment Studies, site planning, installation design, facility upgrades, etc. International Paper Co. Longmeadow Rd. Tuxedo, NU 10987 Contact: Larry Fahy 914-577-7247 SAF'N SHIELDED (tm) International Paper provides a unique wallcovering that prevents electromagnetic interference (EMI), wireless electronic espionage, and other forms of electromagnetic eavesdropping. The new wallcovering, a composite structure that incorporates a nonwoven mat of metallic fibers, has been TEMPEST-tested by the U.S. government and can achieve attenuation levels over 100dB. The material, which eliminates the added costs of "hardening" or adding protective shielding to individual pieces of electronic equipment, is being used both in primary applications and to upgrade facilities to higher levels of protection. It also provides a way to plug EMI leaks quickly and effectively. Unlike woven or sheet metal, which typically require gutting entire rooms, this flexible, lightweight material goes up as quickly as wallpaper. No special tools are needed, and downtime is minimal. Transaction Security, Inc. 21 Industrial Ave. Upper Saddle River, NJ 07458 Contact: O. Mark Hastings 201-573-1150 Steel TEMPEST-type enclosures for any size computer hardware. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Wed, 16 Dec 92 19:13:38 PST To: treason@gnu.ai.mit.edu Subject: Re: files Message-ID: <9212170234.AA14757@maggie.shearson.com> MIME-Version: 1.0 Content-Type: text/plain > From: treason@gnu.ai.mit.edu > Of course half the problems with realistic discussions are aroused > by idiots flaming without checking their sources.... > > treason Gee, who's the fool claiming that its illegal to RF shield your computer... .pm From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Bill O'Hanlon Date: Wed, 16 Dec 92 22:45:56 PST To: cypherpunks@toad.com Subject: A stupid move Message-ID: MIME-Version: 1.0 Content-Type: text/plain Edgar Swank helpfully pointed out that I messed up when I sent my remailer and personal keys out. I sent the wrong personal key. Here's both, once again. Here's mine: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.1 mQCNAiq/Z6sAAAEEAL8au0gDOEj8xQbaV8jS1BM+baetvF6RciEeyfb9A/1Csdpz 87PTEN19tIteDOX8bQIS9exwztaEG7Upa9WlPs9bNsn5TITJAtEOIalqRwlWd1Qh dsrX7jkytL89MFlVTdBWHhlVuKiGTa4yrFcycoiakXPmf51f0xiQVHeOVJ+HAAUT tCBCaWxsIE8nSGFubG9uIDx3bW9AcmVibWEubW4ub3JnPokAlQIFECsT6HDlC9IM 15aj/QEBiucD/iS5u+7ze0X0QVI3cVMrFDmkQpQDWb5mm7uPcaeYra3VGm7+Cfxn LkqwMkMwPytxxkNC9NvFCsrndrFFmuP8eLVBSQpZinfs/2d2A9AJsVsZAd4uDvP3 CKXpF415zgCWBHUt6JrT+pjk00sKUhQYSgUKj1z1uyYfw3q1AMWjrP5s =k9RJ -----END PGP PUBLIC KEY BLOCK----- Here's the remailer@rebma.mn.org, signed with mine. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.1 mQCNAisUI2QAAAEEAKgm07Hsje5KpmXYd5azk0R6AES+qK7LcofnVGojUs7GBghD WbwrmW8oOEOhRorlShRALKeYspV4xYIw4WDkJcJxuf1B254scz1urF/Eem3zPW9b yPAx7W/cGwvs6SouZvFcSDq4v1zApvGE9hP4szPzHeGmVr0NVNeaDK0guoCpAAUR tCBSZW1haWxlciAocmVtYWlsZXJAcmVibWEubW4ub3JnKYkAlQIFECsUJGEYkFR3 jlSfhwEB1zgD/1LG9DttNEVPFddxkULPw+AkkbmSolrqJUmVx/3y3QS1AtW+vVqF 0yhgWgvg770b7+xMnwzO/I1nh0FK2shd1Jkx4FVCA5ctyqUzVFjk1NE6VaaRc5Bv BD1nUxtUheR0WXDc50f+ANHgRNkx22MGRvphseMyXq/Ok88opSn7DIrO =nBQt -----END PGP PUBLIC KEY BLOCK----- -- Bill O'Hanlon wmo@rebma.mn.org From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: hkhenson@cup.portal.com Date: Thu, 17 Dec 92 01:21:34 PST To: cypherpunks@toad.com Subject: Re: tempest devices and use Message-ID: <9212170034.1.20498@cup.portal.com> MIME-Version: 1.0 Content-Type: text/plain I just sent email the first time, but hey, guys, does this not look almost exactly like some of the restrictive proposals? Someone is pulling your chains. Just because they don't put a :-) on it does not keep a posting from being satirical. Keith From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: hkhenson@cup.portal.com Date: Thu, 17 Dec 92 01:21:36 PST To: cypherpunks@toad.com Subject: Re: tempest devices and use Message-ID: <9212170035.1.20498@cup.portal.com> MIME-Version: 1.0 Content-Type: text/plain Actually the posting is a takeoff on the crypto restrictions. Keith From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Thu, 17 Dec 92 11:04:13 PST To: cypherpunks@toad.com Subject: Re: TEMPEST not restricted In-Reply-To: <9212171833.AA11371@novavax.nova.edu> Message-ID: <9212171902.AA05048@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Yanek Martinson makes some very good points about the legality of TEMPEST: > "Treason" writes: > > > Here is parts of the article I posted regarding the legality of the use > > of emf shielding. > [...] > > PERRY, now I put up, now YOU SHUT UP! > > sheesh. > > treason@gnu. > > The article you posted is at least 3 years old, if not older. I have not > checked on the legal references quote in the article, but I called up > Wayne Martin of Lindgren RF Enclosures, and asked him about this. He > said that he was not restricted to selling TEMPEST equipment to military > or government only, and suggested that if I am looking for TEMPEST-compliant > computers, I should call up a computer manufacturer like IBM or Digital, > and they would be able to sell such systems to me. > > Maybe things have changed in the last three years since the article was > written, or maybe it was incorrect to begin with. Thanks, Yanek! And could I suggest to all of us that we be very careful in the language we use when disagreeing with others? "Treason's" demand that Perry now "SHUT UP" is intemperate and counterproductive. Our list is not moderated, that is, there is no censor or moderator holding people back when they feel the temptation to spew bile all over the list. With hundred of folks now on this list, great care must be taken. Sorry to waste list bandwidth on this point of list etiquette. --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: wendtj@jplpost.Jpl.Nasa.Gov (Jeffrey P Wendt) Date: Thu, 17 Dec 92 11:10:49 PST To: cypherpunks@toad.com Subject: New number for Secure Systems & Services Message-ID: <9211177246.AA724619264@jplpost.jpl.nasa.gov> MIME-Version: 1.0 Content-Type: text/plain The new number for SS&S is (214) 907-9288 Also, Lindgren RF Enclosures informed me that they now have exclusive license to market International Paper Company's SAF'N SHIELDED; and they give free samples ;-)) JPW From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: "DrZaphod" Date: Thu, 17 Dec 92 15:42:43 PST To: cypherpunks@toad.com Subject: Re: Treason's bile spewing Message-ID: <44511.drzaphod@ncselxsi> MIME-Version: 1.0 Content-Type: text/plain In Message Thu, 17 Dec 92 11:02:42 PST, netcom!tcmay@netcomsv.netcom.com (Timothy C. May) writes: >Our list is not moderated, that is, there is no censor or moderator >holding people back when they feel the temptation to spew bile all >over the list. With hundred of folks now on this list, great care must >be taken. > >Sorry to waste list bandwidth on this point of list etiquette. > >--Tim Well said Tim. Treason's posts, for the past week, have been like the rantings of a third grader. I'm just glad some people on this list have the resources to prove him wrong. Oh.. and what kind of prices are we talking about to, say, TEMPEST a small room.. maybe enuf for a workstation and misc. accessories. |-] TTFN! DrZaphod [AC/DC] / [DnA][HP] [drzaphod@ncselxsi.uucp] Technicolorized From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: treason@gnu.ai.mit.edu Date: Thu, 17 Dec 92 09:38:58 PST Subject: No Subject Message-ID: <9212171738.AA02009@spiff.gnu.ai.mit.edu> MIME-Version: 1.0 Content-Type: text/plain Here is parts of the article I posted regarding the legality of the use of emf shielding. Read it carefully, and I suggest you also read the posted document in full as well. This poses many problems to the public in general, and the private sector in specific. PERRY, I suggest you read this. NACSIM 5100A is classified, as are all details of TEMPEST. To obtain access to it, contractor must prove that there is demand within the government for the specific type of equipment that intend to certify. Since the standard is classified, the contractors can not sell the equipment to non-secure governmental agencies or the public. This prevents reverse engineering of the standard for its physical embodiment, the Certified equipment. By preventing the private sector from owning this anti- eavesdropping equipment, the NSA has effectively prevented the them from protecting the information in their computers. A number of companies produce devices to measure the emanations from electrical equipment. Some of these devices are specifically designed for bench marking TEMPEST Certified equipment. This does not solve the problem. The question arises: how much radiation at a particular frequency is compromising? The current answer is to refer to NACSIM 5100A. This document specifies the emanations levels suitable for Certification. The document is only available to United States contractors having sufficient security clearance and an ongoing contract to produce TEMPEST Certified computers for the government. Further, the correct levels are specified by the NSA and there is no assurance that, while these levels are sufficient to prevent eavesdropping by unfriendly operatives, equipment certified under NACSIM 5100A will have levels low enough to prevent eavesdropping by the NSA itself. The accessibility of supposedly correct emanations levels does not solve the problem of preventing TEMPEST eavesdropping. Access to NACSIM 5100A limits the manufacturer to selling the equipment only to United States governmental agencies with the need to process secret information.[33] Without the right to possess TEMPEST ELINT equipment manufacturers who wish to sell to the public sector cannot determine what a safe level of emanations is. Further those manufacturers with access to NACSIM 5100A should want to verify that the levels set out in the document are, in fact, low enough to prevent interception. Without an actual eavesdropping device with which to test, no manufacturer will be able to produce genuinely uncompromising equipment. PERRY, now I put up, now YOU SHUT UP! sheesh. treason@gnu. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Richard Childers Date: Thu, 17 Dec 92 12:45:34 PST To: cypherpunks@toad.com Subject: Re: New number for Secure Systems & Services Message-ID: <9212172044.AA04823@rchilder.us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain > and they give free samples ;-)) "Great. Now does anyone know of where to get equipment to test how effective it is? " I'd guess that virtually any hardware lab that has to test its equipment to make sure it meets FCC criteria for minimal emissions, would have a test lab onsite. Such a test lab normally consists of the following : - a very wide frequency range analyzer ( HP makes these ) - a set of antennas by which to sample the EMF field(s) - a platform adjacent to the antenna mount, upon which such equipment as is being tested, is rotated, to allow the antenna to sample the entire 360- -degree field at incremented altitudes and var- -iable angles in incidence. Those test labs I've been acquainted with are usually found at a distance from production facilities, usually small outbuildings in fields out back, insulated by distance from the EMF of the surrounding buildings. I can see how this paper might make it possible to move the lab back indoors ... To answer your question specifically, I'd check a HP electronic test products catalog, with an emphasis on signal/frequency/harmonic analyzers. -- richard ===== -- richard childers rchilder@us.oracle.com 1 415 506 2411 oracle data center -- unix systems & network administration "If Life is a drama, then, surely, the hardest parts go to the most skillful." From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: wendtj@jplpost.Jpl.Nasa.Gov (Jeffrey P Wendt) Date: Thu, 17 Dec 92 12:50:22 PST To: cypherpunks@toad.com Subject: SS&S response to TEMPEST inf0 request Message-ID: <9211177246.AA724625237@jplpost.jpl.nasa.gov> MIME-Version: 1.0 Content-Type: text/plain About 30 minutes after I got off the phone requesting product information and related materials, I recieved a voice mail message from Ray Helsop of SS&S. When I returned his call, he informed me that the address that I gave looked like a residential address (Hmmm), and that they usually don't send information to private homes, apts, bird-baths, e.t.c. He then informed me that he had called my employer (the Junior Proletarian Laboratory), and varified my name in the directory, and the department that I worked in; and that since I work for a Federal Research Facility (DoD sinkhole) everything was `ok'. He then proceded to tell me about foreigners calling the company requesting TEMPEST information, and other "spooky" callers, and that it was now allright to send the product information to my home. After I told him my interests in the hardware, he ran down a list of avilable equipment, and asked about numbers, requirements, and said he'd send it right out to me. I hate to be presumptuous... but I think an "I'm trying to protect my personal computer from prying eyes" would fall on very deaf ears at SS&S, and I'll leave it at that. ;-) JPW From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: norm@xanadu.com (Norm Hardy) Date: Thu, 17 Dec 92 13:51:15 PST To: cypherpunks@toad.com Subject: TEMPEST not restricted Message-ID: <9212172053.AA26480@xanadu.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain While taxpayers paid for TEMPEST and NACSIM 5100A and it would undoubtedly be useful to taxpayers were it declassified, it is not true that compliance with NACSIM 5100A is necessary and sufficient to be secure from eavesdropping. Some of RSA's charm is that it was not promulgated by NSA! From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Thu, 17 Dec 92 10:34:01 PST To: treason@gnu.ai.mit.edu Subject: TEMPEST not restricted In-Reply-To: <9212171738.AA02009@spiff.gnu.ai.mit.edu> Message-ID: <9212171833.AA11371@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain "Treason" writes: > Here is parts of the article I posted regarding the legality of the use > of emf shielding. [...] > PERRY, now I put up, now YOU SHUT UP! > sheesh. > treason@gnu. The article you posted is at least 3 years old, if not older. I have not checked on the legal references quote in the article, but I called up Wayne Martin of Lindgren RF Enclosures, and asked him about this. He said that he was not restricted to selling TEMPEST equipment to military or government only, and suggested that if I am looking for TEMPEST-compliant computers, I should call up a computer manufacturer like IBM or Digital, and they would be able to sell such systems to me. Maybe things have changed in the last three years since the article was written, or maybe it was incorrect to begin with. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Richard Childers Date: Thu, 17 Dec 92 14:12:48 PST To: cypherpunks@toad.com Subject: Patent Infringement Message-ID: <9212172211.AA05449@rchilder.us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain > This does not mean though, that it is illegal to reinvent the wheel and > apply it yourself. "I'm sorry to say that yes, it *IS* illegal to reinvent the wheel and apply it yourself. In the US it is called "Patent Infringement"." Only if you attempt to sell it ... -- richard ===== -- richard childers rchilder@us.oracle.com 1 415 506 2411 oracle data center -- unix systems & network administration "If Life is a drama, then, surely, the hardest parts go to the most skillful." From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) Date: Thu, 17 Dec 92 11:19:50 PST To: treason@gnu.ai.mit.edu Subject: Re: In-Reply-To: <9212171738.AA02009@spiff.gnu.ai.mit.edu> Message-ID: <9212171919.AA27449@tsx-11.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain Date: Thu, 17 Dec 92 12:38:34 -0500 From: treason@gnu.ai.mit.edu Apparently-To: cypherpunks@toad.com Here is parts of the article I posted regarding the legality of the use of emf shielding. Read it carefully, and I suggest you also read the posted document in full as well. We have read it carefully. What your article claims is that NACSIM 5100A is classified, so if something is built to be TEMPEST certified, the design is classified, and the actual device can not be sold to the public, in order to prevent reverse-engineering of the standard. This, however, does not mean that emf shielding is illegal. How to do emf shielding is relatively well understood --- what is classified is how much shielding is enough. As your article itself admits, having the the NACSIM standard isn't very useful anyway, since we can't trust the levels promulgated by the NSA to be sufficient to prevent them from listening in. (What you're saying would be like saying that the NSA has a classified recommendation that RSA keys be at least XXX bits long --- just because the recommendation is classified doesn't mean that we can't use RSA, and if the number of bits were something like 512 bits, if we found out what it was, we'd probably want to use something bigger anyway. :-) As many other people have pointed out, emf shielding can't be illegal, since it's required for FCC requirements. If someone wants to spend additional money, and put a lot more shielding that what's really needed, there shouldn't be any problem with that. Finally, I'm not sure about the complete accuracy of that article you've posted. We have one of the first BBN Safekeeper (tm) boxes at MIT, which is a certificate meter which generates X.509 public key certificates for use in the Privacy Enhanced Mail (PEM) system. It *IS* TEMPEST shielded(*) and BBN is planning on selling it to commercial companies, TEMPEST shielding and all. Therefore, I suspect that the information in that article may be out of date. PERRY, now I put up, now YOU SHUT UP! There's no need to be rude --- especially when you're wrong and can't even interpret the article which you yourself posted. - Ted (*) There is an amusing story about what happened when they took it to get it certified as a FCC Class A computing device (which they needed to do since they were planning on selling it commercially); the FCC tester kept bringing his testing device closer, and closer, and closer to the Safekeeper(tm), and when he was finally on top of it, he tapped his meter and asked: ``Are you sure this is turned on?'' As the story was told to me, the designer of the box was there for the testing, and this was one of his prouder moments. :-) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Thu, 17 Dec 92 12:53:31 PST To: cypherpunks@toad.com Subject: No Subject Message-ID: <9212171925.AA04923@maggie.shearson.com> MIME-Version: 1.0 Content-Type: text/plain Close, but no cigar, Mr. "Treason". Anyone reading your "proof" can see for themselves that there is no law making it illegal to shield your computers, only some regulations on people that sell equipment to the government can't tell other people what their specifications are. Big deal. The line in the article saying Without the right to possess TEMPEST ELINT equipment manufacturers who wish to sell to the public sector cannot determine what a safe level of emanations is. is mostly bull, in the sense that people can probably judge what is safe without knowing the government standards. In any case, you have demonstrated nothing making it illegal to shield your computers, and we've already seen a post containing a dozen purveyors of shielding equipment. Repeating, you don't know what you are talking about. Now go away. Perry Original message included for reference: > From cypherpunks-request@toad.com Thu Dec 17 14:13:11 1992 > Date: Thu, 17 Dec 92 12:38:34 -0500 > From: treason@gnu.ai.mit.edu > Content-Length: 3194 > > Here is parts of the article I posted regarding the legality of the use > of emf shielding. Read it carefully, and I suggest you also read the > posted document in full as well. This poses many problems to the public > in general, and the private sector in specific. > PERRY, I suggest you read this. > > NACSIM 5100A is classified, as are all details of TEMPEST. > To obtain access to it, contractor must prove that there is > demand within the government for the specific type of equipment > that intend to certify. Since the standard is classified, the > contractors can not sell the equipment to non-secure governmental > agencies or the public. This prevents reverse engineering of the > standard for its physical embodiment, the Certified equipment. > By preventing the private sector from owning this anti- > eavesdropping equipment, the NSA has effectively prevented the > them from protecting the information in their computers. > A number of companies produce devices to measure the > emanations from electrical equipment. Some of these devices > are specifically designed for bench marking TEMPEST > Certified equipment. This does not solve the problem. The > question arises: how much radiation at a particular > frequency is compromising? The current answer is to refer > to NACSIM 5100A. This document specifies the emanations > levels suitable for Certification. The document is only > available to United States contractors having sufficient > security clearance and an ongoing contract to produce > TEMPEST Certified computers for the government. Further, > the correct levels are specified by the NSA and there is no > assurance that, while these levels are sufficient to prevent > eavesdropping by unfriendly operatives, equipment certified > under NACSIM 5100A will have levels low enough to prevent > eavesdropping by the NSA itself. > The accessibility of supposedly correct emanations > levels does not solve the problem of preventing TEMPEST > eavesdropping. Access to NACSIM 5100A limits the > manufacturer to selling the equipment only to United States > governmental agencies with the need to process secret > information.[33] Without the right to possess TEMPEST ELINT > equipment manufacturers who wish to sell to the public > sector cannot determine what a safe level of emanations is. > Further those manufacturers with access to NACSIM 5100A > should want to verify that the levels set out in the > document are, in fact, low enough to prevent interception. > Without an actual eavesdropping device with which to test, > no manufacturer will be able to produce genuinely > uncompromising equipment. > > PERRY, now I put up, now YOU SHUT UP! > > sheesh. > > treason@gnu. > From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Thu, 17 Dec 92 11:38:00 PST To: wendtj@jplpost.Jpl.Nasa.Gov (Jeffrey P Wendt) Subject: Re: New number for Secure Systems & Services In-Reply-To: <9211177246.AA724619264@jplpost.jpl.nasa.gov> Message-ID: <9212171936.AA14894@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > The new number for SS&S is (214) 907-9288 I just called them on the old number earlier today, and they answered. Maybe they have call forwarding. > Also, Lindgren RF Enclosures informed me that they > now have exclusive license to market International Paper > Company's SAF'N SHIELDED; Makes some sense. Someone looking for RF shielding is more likely to buy it from someone named Lindgren RF Enclosures than from a paper company. > and they give free samples ;-)) Great. Now does anyone know of where to get equipment to test how effective it is? From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Doug.Brightwell@Corp.Sun.COM (Doug Brightwell) Date: Thu, 17 Dec 92 15:48:52 PST To: cypherpunks@toad.com Subject: TEMPEST Question Message-ID: <9212172348.AA01767@media.Corp.Sun.COM> MIME-Version: 1.0 Content-Type: text/plain Am I correct in understanding that what's actually detected and reconstructed by TEMPEST surveillance is the EMR having to do with screen drawing, and not the CPU and other internal components involved in processing data? If that's the case, would computers without CRT-type displays still be succeptible to TEMPEST surveillance? Such as headless servers that might be running a BBS without a video card inside or a monitor. Or laptops, such as a Mac PowerBook with an active-matrix screen? Thanks, Doug From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Thu, 17 Dec 92 16:23:45 PST To: cypherpunks@toad.com Subject: Faraday Cages In-Reply-To: <44511.drzaphod@ncselxsi> Message-ID: <9212180022.AA21357@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain > Oh.. and what kind of prices are we talking about to, say, TEMPEST a small > room.. maybe enuf for a workstation and misc. accessories. |-] > > TTFN! > > DrZaphod The usual, and cheaper, approach is to shield a computer or workstation. This is the approach discussed in the last several days here. Shielding a room is common is certain applications, such as at NSA (where the entire windowless building is so shielded), in component testing labs, and so on. Such rooms are called Faraday cages. It so happens that in 1972 I worked inside such a Faraday cage (in the labs at UCSB of then-young Paul Hansma, now famous in the nanotech community for his AFM imaging of cells and other biological materials). The shield consisted of copper screen mesh (fine-pitch...perhaps .5 mm gaps) mounted on a wooden frame, with 2 layers and an air gap between them. Attenuation depends on frequency, of course, and a wire mesh screen lets through some frequencies (light, for example!). How many dbs of attenuation at "frequencies of interest" depends on a lot of factors. Extremely high frequency signals, becoming more common in computers as processor speeds exceed 50 MHz, are very hard to shield, due to the short wavelengths. I suspect if the boys in the antenna-equipped vans are parked outside your home, nearly any leakage is too much. But there are cheaper ways for your secrets to be learned. In other words, there are more pressing concerns. I would estimate that shielding an entire room would be expensive, perhaps costing $5K or more ot do a good job. Building a smaller room-within-a-room might cost a little less. Listening to a radio is one very crude way of monitoring your own RF emissions, if you don't have access to specialized gear. Using a laptop helps. (I have an old GRiD Compass, with plasma display, bubble memory, and a black magnesium case...it is definitely less RF-noisy than my PowerBook, and a lot less noisy than my IIci.) (Perhaps Phil Karn can comment on strategies) BTW, we've talked about setting up our own "van Eyck radiation" systems to see just how easy it is to monitor computers. There is a legend, possibly urban, that the NSA did indeed try to block publication of papers on the "van Eyck" effect. This fits part of what "Treason" was saying, though not all of it. (And there is no law saying you can't try to shield your computers, or speak in a low voice, for that matter.) --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Thu, 17 Dec 92 16:36:15 PST To: cypherpunks@toad.com Subject: The Need for Positive Repuations In-Reply-To: <9212172333.AA12866@toad.com> Message-ID: <9212180034.AA23003@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Tai (UFLTAI@MEMSTVX1.bitnet) asks about how best to stop people from generating many, many digital pseuodonyms, thus evading filtering by "Kill" files. Lots of issues here. The longterm solution is to use "positive reputations" and not just "negative reputations" (as in Kill files). This is something Dean Tribble just talked about at our last physical meeting of the Cypherpunks ("Bay Area Branch" :-} ). Think of like a credit rating. People _earn_ trust, they don't just get assigned a credit rating until they do something bad. Positive reputation filtering will still allow digital pseudonyms, but a reputation will be attached and will be important. Read Vinge's "True Names" for some insights on this. --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Derek Atkins Date: Thu, 17 Dec 92 13:38:49 PST To: dclunie@pax.tpa.com.AU (David Clunie) Subject: No Subject In-Reply-To: <9212172122.AA00432@britt> Message-ID: <9212172137.AA04528@deathtongue.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain > This does not mean though, that it is illegal to reinvent the wheel and > apply it yourself. I'm sorry to say that yes, it *IS* illegal to reinvent the wheel and apply it yourself. In the US it is called "Patent Infringement". Now, this may not apply to EVERYTHING, but there are cases where people re-invented something that was classified and their work then became classified.... (I also believe there are stories where the opposite is true, but I don't want to belabor the point) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Derek Atkins Date: Thu, 17 Dec 92 13:38:54 PST To: dclunie@pax.tpa.com.AU (David Clunie) Subject: No Subject In-Reply-To: <9212172122.AA00432@britt> Message-ID: <9212172137.AA04531@deathtongue.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain > This does not mean though, that it is illegal to reinvent the wheel and > apply it yourself. I'm sorry to say that yes, it *IS* illegal to reinvent the wheel and apply it yourself. In the US it is called "Patent Infringement". Now, this may not apply to EVERYTHING, but there are cases where people re-invented something that was classified and their work then became classified.... (I also believe there are stories where the opposite is true, but I don't want to belabor the point) -derek From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Thu, 17 Dec 92 13:53:18 PST To: cypherpunks@toad.com Subject: 1st dc-net works! Message-ID: <9212172152.AA20073@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain Finally, I got a dc-net working. It is now quite primitive, and useful only as a proof of concept. It does not yet do any key management, I just copied the binaries of several unix utilities to be used as one time pads. The reservation system does not work yet. If there is a message to be sent, it is sent immediately. That means only one of the participants can send a message in one round. The messages are not forwarded anywhere, they are just dropped to "outgoing" directory. It runs on one machine, under three accounts I created just for that purpose. The mail keeps going back and forth constantly between the three accounts, with null files being deposited to the outgoing directories. Temporary files are being created and deleted. As soon as I put a file in one of the incoming directories, within one round it appears in each of the outgoing directories. So the main function works. It is written in perl, because of the ease I can manipulate binary data of any size. As soon as I add the minimal necessary features (PGP based key exchange, and reservation blocks) I will be looking for some people to participate in an experimental dc-net. People who want to participate in this, should have fast, reliable, e-mail connections (preferably round-trip time to any other participant should be less than 10 minutes). If even one participant has a slow link, it will hold everyone up. You also need the ability to pipe incoming mail with a certain subject header through an arbitrary program. You can use any of the various 'slocal' programs, or you could use elm's filter program, or any other means. You also need to have perl working on your system. You need PGP. As someone suggested, an arbitrary group of people might not have much to talk about amongst themselves, so the next feature will be forwarding to a mailing address (or list), a newsgroup, or another dc-net. It is very simple to do the forwarding, it is a little more complicated, and interesting, to decide who will do the forwarding. I would not want to rely on any single site serving as a gateway, since that would introduce a single point of compromise. I would rather have some dynamic system, similar to the reservation blocks, that would let the net randomly decide who will forward a particular message. As soon as this first test network has run for a couple of days, and all the bugs are fixed, I will release the code, so that anybody can work on it. I expect that some people will work on various projects I mentioned in the "FUTURE ENCHANCEMENTS" section of my initial posting on this topic. I hope that people who add features to the system send the mods back to me, so I can incorporate them in a new version. When there is a number of networks running, it will be interesting to experiment with hierarchical nets, or linked networks of networks. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tribble@xanadu.com (E. Dean Tribble) Date: Thu, 17 Dec 92 17:40:08 PST To: uunet!CUNYVM.CUNY.EDU!UFLTAI%MEMSTVX1.bitnet@uunet.UU.NET Subject: abusing the system? In-Reply-To: <9212172333.AA12866@toad.com> Message-ID: <9212180105.AA28598@xanadu.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain Date: Thu, 17 Dec 92 17:33 CDT From: uunet!CUNYVM.CUNY.EDU!UFLTAI%MEMSTVX1.bitnet X-Vms-To: IN%"cypherpunks@toad.com" I realise that this is probably not important in the overall scheme of things... but I am curious about what can be done to reduce such potential abuse. You will be happy to know that solving that problem will be extremely important (probably even in the short term). We need a positive reputation system (kill files filter against negative reputations) so that you only see mail messages by people who have a reputation for valuable postings. I rambled about this topic at the last cypherpunks meeting. I will be posting my notes in an effort to get feedback and organizational help from the people on the list (it will be a few days, however). The content will eventually be organized into something that I hope will spread. dean From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Doug.Brightwell@Corp.Sun.COM (Doug Brightwell) Date: Thu, 17 Dec 92 17:27:21 PST To: yanek@novavax.nova.edu Subject: Re: TEMPEST Question Message-ID: <9212180126.AA01855@media.Corp.Sun.COM> MIME-Version: 1.0 Content-Type: text/plain >> Cpu signal is the easiest to detect, but not the only >> one. Other possible sources of emissions are all >> kinds of communications cables. Unshielded RS-232 to >> the modem, possibly even the connections to the disk >> drives. Synching up to monitor signals, I can understand. But as a non-technical person, what I'm struggling to understand is how a surveillance team could monitor the emmisions from such cables and have any clue as to what they are. Let's say they zeroed in on my poorly shielded modem cable and were able to tune into a stream of 0's and 1's. How could they then resolve that digital data into anything meaningful? It could be one of any number of documents created by one of any number of programs on one of any number of platforms. How do the spies know they're dealing with a Frame page layout document created on a Sun workstation versus a spreadsheet created on a Mac? Even if it's just a plain text file how could the surveillance team read it? Does each member of the ASCII character set have specific and identifiable radiation signatures? For example, does the letter "k" as it passes through my modem cable have a characteristic EMR that is the same for all machines? Sorry if this query is too basic, but I would appreciate any enlightenment... Doug From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: UFLTAI%MEMSTVX1.bitnet@CUNYVM.CUNY.EDU Date: Thu, 17 Dec 92 15:33:28 PST To: cypherpunks@toad.com Subject: abusing the system? Message-ID: <9212172333.AA12866@toad.com> MIME-Version: 1.0 Content-Type: text/plain Hiya, One of the newsgroups I was reading have this persistant "tester" who uses the anon service in Finland. Anyway, there were several different postings, all with different ids, but same kinds of "this is a test, nyah nyah" contents. As I was one of those "stop it" people, and seeing more of the same bullshit by that guy, I got slightly pissed off, and started thinking. Already that person is using about 3 different anonymous ids. If he is introduced to the remailers here, conceivably he could generate more anonymous ids for himself (ie, kill files won't work then, unless you want to kill a whole site) by routing his mail thru the remailers. Each remailer would give him another userid at that anon service. And if he uses it to loop back to the remailers... And then loop to that Australian anon service... and so on. He could "legitimately" have a hundred or so different anon_ids, from one original userid. What if someone who realises this was to use that capability to post some really "colorful" material to news? Suddenly you have a hundred or so weirdos posting "I want nude pictures of a gerbil, please" to alt.binaries. pictures.erotica... you get the idea. Is there anyway to stop this from happening? And this is on top of the real weirdos (ie, those who know how to post anonymously, like most of the readers of this list... :)) So far, the net has functioned as it's own sieve with regards to the "weirdos" but if the remailers is generally available (as it should be!), the potential for abuse is much much greater. Any way to slow it down? "Hey, look, a flame war, let's join in..." Of course, if someone was to forge a mail to the anon service... don't even need to know about the remailers... but with forged mail, the anon service can at least "check" to see the validity of your address. I realise that this is probably not important in the overall scheme of things... but I am curious about what can be done to reduce such potential abuse. Ciao. -Tai ps: Any tips on tracing anonymous mail and newspostings? I mean beyond the "from" and "path" things... ie, trace to the userid... Someone tried to forge a posting in my name... (yes, that's what got me thinking :)) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Richard Childers Date: Thu, 17 Dec 92 17:38:36 PST To: cypherpunks@toad.com Subject: Re: Treason's bile spewing Message-ID: <9212180136.AA06221@rchilder.us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain "Treason's posts, for the past week, have been like the rantings of a third grader." This is in itself rather derogatory and does nothing to quell the flames. "I'm glad some people on this list have the resources to prove him wrong." I suspect the gentleman in question was not displeased to learn something new, and, by contributing material that _was_ a few years out of sync, he was not trying to lower the quality of the discussion ... or dominate it ... he was trying to contribute. Easy does it, folks. -- richard ===== -- richard childers rchilder@us.oracle.com 1 415 506 2411 oracle data center -- unix systems & network administration "If Life is a drama, then, surely, the hardest parts go to the most skillful." From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Thu, 17 Dec 92 14:55:51 PST To: tcmay@netcom.com (Timothy C. May) Subject: enabling technologies In-Reply-To: <9212172233.AA06614@netcom.netcom.com> Message-ID: <9212172254.AA21668@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > I'm amazed at the progress everybody's making on so many fronts. > > --Tim What we are witnessing (and participating in) here is the synergy of enabling technologies. The availability of quality free software such as perl, and C compilers makes it easy to quickly build useful tools. These can then be combined in various ways, without re-inventing them. For example, I do not need to reinvent the strong-pseudorandom function, I can just "borrow" it from the PGP code. I do not need to write a public key system just to distribute seeds for the dc-net one-time pads system, I can use PGP. I don't need to write a program to take chunks of data and xor them together, perl has this capability. I just design a system, and put it together from existing blocks. This is the reality of what the OOP "building-blocks" people are talking about. And the important method is not object-oriented anything, but free software, with source code, and cooperation of people widely separated in time and space, some even anonymous, all linked through the nets. My dc-net system will make life easier for people that are doing digital cash, by providing a ready means of sending untraceable messages. Many useful systems can be built on top of a working digital cash system. All this is catalysed by the existence of this mailing list. For example I got the idea of reservation blocks from ILF's post of Chaum's article. That was made possible by the anonymous remailers. The anonymous remailers can be made more anonymous by linking then into a dc-net. There's a positive feedback loop developing here. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Thu, 17 Dec 92 15:00:07 PST To: rchilder@us.oracle.com (Richard Childers) Subject: Re: Patent Infringement In-Reply-To: <9212172211.AA05449@rchilder.us.oracle.com> Message-ID: <9212172259.AA21750@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > "I'm sorry to say that yes, it *IS* illegal to reinvent the wheel and > apply it yourself. In the US it is called "Patent Infringement"." > > Only if you attempt to sell it ... No. The patent law prohibits anyone from "making, using, or selling" anything covered under the patent. Selling it makes it more likely that the patent holder will come after you, as they have a greater chance of getting some money from you. I am not a lawyer, I am sure someone here can explain all this in greater detail, or correct me if I'm wrong. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: "Mark W. Eichin" Date: Thu, 17 Dec 92 15:59:41 PST To: UFLTAI%MEMSTVX1.bitnet@CUNYVM.CUNY.EDU Subject: re: abusing the system? In-Reply-To: <9212172333.AA12866@toad.com> Message-ID: <9212172358.AA07292@tweedledumber.cygnus.com> MIME-Version: 1.0 Content-Type: text/plain >> ps: Any tips on tracing anonymous mail and newspostings? I mean beyond the >> "from" and "path" things... ie, trace to the userid... Someone tried to forge >> a posting in my name... (yes, that's what got me thinking :)) Remember to look at the "Message-Id" -- on typical unix mailers, that has the IP address encoded into it to help make it more "unique". A social point to keep in mind, though: one reason we really *need* signed messages is because there is no real identity attached to email. It is easy to "believe in" some identity you see on the net, and for the most part enough of them are real that it is ok... but I expect this to become even more of a problem than it is now without signatures. A "historical" example -- at MIT, as part of Project Athena, we have a real-time messaging system called Zephyr (for more details, look in Usenix proceedings from some time in 87 or 88, or just look at athena-dist.mit.edu:pub/usenix/zephyr.PS.) It optionally uses kerberos authentication, and the recipient application will display whether a message is authenticated or unauthenticated. People tended to ignore this, until one of the other developers wrote a program that looked at the database of current users, picked a pair at random, picked a message at random, and sent it to one, from the other. (It backfired amusingly once -- it sent a message from him, to me, saying "I'm stopping at the coffeehouse, want me to get you anything?" to which I responded sure... and then harassed him about it for years, until he finally *did* bring me the M&M's I wanted. :-) The point was that this program didn't fake the authentication (it did use privileged access to look at the user database, which is not available remotely, but the messages themselves were unauthenticated) but rather noone paid attention to it. The "unauthenticated" flag was made more visible in a later release, I believe... but I don't think anyone ever went as far as refusing unauthenticated personal messages altogether. I could see that happenning with email... _Mark_ MIT Student Information Processing Board Cygnus Support From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: "Mark W. Eichin" Date: Thu, 17 Dec 92 16:09:11 PST To: ncselxsi!drzaphod@ncselxsi.netcom.com Subject: TEMPEST pricing In-Reply-To: <44511.drzaphod@ncselxsi> Message-ID: <9212180008.AA07304@tweedledumber.cygnus.com> MIME-Version: 1.0 Content-Type: text/plain >> Oh.. and what kind of prices are we talking about to, say, TEMPEST a small >> room.. maybe enuf for a workstation and misc. accessories. |-] I don't know about an entire room, but I seem to recall that Sun has TEMPESTed workstations on the GPO pricelist, as do other companies... and that a few years ago TEMPESTed PC's (286 boxes) *started* around $10K. Most of this was because of the limited market -- I doubt you'll find a mass-market PC that hasn't skimped as much as possible on the RF shielding if it was cost effective (BYTE, Oct. or Nov., or maybe the laptop issue, mentions Apple switching from sprayed-on metallic paint on the inside of their cases to sheet-metal liners because it ended up being significantly less expensive.) Given the lack of a large-volume market to produce economies of scale, you'd expect the prices for TEMPESTed hardware to stay high. Over at MIT, in building 20, there's a room that is entirely RF shielded (built in place, years ago...) I don't know the story behind it, I don't know if the shielding is even maintained any more, it is decades old. It's now random lab-space... _Mark_ From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Thu, 17 Dec 92 16:28:15 PST To: Doug.Brightwell@Corp.Sun.COM (Doug Brightwell) Subject: Re: TEMPEST Question In-Reply-To: <9212172348.AA01767@media.Corp.Sun.COM> Message-ID: <9212180027.AA24433@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > Am I correct in understanding that what's actually detected and > reconstructed by TEMPEST surveillance is the EMR having to do with > screen drawing, and not the CPU and other internal components involved > in processing data? Cpu signal is the easiest to detect, but not the only one. Other possible sources of emissions are all kinds of communications cables. Unshielded RS-232 to the modem, possibly even the connections to the disk drives. I don't think the cpu itself emits much or if it does that it is easy to interpret it in any easy way, but I don't know for sure. The monitors are just easiest to detect, since for every pixel, the electron beam is turned on and off. These pulses are easy to detect, and if your monitor is synchronized with the target, a simple device could reconstruct the image, without any need for powerful computers to process the data. > If that's the case, would computers without CRT-type displays still be > succeptible to TEMPEST surveillance? It would be safe to say that they would be _less_susceptible_. > might be running a BBS without a video card inside or a monitor. Or > laptops, such as a Mac PowerBook with an active-matrix screen? Anyone that knows NSA's capabilities in these areas certainly isn't talking. It _may_ be possible to derive at some limits just by knowing electronics and the laws of physics. I don't know of any independent research team having done such a study. If it has been done, or is being done, I would like to know. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Thu, 17 Dec 92 17:23:42 PST To: yanek@novavax.nova.edu (Yanek Martinson) Subject: my mistake (re: TEMPEST) In-Reply-To: <9212180027.AA24433@novavax.nova.edu> Message-ID: <9212180122.AA26838@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > > reconstructed by TEMPEST surveillance is the EMR having to do with > > screen drawing, and not the CPU and other internal components involved > > Cpu signal is the easiest to detect, but not the only one. Other possible Sorry, I meant "display signal". From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Richard Childers Date: Thu, 17 Dec 92 20:48:27 PST To: cypherpunks@toad.com Subject: So you want a wide-spectrum signal analyzer ? Message-ID: <9212180447.AA06689@rchilder.us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain Here's what HP's catalog says : Spectrum Analyzers Spectrum analyzers take advantage of the frequency-conversion properties of the swept-tuned heterodyne receiver to make sig- -nificant contributions to frequency-domain signal analysis. The following are some of the measurements that can be made with spectrum analyzers : (1) Absolute and relative frequency. (2) Absolute and relative amplitude. (3) Noise. (4) Distortion products. (5) AM, FM & pulsed RF modulation. (6) Stimulus response. ( biofeedback ? ed. ) (7) Electromagnetic compatibility (EMC). These measurements are possible because spectrum analyzers have the following characteristics : (1) Broad frequency coverage from 5 Hz to 325 GHz. (2) Wide amplitude range from -138 dBm to +30 dBm. (3) Excellent sensitivity for low-signal detection. (4) Excellent frequency stability. (5) High resolution of frequency and amplitude. These capabilities allow spectrum analyzers to provide frequency- domain signal analysis for numerous applications, including the manufacture and maintenance of microwave communication links, radar, telecom equipment, CATV systems, and broadcast equipment ; EMI diagnostic testing ; and signal surveillance. ( I can't believe they actually said that. Gee, I wonder if They're going to classify test & measurement equipment next. )-: Prices for these puppies run from @ $ 20,000 to @ $ 50,000. They are very modularized, and, for the paranoids amongst you, these things are portable. They are probably devilishly heavy, like most test equipment is, and look a lot like an oscilloscope, when the cover is off. For information about any Hewlett Packard product or service, or for additional copies of this catalog, call the Customer Infor- -mation Center (CIC) at 800-752-0900 between 6:00 am and 5:00 pm PST. What you want is their 'Test & Measurement Catalog'. One small tip - if you're calling them up and want to get a catalog sent to you, you want to make an effort to look like a valid customer. These catalogs are large and expensive and they may be less inclined to pay for what is probably a few dollars' shipping if you come across as a college student ( with apologies to college students :-). Give an address if you can, give yourself a title - R&D engineer is good - a department - R&D - and, if they ask for a box or mail dept code, you can make one up or say that you don't have one. ( Using different box numbers going to a same address is a great way to see who's sharing their mailing list with whom else, BTW ). I'm not encouraging you to spoof these folks, merely noting that it is a regrettable necessity. If you don't present yourself as a prospect, they may blow you off, and if you give any hint that you don't represent some sort of company, you are sure to be blown off, presumed to be a waste of their time. ( Of course, this posting may lead to three or four analyzers, $ 100-200 thousand worth of sales, but try to persuade a salescritter of this. :-) -- richard ===== -- richard childers rchilder@us.oracle.com 1 415 506 2411 oracle data center -- unix systems & network administration "If Life is a drama, then, surely, the hardest parts go to the most skillful." From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: strat@intercon.com (Bob Stratton) Date: Thu, 17 Dec 92 18:03:16 PST To: Doug.Brightwell@corp.sun.com Subject: TEMPEST Question In-Reply-To: <9212180126.AA01855@media.Corp.Sun.COM> Message-ID: <9212180202.AA21476@intercon.com> MIME-Version: 1.0 Content-Type: text/plain >>>>> Doug.Brightwell@corp.sun.com (Doug Brightwell) writes: Doug> But as a non-technical person, what I'm struggling to Doug> understand is how a surveillance team could monitor the Doug> emmisions from such cables and have any clue as to what Doug> they are. Let's say they zeroed in on my poorly shielded Doug> modem cable and were able to tune into a stream of 0's Doug> and 1's. How could they then resolve that digital data Doug> into anything meaningful? ... My understanding, being only a moderate RF weenie, is that UARTs, the devices which, more often than not, are driving your serial ports, generate an emission very much like good old frequency shift keying. It makes sense - having listened to computers on radios before. Think in terms of sound first, as it's easier. A given sound represents a "1", and another tone is "0". You waver back and forth between the tones to describe the data you're transmitting. The idea is that some of the normal emission characteristics from components in computers (like UARTs) correspond to this sort of modulation. With regard to machine types, if it's a serial line, it's fairly easy to map the communications into a set of probably protocol suites. If you know *anything* about the use of the machine, it becomes a lot easier. For instance, given an intercept of TCP/IP traffic over a SLIP line, I could probably reconstruct a TELNET session log, but it's nowhere as easy as just reading a terminal session on a link to some BBS. Doug> Even if it's just a plain text file how could the Doug> surveillance team read it? Does each member of the ASCII Doug> character set have specific and identifiable radiation Doug> signatures? For example, does the letter "k" as it Doug> passes through my modem cable have a characteristic EMR Doug> that is the same for all machines? You might also think in terms of things other than screens and modem cables. For instance, many keyboards emit RF as they are used. It's not irrational to suspect that these emissions might be tied in some way to the use of the keyboard - I have an old FCC Class A Wyse terminal that sounds different depending on which keys I hit. Since we know that every piece of equipment has a uniquely identifiable (even compared to other units of the same type) emission signature, it's not too outlandish to expect that different key encodings in a keyboard might generate different emission patterns. Doug> Sorry if this query is too basic, but I would appreciate Doug> any enlightenment... It's weird stuff, and some people would rather not have the world learning how to do this. In fact, Van Eck's original article is known to have some deliberate misinformation in it, as the author didn't want to make it "too easy" to learn how to do this kind of ELINT. --Strat From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Thu, 17 Dec 92 18:14:38 PST To: Doug.Brightwell@Corp.Sun.COM (Doug Brightwell) Subject: They have to find you first! In-Reply-To: <9212180154.AA01889@media.Corp.Sun.COM> Message-ID: <9212180213.AA29897@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > I would guess that all efforts towards creating secure, encrypted email > would only cause surveillance groups to focus their efforts more upon > what's showing up on your screen in plaintext before encryption and To do that, they need to know who you are and where you are located. They can't bug everyone. If a pseudonymous system is used, then it would be your top priority to make it impossible to connect your pseudonym with your legal identity. If you have not already, read Vinge's _True_Names_. If "they" know who you are and where you are located, many techniques are available, TEMPEST eavesdropping being only one of them. Others are confiscating your equipment, arresting you, threatening you and using you to track down other people. So, instead of concentrating on how to shield yourself from surveilannce once you have been found, concentrate instead on not being found. You can maintain a usual identity that you use for normal conversation, but for anything dangerous use an alternate identity, secure remailers, etc. You might want SOME shielding, in case "they" take up the practice of routinely driving up and down the streets looking to randomly find something (someone) interesting. It should be much easier to protect against a casual search. It may be nearly impossible, and/or useless to protect oneself from a determined physical attack by a resourceful enemy. It is much more profitable to prevent the attack. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 (not in hiding yet :-) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: MAILER-DAEMON@acf3.NYU.EDU (Mail Delivery Subsystem) Date: Fri, 18 Dec 92 11:53:19 PST To: habs@acf3.NYU.EDU Subject: Returned mail: User unknown Message-ID: <9212180223.AA06621@acf3.NYU.EDU> MIME-Version: 1.0 Content-Type: text/plain ----- Transcript of session follows ----- >>> RCPT To: <<< 550 ... User unknown 550 cyperpunks@toad.com... User unknown ----- Unsent message follows ----- Received: by acf3.NYU.EDU (5.61/1.34) id AA06619; Thu, 17 Dec 92 21:23:18 -0500 From: habs (Harry A. B. Shapiro) Message-Id: <9212180223.AA06619@acf3.NYU.EDU> Subject: repeater abuse To: cyperpunks@toad.com Date: Thu, 17 Dec 1992 21:23:17 -0500 (EST) X-Mailer: ELM [version 2.4 PL0] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Length: 544 In reponse to Dean T. message. I agree. Re: low tech - The extropians uses several Perry(TM) filters to prevent unwanted bounces AND unwanted posters OUT. For a more high tech solution I can imagine some sort of public or private key needed to make a post - An example being some a public key that was in some manner signed by a trusted member of a list - I am weak on the techincal end/side but basically unless the message is "trusted" it doens't get through. -- habs@acf3.NYU.EDU habs@gnu.ai.mit.edu habs@well.sf.ca.us habs@panix.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Hal <74076.1041@CompuServe.COM> Date: Thu, 17 Dec 92 22:53:06 PST To: CYPHERPUNKS Subject: Positive reps. Message-ID: <921218064714_74076.1041_DHJ46-1@CompuServe.COM> MIME-Version: 1.0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- I was thinking about the idea of positive reputations and thought I'd mention a few thoughts while waiting to see Dean's notes. As I understand it, a positive reputation is basically some kind of recomendation or endorsement of a person by someone else. It might be fairly specific, like "so-and-so paid a debt of $50 to me within the agreed-upon two-week period." Or it could be more general, like "so-and-so is, in my opinion, an honest person." I was thinking of positive reputations that might be relevant to the problem mentioned of anonymous posting to mailing lists and newsgroups. As Dean mentions, we can envision a system which uses the opposite of kill files. Instead, messages would only be displayed from people who met certain criteria in terms of their reputation credentials. What would I want to see in the way of such credentials that would help me decide whether I wanted to read the message? (The issue of judging the validity of credentials is discussed below.) Maybe recommendations in favor of the poster's intelligence, knowledge, judgment, temperance (i.e. reluctance to flame), etc. would be useful. Imagine a system in which a person was rated from 1 to 10 in each of these categories. A person's positive reputation would consist of (digitally) signed statements from various "endorsers" (or "introducers"), each giving their numeric judgements about the person in question. With this system, I could set my ideal mail/news reader to only display postings from people whose scores met some standards. Maybe I would average them; maybe I would weight the different categories according to my own tastes. But this would let me filter out time-wasters like the random poster who was causing problems. Now, this still leaves open the problem of judging the validity of various credentials. This problem is very similar to the problem of accepting key signatures in PGP. If I receive a PGP key loaded with signatures, that doesn't mean much unless I know at least one of the people involved (either directly, or through the net). Only then can I judge how valid the signatures are. In the same way, if a new person posts on a newsgroup, and includes his credential loaded with 10/10/10/10's, that doesn't mean anything unless I know some of these people who are vouching for him. In the most extreme case, he could have created a bunch of false identities and had them provide all the endorsements. So an endorser unknown to me is not useful. It's interesting that the PGP key "web of trust" may have application to this more general problem. I wonder if the PEM folks will push for a centralized "email posting quality" hierarchy in which agencies rate each person's quality of postings and assign them an official score. :-) This would be the analog of their solution to the key-signature problem. That's about as far as I've gotten. A few more general comments: Such a system requires an infrastructure of public-key encryption and digital signatures. Only in that way will signed credentials be secure enough to be meaningful. Since so few people use these tools today, a positive-credential system would filter out almost everyone, throwing out the baby with the bath water. But, remailers are springing up everywhere. It is an idea whose time has come, it seems. So the problem exists today, but the solution can't be practically applied for at least another year or two, even assuming rapid acceptance of PGP, RIPEM, PEM, or some other cryptographic standard. That means that there may be some political pressure against remailers during this interval. Perhaps we can turn this to our advantage by describing the advantages of a credential system, and using that to further encourage widespread use of cryptographic programs. Hal Finney 74076.1041@compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBKzFI+KgTA69YIUw3AQEdCQP8DbPD9jrlR1MhlLOOQrSUc8Svcue2DZsj +DIXiC50bpv+C5pZYtoCa5SuOXX8W6XmZRSkZW3gilvEKDQ2Zt7hH0ol+tFnn8cs q05T1bYJIZqdMdqia6PZkVyvs+DQLuQSog5rZxAja1XfC/Rq59RnbPp2IViLqDiD OfiasXA4Egs= =GVH7 -----END PGP SIGNATURE----- Distribution: CYPHERPUNKS >INTERNET:CYPHERPUNKS@TOAD.COM From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Marc Horowitz Date: Fri, 18 Dec 92 01:08:33 PST To: cypherpunks@toad.com Subject: holiday travel: sign some keys! Message-ID: <9212180907.AA07411@portnoy.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain With the holidays coming up, and many of us traveling to see friends and relatives, we all have a great chance to sign keys of people who aren't in our normal circle of contact. In our web of trust, we need as many long strands as we can get. I recommend that all of you write down your MD5 hashes, and, if you are willing, post your general itinerary if you are traveling so people can get in touch with you, and your key signing policy. It only takes a five minute meeting (unless there's good chinese food conveniently nearby :-) to exchange hashes, then you can email your keyring once you get back home. I'll start. I'll be visiting friends in the Alexandria, VA area saturday and sunday (12/19-12/20), but I won't be reachable via phone easily so if you'll be in that area during that time, email me before noon saturday with contact information. From sunday 12/20 to wednesday 12/23 (I may stay later), I'll be in northern New Jersey (Wayne, to be exact) at my parents' house, phone 201-694-3152. I only sign keys I can verify out-of-band, either in person or by phone with someone I know. So far, all the keys I've signed are people I've known for awhile and see often, so it was easy. I guess I'll make up a new rule: show me a driver's license and another piece of ID (sort of like what you need to cash a check), and I'll trust that you're you. The harder to fake the better; I suppose passports rank high on that list. Maybe I'm crazy for posting all this info saying when I'm going to be out of town, but I think it's worth it in the interest of getting some more connections established (and I've been accused of being crazy many times before, anyway). Marc From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: dclunie@pax.tpa.com.AU (David Clunie) Date: Thu, 17 Dec 92 13:22:55 PST To: cypherpunks@toad.com Subject: No Subject Message-ID: <9212172122.AA00432@britt> MIME-Version: 1.0 Content-Type: text/plain > Here is parts of the article I posted regarding the legality of the use > of emf shielding. Read it carefully, and I suggest you also read the > posted document in full as well. This poses many problems to the public > in general, and the private sector in specific. > PERRY, I suggest you read this. > > NACSIM 5100A is classified, as are all details of TEMPEST. The information may be classified, as perhaps it should be. If I were an organization of any kind trying to protect my data I wouldn't run around publicizing the details of the technology required to protect it either. This does not mean though, that it is illegal to reinvent the wheel and apply it yourself. Besides, who is to say what is an "acceptable" level of EM radiation - the government has clearly chosen what it considers acceptable levels to facilitate equipment supply by contractors. If you want more or less protection then you and any other member of the public are free to define, manufacture or purchase whatever you want. And if you can't get it from a local source I am sure there are plenty of governments and manufacturers elsewhere in the world you can deal with, though of course exporting the technology may be another matter, but there is nothing new about that. There are plenty of other government conspiracies to focus on ! This one seems a bit lame. david From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pozar@kumr.lns.com (Tim Pozar) Date: Fri, 18 Dec 92 08:28:39 PST To: rchilder@us.oracle.com (Richard Childers) Subject: Re: So you want a wide-spectrum signal analyzer ? In-Reply-To: <9212180447.AA06689@rchilder.us.oracle.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Richard Childers wrote: > These capabilities allow spectrum analyzers to provide frequency- > domain signal analysis for numerous applications, including the > manufacture and maintenance of microwave communication links, radar, > telecom equipment, CATV systems, and broadcast equipment ; EMI > diagnostic testing ; and signal surveillance. > > ( I can't believe they actually said that. Gee, I wonder if They're going > to classify test & measurement equipment next. )-: We use them all the time to track down pirate stations and wierd emissions (spurs, harmonics...). BTW... If you have an O-Scope that has X-Y inputs, it isn't that difficult to design and build a low-end, front-end for the scope that will provide the same functions as a spectrum analyzer. > I'm not encouraging you to spoof these folks, merely noting that it is a > regrettable necessity. If you don't present yourself as a prospect, they > may blow you off, and if you give any hint that you don't represent some > sort of company, you are sure to be blown off, presumed to be a waste of > their time. ( Of course, this posting may lead to three or four analyzers, > $ 100-200 thousand worth of sales, but try to persuade a salescritter of > this. :-) I think they partially do this 'cause the catalogs are so bloody expensive to produce. They are an education if you get one. Tim -- Internet: pozar@kumr.lns.com FidoNet: Tim Pozar @ 1:125/555 Snail: Tim Pozar / KKSF / 77 Maiden Lane / San Francisco CA 94108 / USA Voice: +1 415 788 2022 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: deboni@diego.llnl.gov (Tom DeBoni) Date: Fri, 18 Dec 92 09:52:02 PST To: CYPHERPUNKS@toad.com Subject: positive reps and paranoia Message-ID: <9212181748.AA03280@diego.llnl.gov> MIME-Version: 1.0 Content-Type: text/plain I'm just a lurker on this list, trying to pick up on what's happening in this subset of computing and communications, but my chain's been yanked, and the subject merits a reply. On the matter of the discussion that's been going on vis-a-vis reputations versus kill files, I'm afraid we're regressing to the bad old days when everyone was considered bad and worthy of suspicion until they demonstrated that they were good and trustworthy. I'd personally rather believe people are basically good than otherwise. Even if I must occasionally suffer getting burned, it's easier on the nerves, attitude, and karma to assume the best in those I interact with. I think it's significant that there are really so few of us on the net who are actually insufferable and refuse to be shouted down to reasonable behavior by the civil rest of us. Those few who are will not be prevented from troubling us by the measures being advocated - positive reps, scores on 1-to-10 scales, etc. - any more than weapon makers are deterred by manufacturers of armor. someone who really wanted to could still flood our group with vitriol, using multiple artificial identities vouched for by other artificial identities. If such neurotic vengeful behavior were really likely on the net, we'd have seen it already. What, other than good sense and a low threshold of boredom, prevents any of us from flooding any and all news groups with garbage? And if it ever becomes a problem, we'll just have to appoint a moderator, perhaps on a rotating basis, from among those of us who are personally acquainted with each other. My point here isn't that we shouldn't prepare for the worst, but that we shouldn't get crazy about it. The theoretical aspects of the discussion are interesting to me, but I just thought it was getting a little close to the edge not to comment. Tom DeBoni (Once I figure this stuff all out, I'll get a "protected" identity, too.) deboni@llnl.gov From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: miron@extropia.wimsey.com (Miron Cuperman) Date: Fri, 18 Dec 92 02:31:06 PST To: cypherpunks@toad.com Subject: New remailer Message-ID: <1992Dec18.095552.1987@extropia.wimsey.bc.ca> MIME-Version: 1.0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- I've set up a new remailer. I am currently working on extensions. Here are the details: Address: remail@extropia.wimsey.com Contact: miron@extropia.wimsey.com Encryption: PGP 2.1 Syntax: Compatible with Hal-standard remailers, except for a couple of things: - Encryption MUST be used. - Syntax can be simplified. The pasting operator is assumed. The "Encrypted:" header is optional. Accordingly, you can just encrypt plaintext of the following form (without the cut-here lines): --- cut here --- To: --- cut here --- In any case, one should be able to use the scripts posted on cypherpunks without change. Availability: continuous, approx 2 hr turnaround or better. (The keys follow this signed message.) -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBKzGfiZNxvvA36ONDAQHs0AP9EO5eiynLcTZumU7l4I+uLTvwROHR+DVv LfFDV5/dKtSaISQpYvj2RSKYK3NHi2JiCM5vnkNYUWFW1uHcX/BpdOte8IJr2zML /lpEEOYgbi56OGqg2bYhBCbJuh2wY71Ibs5Z5C/1HHsJ8hC334nbOV8pKC+gr+Mi Am+tEzExRyM= =Af9o -----END PGP SIGNATURE----- Remailer Key: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.1 mQCNAisrAP0AAAEEAJr3OwIfOIOoh9JndwwqFg+VyWFTAyM8S0B7wyGKI+A9sMAB mbSOIU52EszvLdZk8NH8mrOD9m3EZlt9gXOjln881RMilAunnzdXaJ6ffBKqPL+l yiefCbCo6wScVNfMSV6Di/2HMoFzVqukwRjTx8lqKt6hgy0uedtwcCemtaMvAAUR tCVSZW1haWxlciA8cmVtYWlsQGV4dHJvcGlhLndpbXNleS5jb20+iQCVAgUQKysE i5NxvvA36ONDAQF2AAP+IQlQxQ9MxuO6WDzIPsuzTxOS5LVrdh3MLWeAkbk+QN3l hrRvEneULh82xOEvZg9whZ+/W8WYtFA4a8g/HbAhuHh4gqQHGakr0SUpKYGpnUWl EBzZjMb+YKMR4UXpusF6ysWUDZ+f0tDbUDq0ukCoRZRq8wyIf9mndSfaqcsyfyGJ AEUCBRArKwPUS60iYsR4D/cBATXBAXsFqc8sCpP0gQ8KHF3myZrE+s7oP2nu/FP3 LvZE1+ttF3I9c6jncfWPT6cHpvWEoWk= =ZZ5t -----END PGP PUBLIC KEY BLOCK----- My key: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAiqvJ10AAAED/jXfntqmsRjJRYoxYTxLO7obzMfzgUNtSDEawb3Suj4UO1xq uARc25PJNAHQhIa83Yxf9z/R/3AjwmYrZqxvB2RkLPTjTmzQd04fypsZToiR/TlM 5F43JCuCM779mAir9Idy1CQzXQ2bn89eUZaVhOUJzNgndl+wLpNxvvA36ONDAAUR tCxJbW1vcnRhbCBGcmVlZG9tIDxtaXJvbkBleHRyb3BpYS53aW1zZXkuY29tPokA lQIFECsXPLSTcb7wN+jjQwEBv20D/jIKu8z9DP+wTLLWYZZax9wnJJzRkD9//kFA C0is6LMNMSSX0yGwOPmqEI710BSovuTAlNBmqBrMrl0Bp5bsxpCN8Fw3Mc0ex5fe 1efockVjXNLMP0G4plr0AFMA4KXNE+MfwLFMd+Gcdxufro0yKoBygsHwQ+om+rut RPIy89/PiQBFAgUQKwxwHUutImLEeA/3AQGQnQF8D0Zdrrz+kMAguOANBhbnxm5t zak4TWg37hp/iU2CEfIbW/IUVIPEjNhvM6cjZ1jQ =/SVk -----END PGP PUBLIC KEY BLOCK----- -- Miron Cuperman | NeXTmail/mime ok | Public key avail AMIX: MCuperman | cybercomputingimmortallaissezfaire | From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Fri, 18 Dec 92 11:24:15 PST To: cypherpunks@toad.com Subject: Re: Patent Infringement Message-ID: <9212181618.AA29313@maggie.shearson.com> MIME-Version: 1.0 Content-Type: text/plain > From: yanek@novavax.nova.edu (Yanek Martinson) > > > "I'm sorry to say that yes, it *IS* illegal to reinvent the wheel and > > apply it yourself. In the US it is called "Patent Infringement"." > > > > Only if you attempt to sell it ... > > No. The patent law prohibits anyone from "making, using, or selling" > anything covered under the patent. Selling it makes it more likely > that the patent holder will come after you, as they have a greater > chance of getting some money from you. > > I am not a lawyer, I am sure someone here can explain all this in > greater detail, or correct me if I'm wrong. This is one of the sillier threads I've seen in a while. Is anyone here arguing seriously that RFI shielding your equipment is a patented technology? Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Fri, 18 Dec 92 11:49:01 PST To: cypherpunks@toad.com Subject: Re: The Need for Positive Repuations Message-ID: <9212181645.AA29793@maggie.shearson.com> MIME-Version: 1.0 Content-Type: text/plain > From: tcmay@netcom.com (Timothy C. May) > The longterm solution is to use "positive reputations" and not just > "negative reputations" (as in Kill files). This is something Dean > Tribble just talked about at our last physical meeting of the > Cypherpunks ("Bay Area Branch" :-} ). > > Think of like a credit rating. People _earn_ trust, they don't just > get assigned a credit rating until they do something bad. Indeed, in the long run, when there are billions of people in the nets, even UseNet newsgroups devoted to people who use musical instruments as sex toys would have thousands of posts a day because given billions of possible subscribers, finding a few tens of thousands with a particularly obscure interest wouldn't be hard. Thus, in the long run, the nets will move to "closed" newsgroups and mailing lists in which to be a subscriber one will have to be explicitly subscribed to a list and will only be able to read with one's private key and post by digitally signing messages. In such an environment, anonymous abusers will simply be incapable of annoying people. A weak version of this exists already in the Extropians mailing list, which considers itself to be a closed list. The list is governed by a privately produced legal code (its in some ways a test of anarchocapitalist legal theory), and since the adoption of the code, we've had a reduction of flaming by a large factor even though we've seen a three fold increase in list size. The content is improving because people know that sanctions will be applied for flaming and that they can actually be kicked off the list, and that being kicked off is meaningful. In the long run, all serious discussion groups will likely evolve in this direction, with the lists being closed to explicit subscribers and with meaningful sanctions like ostracism being applied to people that behave in an antisocial manner. Such lists have little reason to fear people hiding behind cloaks of anonymity. With digital signatures, even the anonymous can develop meaningful reputations and can be sanctioned for failing to live up to those reputations. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Derek Atkins Date: Fri, 18 Dec 92 08:55:19 PST To: Marc Horowitz Subject: Re: holiday travel: sign some keys! In-Reply-To: <9212180907.AA07411@portnoy.MIT.EDU> Message-ID: <9212181654.AA05651@deathtongue.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain I like the idea! Anyways, being one of the people who has cross-signed with marc, and hoping to increase our web of trust.... I'll be in the NorthEast Ohio region for about 2 weeks, 21Dec-4Jan, with a small stint in Brampton, Ontario over New Years... My Cleveland contact number is (216) 292-5845. I don't have a contact number in CA, so you'll have to either e-mail me by this weekend or get ahold of me in Cleveland. Like marc, I like to sign keys out-of-band. I'll have my key fingerprint for anyone who wants it. I hope to see some of you over the holiday season! -derek From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: wendtj@jplpost.Jpl.Nasa.Gov (Jeffrey P Wendt) Date: Fri, 18 Dec 92 14:18:16 PST To: cypherpunks@toad.com Subject: The Wheel Message-ID: <9211187247.AA724710372@jplpost.jpl.nasa.gov> MIME-Version: 1.0 Content-Type: text/plain Has anyone built there own TEMPEST reciever/antenna equipment? I have seen articles that say that you can use old television sets, and that you can build more advanced TEMPEST unit for a hundred dollars. This seems akin to the carburator that will give you 200 mpg, and plans for a particle beam cannon in the back of some zines. If this is so cheap and easy or cheaper-quicker-better (NASA-Goldin-TQM propoganda), then why haven't we seen an article/articles on the construction of a TEMPEST reciever and the associated tuning/specs on such an item. Is it possible, or nothing more than snake oil? JPW From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Fri, 18 Dec 92 10:29:44 PST To: deboni@diego.llnl.gov (Tom DeBoni) Subject: Reputation Systems In-Reply-To: <9212181748.AA03280@diego.llnl.gov> Message-ID: <9212181828.AA25958@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > it's easier on the nerves, attitude, and karma to assume the best > in those I interact with. But you can not interact with everyone that that has the technical means to post a message. If you can now, somehow, (you can't do much else if you want to keep up with 50MB per day), then in the near future you will not be able to. So, you need a way to pick who to interact with. > I think it's significant that there are really so > few of us on the net who are actually insufferable and refuse to be shouted > down to reasonable behavior by the civil rest of us. Those few who are will If you are referring to the current state of the UseNet, then I suggest that you keep in mind that until fairly recently the access was mostly limited to people in universities, and research departments of hi-tech corporations. This is a highly selected group of people, and can not be compared to the "general public". As communications technology becomes cheaper, more widespread and accessible to anyone that wants to, and eventually ubiquitous like the telephone is now, the number of people that will be able to "interact" will be much greater. In general, I view this as a good thing. Unfortunately, the ratio of people that I would find _interesting_ or _usefule_ to "talk" to in relation to the total number of people I _can_ talk to will decrease dramatically. > not be prevented from troubling us by the measures being advocated - positive > reps, scores on 1-to-10 scales, etc. - any more than weapon makers are > deterred by manufacturers of armor. someone who really wanted to could still I don't think anyone intends to use reputation systems to prevent someone from posting a message, instead as a means to easily filter the messages you personally want to read. Or maybe even not filter, but as some suggested, _sort_. So you would first read (and reply to) the messages of people with a higher reputation for writing informative articles, or participating in interesting discussions. To some extent, this already is already occurring. If there are some people that you remember from the past as interesting people to talk to, you are more likely to read their messages. An automated system would let you benefit from other peoples' memories. > groups with garbage? And if it ever becomes a problem, we'll just have to > appoint a moderator, perhaps on a rotating basis, from among those of us who Think of a reputation system as being a distributed moderator. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: jthomas@kolanut.mitre.org (Joe Thomas) Date: Fri, 18 Dec 92 12:20:39 PST To: cypherpunks@toad.com Subject: Re: The Need for Positive Repuations Message-ID: <9212182019.AA00438@kolanut> MIME-Version: 1.0 Content-Type: text/plain > From: tcmay@netcom.com (Timothy C. May) > The longterm solution is to use "positive reputations" and not just > "negative reputations" (as in Kill files). This is something Dean > Tribble just talked about at our last physical meeting of the > Cypherpunks ("Bay Area Branch" :-} ). > > Think of like a credit rating. People _earn_ trust, they don't just > get assigned a credit rating until they do something bad. >From: pmetzger@shearson.com (Perry E. Metzger) >Indeed, in the long run, when there are billions of people in the >nets, even UseNet newsgroups devoted to people who use musical >instruments as sex toys would have thousands of posts a day because >given billions of possible subscribers, finding a few tens of >thousands with a particularly obscure interest wouldn't be hard. >Thus, in the long run, the nets will move to "closed" newsgroups and >mailing lists in which to be a subscriber one will have to be >explicitly subscribed to a list and will only be able to read with >one's private key and post by digitally signing messages. In such >an environment, anonymous abusers will simply be incapable of >annoying people. Yes, but there will still need to be a way for new people to join the lists, (and the net in general) before they've had a chance to "prove themselves." Allowing all new id's to post to the whole group on a probationary basis is unacceptable; as soon as someone proves obnoxious enough to kick off they could just start over with a new id. The obvious answer is that a moderator will be necessary for all closed lists that require a positive rep for posting and that don't wish to be forever limited to their founding members. After a few lucid posts passed by the moderator, an individual would gain enough of a reputation not to be filtered out any longer. Of course, anyone who's heard Howard Stern fans invade political call-in shows will realize there's not much that can be done with those weird people who will spend a lot of time and energy to appear credible, only to annoy people. Joe From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tcmay@netcom.com (Timothy C. May) Date: Fri, 18 Dec 92 15:55:47 PST To: cypherpunks@toad.com Subject: Re: The Need for Positive Repuations In-Reply-To: <9212182252.AA06643@tla> Message-ID: <9212182354.AA14872@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Marc writes: > Go read Ender's Game. They had a seriously electronic society. There > were public message boards, and positive-reputation-based boards. > Basically, if you demonstrated a clue on the public boards, then > someone already reputable could recommend you for "membership" in the > reputation-based boards. One of the characters did so anonymously. > She even got paid for writing editorials, etc. Anybody could watch > the proceeedings of the reputeable boards. In time, she was competing > in debates with major politicians, et. al. Sci-fi? or Reality? I > believe we could move from the former to the latter. (And I just > avoided any sort of spoiler about the plot ;-) Exactly! "Ender's Game," by Orson Scott Card, and "True Names," by Vernor Vinge, are the two books I've been recommending since I coined the term "crypto anarchy" in 1987. I held these books up in a couple of talks I gave at BayCon (SF convention) and the Hackers Conference and said "Read these books!" A couple of folks have said that newcomers will never be listened to, will never "get in" to positive reputation systems. This simply isn't true, even with today's "manual" reputation management systems. On the two main lists I subscribe to, this list and the Extropians list (send request to Extropians-request@gnu.ai,mit.edu if interested in future stuff, anarchocapitalism, nanotech, cryonics, etc....about a dozen folks on this list are also on Extropians, I would guess), newcomers start making posts and gradually the list gets to know their name, what to expect of them, etc. This is their "rep." Serious flamers or abusers see their rep torn down. (A list I just joined is the Pynchon list...actually, one of them saw my "W.A.S.T.E. line in my .sig and _invited_ me to join. As a newcomer to that list, I have no reputation. What I say and how reasonably I say it will establish my rep. This is as it should be.) If people want to see the posts and comments of newcomers, even those without extensive history on the list or glowing reps, then they will likely set their "agents" to allow the new stuff through. Lots of variations are possible and will be tried. Think about positive reputations and you'll see them in action all around you...where you shop, what you read, who you associate with, etc. The Net will ultimately be no different. --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: by arrangement. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: habs@acf3.NYU.EDU (Harry A. B. Shapiro) Date: Fri, 18 Dec 92 12:54:54 PST To: cypherpunks@toad.com Subject: Re: The Need for Positive Repuations In-Reply-To: <9212182019.AA00438@kolanut> Message-ID: <9212182054.AA11836@acf3.NYU.EDU> MIME-Version: 1.0 Content-Type: text/plain A conscious being, Joe Thomas, wrote in a previous message: > Yes, but there will still need to be a way for new people to join the > lists, (and the net in general) before they've had a chance to "prove > themselves." There will always be the Sear credit cards of news groups. Those that will let almost anyone in - just so they can prove themselves. -- habs@acf3.NYU.EDU habs@gnu.ai.mit.edu habs@well.sf.ca.us habs@panix.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tribble@xanadu.com (E. Dean Tribble) Date: Fri, 18 Dec 92 17:35:03 PST To: cypherpunks@toad.com Subject: reputations talk notes Message-ID: <9212190048.AA04870@xanadu.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain These are the notes from my talk at the last meeting. They may only be parsable by people who saw the talk, but I'm interested in all comments. Thanks to Mark Miller and Eric Drexler who helped me put together these notes the first time. The need for reputations: single Prisoner's Dilemna incentive for defecting iterated Prisoner's dilemna incentive for cooperating reps put each person in an iterated situation with the group better reputations reduce reputation float (see below) Spreading reputations makes them better at encouraging cooperation Uses of reputations: sorting filtering - this is just bad sorting collateral - for business and important trust issues let me add that reputation appication is largely on the receiving side Negative reputations: don't work with anonymity because you just make another identity don't spread for psychological and legal reasons many people won't reveal negative opinions about others people primarily support filtering and collateral Positive reputations: are safer to reveal and spread allow sorting can handle anonymous pseudonyms Anonymity: reduces perceived and actual accountability breaks many of our trained intutions for trusting others implicit but unrevealed assets aren't at risk trade names are examples of non-anon. pseudonyms Reputations systems for sorting mail are less of an issues than reputations systems for actual business because there is less at risk. Gaming of a reputation system depends on how much is at risk. Brilliant Pennies: randomly generated reputations the con game: start with 1000 pennies flip them every day. head the stock market goes up, tails it goes down throw out pennies that 'guessed' wrong at the end of ten days you have a penny with a 'reputation' for predicting the stock market sell the penny anonymously :-) inconsistent positive reputations are better than perfect reputations can explain away first several mistakes Assets that support an identity recoverable assets anything that can be recovered in the even of a defection bank accounts, goods, factories, etc. pseudonyms typically won't have recoverable assets pseudonyms could keep recoverable assets in a non-anonymous escrow can be anonymously and privately committed to more than one party in the event of a defection, so value can't properly be assessed unrecoverable assets Sunk costs time, money spent building a reputation solves the Brilliant Penny problem: random rep requires huge investment a 30day coin-flipping rep requires more pennies than exist notarized money-destruction service: proves investment with no route for kickbacks to the investor demonstrates the comparative cost of running an anon. service our intuitions about sunk costs can be very wrong here we're used to sunk costs at least looking recoverable (liquidation) we're used to eventual personal accountability of decision maker sunk costs enable kill files again you can only afford so many pseudonyms this is relates to the Brilliant Penny solution reputation capital (perceived value of reputation) customer good will, market share, shelf space, customer mind-space, etc. priority settings in receivers's mail handlers (filters, sorters) future sales potential based on the net present value of the reputation perceived differently by different individuals (customers/producer) based on discount rate (subjective value of money now vs. money later?) perception of discount rate can change radically you are told you have 6 months to live Reputation Float: latency between use of a reputation and the effect on the value of the reputation how long can you ride on past glory? this includes the amount of goods, etc. against which the reputation is collateral existing trade-names collateralize the quality of existing goods (i.e. cars) estimating reputation float is a public goods problem why should I reveal the goods I have outstanding if I can get the info anyway insurance (Idea Futures) doesn't help the anonymous could collect both from defaulting and from insurance our intuitions screw up at estimating this we're not used to untraceable transactions Miscellaneous: filtering/sorting reputations should be wrt to topics This generalizes to other criteria individuals have different levels of expertise in different areas synthesized reputations are reputations composed from multiple reputations chaining remailers composes their reputations for security voting among key providers composes their uncompromisability reputations From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: tribble@xanadu.com (E. Dean Tribble) Date: Fri, 18 Dec 92 17:35:04 PST To: cypherpunks@toad.com Subject: reputations Message-ID: <9212190101.AA04917@xanadu.xanadu.com> MIME-Version: 1.0 Content-Type: text/plain Since I have a reputation for talking about reputations.... You are already engaged in a positive reputation system. Which email lists are you on? Which newsGroups do you bother with? what TV shows do you watch? New instances of all of these pop up and succeed all the time. Negative reputation systems work very poorly. Right now I receive cypherpunks. I used to receive Extropians (and will do so again soon). The volume can get horrific at times. Consider all the stuff that I'm not receiving (that I filtered out). I don't see sci.nanotech, sci.crypt, alt.pgp (?), libernet, alt.politics, alt.sex.bondage, etc. because I haven't the bandwidth. Ah, but if I could pick and choose among the entire available feed rather than ignoring most of it just so I have a hope of filtering down to a manageable mail load.... That's what positive filters are for. There are lots of gems buried in the crap of net-news (and remember that my gems may be your crap), and I want a system that will find them for me. I think the approach of reputation filtered mailing lists is a bad one. That reputation filtering process is simply a poor mechanism to avail us all of the moderator's taste in email. If we had a better mechanism, then such a list is just alt.extropy or sci.crypt where things are prioritized (using the positive prioritixing information of such people who would otherwise be moderators) such that I see the good stuff and ignore the bozoz (whomever they are). Or in the more likely case, I just see the creme de la creme of the good stuff because that's all I have time for. In such a system, one can think of a magazine as simply purchasing the editor's priority information. Paul Baclace built a genetic algorithm thing that would present netnews from all groups in prioritized order. As you gave it feedback on how glad you were to receive each message, it didi pattern matching on features of the messages to make better sorters. This ends up correlating author (anonymous or otherwise), subjet, topic, reply chain, time of day, whatever seems relevant into the prioritization of mail. If those weight could be spread, combined with manually entered filters ("I'm tired of politics..."), etc. you might actually be able to spend less time on email/news getting more value from it. dean From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: 2FTPHAVOC@kuhub.cc.ukans.edu Date: Fri, 18 Dec 92 15:24:06 PST To: cypherpunks@toad.com Subject: Patently false rumor Message-ID: <01GSGW2OK9420056TH@KUHUB.CC.UKANS.EDU> MIME-Version: 1.0 Content-Type: text/plain I just finished reading the Mondo 2k article on cypherpunks. I was hoping to find out some more info on !encrytption software. All rumors are built on a grain of truth, aren't they? From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Marc Horowitz Date: Fri, 18 Dec 92 14:53:18 PST To: cypherpunks@toad.com Subject: Re: The Need for Positive Repuations In-Reply-To: <9212182054.AA11836@acf3.NYU.EDU> Message-ID: <9212182252.AA06643@tla> MIME-Version: 1.0 Content-Type: text/plain Go read Ender's Game. They had a seriously electronic society. There were public message boards, and positive-reputation-based boards. Basically, if you demonstrated a clue on the public boards, then someone already reputable could recommend you for "membership" in the reputation-based boards. One of the characters did so anonymously. She even got paid for writing editorials, etc. Anybody could watch the proceeedings of the reputeable boards. In time, she was competing in debates with major politicians, et. al. Sci-fi? or Reality? I believe we could move from the former to the latter. (And I just avoided any sort of spoiler about the plot ;-) Imagine a system where spaf distributed the public key of the moderator(s) of a moderated newgroup. News servers would make sure that the message was signed by the moderator, or that the poster included some sort of certificate, signed by the moderator, indicating that he could post without having to go through the moderator first. Expirations and/or revocation lists would be needed to do things right, but these are problems with fairly good solutions. Marc From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: mark@coombs.anu.edu.au (Mark) Date: Fri, 18 Dec 92 01:16:11 PST To: cypherpunks@toad.com Subject: TEMPEST/Van Eyck data Message-ID: <9212180915.AA16502@coombs.anu.edu.au> MIME-Version: 1.0 Content-Type: text/plain From: strat@intercon.com (Bob Stratton) >It's weird stuff, and some people would rather not have the world >learning how to do this. In fact, Van Eck's original article is known >to have some deliberate misinformation in it, as the author didn't >want to make it "too easy" to learn how to do this kind of ELINT. Ever realised that some things come along that just tickle your curiosity nerve and you wont let go until your satisfied? Im sure there are individuals and organisations out there that would love an excuse to shut down lists of this type, especially considering the type of information and the implications in the not too distant future if people start implementing half the concepts that are presented here. I would like to see indepth technical information, or at least pointers to said information presented here. Does anyone know of mailing lists out there that concentrate on levels of computer emissions and methods of diminishing them to negliable amounts? Where would one obtain copies of articles on the subject? I have saved the article posted by treason@gnu as it does contain a lot of references which give one something to go on. I commend him for posting it for it's informational content. It wasnt his fault it may have contained obselete or inaccurate information. So, anyone have lists of books, periodicals, email lists or papers that discuss the topic of computer RF emissions and how to protect a machine *AND* monitor the levels of others? Mark mark@coombs.anu.edu.au P.S. That NASA guy had better watch for list members waiting for the postie so they can collect the goodies before he can :) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: edgar@spectrx.Saigon.COM (Edgar W. Swank) Date: Sat, 19 Dec 92 08:09:32 PST To: Cypherpunks Subject: Remailer Policies Message-ID: MIME-Version: 1.0 Content-Type: text/plain I would like to expand on Hal's suggestion that remailer operators post their policies on a)keeping logs and b) divulging same. Hal says he keeps logs "for a few days" and might divulge logs of "really vicious, racially or sexually harrassing" messages. Presumably this would also cover anonymous threatening messages, blackmail, etc. We've already discussed use of PGP by pedophiles to encrypt incriminating diaries. It gets better. PGP and remailers can be used to encrypt and ship "kiddy porn" GIF files. Even private possession of such material is a serious crime in the USA. A chain of anonymous and encrypted remailers could be used to drop kiddy porn into newsgroups like alt.sex.pictures I'm sure that would create quite a stir! Perhaps Duncan or another attorney would like to comment on legal liability of remailers in these kinds of situations. I don't think there's currently any law on what records remailers would have to keep; if you didn't have them, you couldn't give them up. If this becomes a problem, expect legislation regulating or even outright banning remailers. However, if remailer code has spread over many national boundaries, such legislation may not be effective. By the way, no-one has yet responded to my request to add features to Eric's remailer to 1)remove the "sig" after "--" and 2)Anonymously post to newsgroups available at the remailer site. Both these features are present in the Australian remailer at Pax. Unfortunately that remailer seems less secure than Eric's in that it keeps more or less permanent records of its users at the remailer site and it doesn't seem to be able to chain to other remailers. -- edgar@spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: peter honeyman Date: Sat, 19 Dec 92 05:56:01 PST To: yanek@novavax.nova.edu (Yanek Martinson) Subject: Re: Reputation Systems In-Reply-To: <9212181828.AA25958@novavax.nova.edu> Message-ID: <9212191355.AA24847@toad.com> MIME-Version: 1.0 Content-Type: text/plain i should think that a middle ground would be suitable, in which people keep a hot list and an "other" list, with perhaps a kill list as well. peter From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Sat, 19 Dec 92 10:30:47 PST To: honey@citi.umich.edu (peter honeyman) Subject: Re: positive rep In-Reply-To: <9212191759.AA01309@novavax.nova.edu> Message-ID: <9212191829.AA02189@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > but how do you know who to add to the positive rep list? take netnews, > e.g. i generally scan a group for names i know (+ rep), then read For example, all mail/news reader software would have a function where after reading the article you could press a key to indicate you found the article useful/informative/interesting. What it would do is send the person a "certificate", which in essence says "I recommend reading messages by this person", signed cryptographically with your signature. These certificates could be appended to messages by that person, or posted to some special newsgroup just for that purpose (similar to "control"), or distributed through some other means. If several people to whom you have assigned high credibility recommend messages by a person, then your news software would automatically sort his messages to appear higher in the list before other people's messages, and also that person's recommendations would have a higher weight in computing other people's sort values. All this pre-supposes widespread use of authenticated messages, so someone could not forge himself some certificates from well-known people. Also, it would not allow a J. Random to forge a post that appears to be from a person with high reputation. The technology for such communication exists now (PGP, MD5, RSAREF, etc) it is just not integrated into most news/mail software. Unlike negative reputations, positive reputations are immune to subversion by creating many anonymous or pseudonymous identities. You might imagine someone creating two hundred "people" and have them all send him their "certificates". But this would not work, since no-one has recommended these people, their certificate would carry no weight whatsoever. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: gnu (John Gilmore) Date: Sat, 19 Dec 92 14:46:06 PST To: cypherpunks@toad.com, gnu Subject: TEMPEST Message-ID: <9212192246.AA05562@toad.com> MIME-Version: 1.0 Content-Type: text/plain > There are plenty of other government conspiracies to focus on ! This one > seems a bit lame. Our government should not be our opponent when we try to find out how to provide high levels of privacy for ourselves, our computers, and our communications. Ignoring that, yes, TEMPEST doesn't look like a deep dark conspiracy. It's legal to shield your equipment and probably legal to export it (if you didn't use the classified TEMPEST specifications in building it, but reverse engineered them yourself). The government is not our enemy here (like it *is* our enemy in the drug war), but it isn't our friend either. John Gilmore From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Hal <74076.1041@CompuServe.COM> Date: Sat, 19 Dec 92 16:52:59 PST To: CYPHERPUNKS Subject: Remailers. Message-ID: <921220004532_74076.1041_DHJ42-1@CompuServe.COM> MIME-Version: 1.0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Responding to Edgar Swank's message: > We've already discussed use of PGP by pedophiles to encrypt > incriminating diaries. It gets better. PGP and remailers can > be used to encrypt and ship "kiddy porn" GIF files. Even private > possession of such material is a serious crime in the USA. A chain > of anonymous and encrypted remailers could be used to drop kiddy porn > into newsgroups like > > alt.sex.pictures > > I'm sure that would create quite a stir! This could easily happen soon, as news of these remailers spreads. There's been talk on the net about a student at an Ivy League college who is being investigated by the FBI for allegedly posting illegal images containing child pornagraphy. Once people find out about anonymous remailers, especially ours with their chaining capabilities and encryption, they will realize that such posts can be made with almost total safety. Presumably this may increase the number of people who would attempt it. > Perhaps Duncan or another attorney would like to comment on legal > liability of remailers in these kinds of situations. I don't think > there's currently any law on what records remailers would have to > keep; if you didn't have them, you couldn't give them up. > > If this becomes a problem, expect legislation regulating or even > outright banning remailers. However, if remailer code has spread > over many national boundaries, such legislation may not be effective. My guess is that it will not be feasible to ban remailers, since it would be hard to draw the line between completely automated remailers, and simple manual forwarding of a message that someone sent you, which happens all the time and can hardly be made illegal. I suspect that instead the approach would be to claim that remailer operators are responsible for the material their remailers produce, regardless of its original source. So if child porn comes out, I am guilty of sending child porn. I can argue that my remailer was automatic and that I shouldn't be held responsible for what comes out of it, but my guess is that this argument will be rejected on the grounds of personal responsibility, and because no one forces me to run a remailer which sends out anything that comes in to it. Such a policy would be a plausible extension of current Internet policies, IMO. RFC 822, the document which describes the format of Internet mail message, in session 4.4.2 discusses the "Sender:" field, and says, "Since the critical function served by the 'Sender' field is identification of the agent responsible for sending mail and since computer programs cannot be held accountable for their behavior, it is strongly recommended that when a computer program generates a message, the HUMAN who is responsible for that program be referenced as part of the 'Sender' field mailbox specification." [Capitalization in the original.] The need for a person to take responsibility for each piece of mail that is sent would tend to lead to the policy I mentioned. With such a policy in place, if enforced by law, I don't think people would run remailers in this country because of the legal risks. There would still be the international remailers, though. > By the way, no-one has yet responded to my request to add features > to Eric's remailer to 1)remove the "sig" after "--" and 2)Anonymously > post to newsgroups available at the remailer site. Both these > features are present in the Australian remailer at Pax. Unfortunately > that remailer seems less secure than Eric's in that it keeps more or > less permanent records of its users at the remailer site and it > doesn't seem to be able to chain to other remailers. > > -- > edgar@spectrx.saigon.com (Edgar W. Swank) > SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca It should be possible to chain from Pax to our remailers, getting the best features of both. Pax could be the first remailer in the chain, stripping the sig. The message could then go through our remailers, providing non-traced security, at least if you can find someone who does not keep logs. Anonymous posting can be done already. Anyone can post to most newsgroups by sending mail to certain addresses. One such system is at Berkeley. Send to, e.g., sci-crypt@ucbvax.berkeley.edu to post to sci.crypt. There is another such system running in Austin, TX, I believe, but I don't have the corresponding net address handy. So this capability is already provided by our (or anyone's) remailers. One reason I haven't looked at stripping the .sig is due to an email discussion I had about a month ago with Eric Hughes. Eric strongly felt that message bodies should be preserved as much as possible by the remailers, in accordance with the general principle of Internet mail forwarding. Too much mangling is done already by mail gateways, and adding more changes might be harmful. Obviously, the remailers can't avoid doing some processing of the message body, what with the "::" pasting tokens and PGP decryption, but Eric felt that unnecessary changes should be minimized. I know Eric is working on some new remailer concepts so I want to defer to him on this issue for now. Hal Finney 74076.1041@compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBKzOXf6gTA69YIUw3AQEvQQQArHXSwwrkQ3mSGOD60ZBV/p1R9RONqv2x S64iJjdJB43G2nxLHB2t9xXAKSdCT00shEtil8LWu20XW0rWXqmMXyYudtt3qf3t 2arqlvxdGXlPt3eISFJ97U6jaI1EhswPg29fjuXMMaKv5OO/gBKp1i9Cig7suZDt EkUDJihLQxc= =q6zH -----END PGP SIGNATURE----- Distribution: CYPHERPUNKS >INTERNET:CYPHERPUNKS@TOAD.COM From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Hollander Date: Sun, 20 Dec 92 00:02:57 PST To: dclunie@pax.tpa.com.au (David Clunie) Subject: Re: Remailer Policies In-Reply-To: <9212192250.AA01396@britt> Message-ID: <9212200800.AA20904@soda.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain >The anonymous mailing system at pax has the following policy: > > - A log of activities of the remailing software is maintained when > debugging is in progress (often) which could be used to correlate > real identities with aliases - this is no more or less information > than is available in the alias database which is not visible to > anyone except the root user. Message-id's are NOT stored in this log, > and the contents of messages and posts are NOT stored anywhere, nor > are they scrutinized by me or anyone else. I don't care and I don't > want to know. If someone does something unreasonable and I get > complaints then I could lock out a particular source of mail if > I didn't get a good explanation, but I am not going to go reading > other peoples mail in order to censor it ! I keep logs on content and origin on my three remailers. I do read the logs. However, I would not censor any transmissions. I would stop accepting mail from a site given enough reasonable complaints. > - Under no circumstance short of being arrested and/or the equipment > commandeered by someone else will the alias database be divulged > or the contents or routes of messages deliberately intercepted. Dido for me. I would make an attempt to destroy all of my data if an attempt were made to take the equipment or access the data by a government or other agency. e From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: "DrZaphod" Date: Sun, 20 Dec 92 09:54:49 PST To: CypherPunks@Toad.Com Subject: Avoiding snags in the Law : Remailers. Message-ID: <24020.drzaphod@ncselxsi> MIME-Version: 1.0 Content-Type: text/plain In Message 19 Dec 92 19:45:33 EST, Hal writes: >I suspect that instead the approach would be to claim that remailer >operators are responsible for the material their remailers produce, >regardless of its original source. >Such a policy would be a plausible extension of current Internet >policies, IMO. RFC 822, the document which describes the format of >Internet mail message, in session 4.4.2 discusses the "Sender:" field, >and says, "Since the critical function served by the 'Sender' field >is identification of the agent responsible for sending mail and >since computer programs cannot be held accountable for their behavior, >it is strongly recommended that when a computer program generates a >message, the HUMAN who is responsible for that program be referenced >as part of the 'Sender' field mailbox specification." [Capitalization >in the original.] The need for a person to take responsibility for >each piece of mail that is sent would tend to lead to the policy >I mentioned. > Perhaps the solution to this is to run encrypted remailers, anonymously. The remailer could either run on it's own, or under instructions by an anonymous source [i.e PGPed instructions and software updates signed by the owner who has created a second key for his identity of remailer operator [Let's call him Oz]. Example: Joe creates an account on a random system, installing the nessicary software to run a PGP remailer. This software would be modified to accept instructions from a specific anonymous identity, for which Joe creates one, leaving the public key with the remailer. The remailer also has it's own key pair to decrypt and forward messages [of course]. People could now route their messages through Joe's remailer to anywhere they wish. The remailer should be set up to NOT keeps logs, except errors. Now Joe decides he wants to update his remailer with the latest scripts. He mails te scripts [thru various remailers], encrpyted with the remailers key and signed by Oz's key. The remailer decrypts the mail, verifies that it belongs to Oz, and updates itself. In this way no person can be held responsible for mail passing thru it's remailer. The only way to stop such a remailer would be to downright shut it down, or to communicate to Oz via the remailer [the scripts would allow Oz to pick up any mail left directly to the remailer withour a forwarding header -- of course it would reroute the messages, encrypted, thru various other well-known remailers]. TTFN! DrZaphod [AC/DC] / [DnA][HP] [drzaphod@ncselxsi.uucp] Technicolorized From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Sun, 20 Dec 92 05:45:43 PST To: hh@soda.berkeley.edu (Eric Hollander) Subject: Destroying Data (Re: Remailer Policies) In-Reply-To: <9212200800.AA20904@soda.berkeley.edu> Message-ID: <9212201344.AA26203@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > logs. However, I would not censor any transmissions. I would stop > accepting mail from a site given enough reasonable complaints. That would not help in the least. The person can still send mail through your system, they would just not use you as the first hop. > Dido for me. I would make an attempt to destroy all of my data if an > attempt were made to take the equipment or access the data by a government Make sure you don't think 'rm -rf /remailer-logs' actually destroys data. It merely de-allocates the i-nodes. You need to know which physical device the filesystem is on, (let's call id /hdxxx) and then do 'cat /dev/null > /dev/hdxxx' which overwrites with zeroes all data on that partition. For that reason it may be preferable to keep all such information opn a filesystem of their own, so you don't have to destroy much other data along with it. If you use swapping or paging, you need to clear out those devices too, and then turn the machine off to remove all data in RAM. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: dclunie@pax.tpa.com.AU (David Clunie) Date: Sat, 19 Dec 92 14:50:47 PST To: cypherpunks@toad.com Subject: Re: Remailer Policies Message-ID: <9212192250.AA01396@britt> MIME-Version: 1.0 Content-Type: text/plain > I would like to expand on Hal's suggestion that remailer operators > post their policies on a)keeping logs and b) divulging same. > The anonymous mailing system at pax has the following policy: - A log of activities of the remailing software is maintained when debugging is in progress (often) which could be used to correlate real identities with aliases - this is no more or less information than is available in the alias database which is not visible to anyone except the root user. Message-id's are NOT stored in this log, and the contents of messages and posts are NOT stored anywhere, nor are they scrutinized by me or anyone else. I don't care and I don't want to know. If someone does something unreasonable and I get complaints then I could lock out a particular source of mail if I didn't get a good explanation, but I am not going to go reading other peoples mail in order to censor it ! - Under no circumstance short of being arrested and/or the equipment commandeered by someone else will the alias database be divulged or the contents or routes of messages deliberately intercepted. david From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: bart@netcom.com (Harry Bartholomew) Date: Sun, 20 Dec 92 09:53:45 PST To: cypherpunks@toad.com Subject: Re: Destroying Data Message-ID: <9212201752.AA24549@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain In audio recording which uses magnetic media similar to disks the only way to thoroughly erase a tape is with a so-called bulk eraser. This applies a very strong a.c. magnetic field and then is gradually withdrawn from the tape to allow the residual magnetism to "follow the hysteresis curve" down to zero. This would be difficult to apply to disks except floppies. Consider also the technique used in the Norton Utilities program "Diskwipe" which takes a /g switch which "Follows certain government rules for wiping". I can't find the manual but I think it specifies how many repetitions are used and different values to write in each. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: miron@extropia.wimsey.com (Miron Cuperman) Date: Sun, 20 Dec 92 03:25:01 PST To: cypherpunks@toad.com Subject: Remailers and liability Message-ID: <1992Dec20.105340.11707@extropia.wimsey.bc.ca> MIME-Version: 1.0 Content-Type: text/plain Here is a post which is somewhat relevant: >Newsgroups: alt.censorship,news.admin.policy,comp.org.eff.talk >From: nagle@netcom.com (John Nagle) >Subject: Appeals court declares child pornography law unconstitutional >Message-ID: <1992Dec17.232618.19727@netcom.com> Summary: New decision by Ninth Circuit may affect BBS operators >Keywords: law pornography >Organization: Netcom - Online Communication Services (408 241-9760 guest) >Date: Thu, 17 Dec 1992 23:26:18 GMT The Ninth U.S. Circuit Court of Appeals ruled, in US vs X-Citement Video Inc., (CA No. 89-50556), that the sections of the Protection of Children Against Sexual Exploitation Act of 1977 that deal with distribution, transportation, and receipt of sexually explicit materials are invalid on First Amendment grounds. The court let stand the prohibition on the production of child pornography. This ruling needs to be looked at more closely, but it may help to remove sysop worries about someone posting such material on their system without their knowledge, or about network nodes being liable for material passing through them. This is a step forward, because it was one of the very few real legal risks a US sysop had to face, and now it appears to be dead. Do the lawyers out there agree with this analysis? Producing child pornography remains illegal, which is reasonable. John Nagle Source: Wall Street Journal, 17DEC92, p. B10 (Western edition) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: peter honeyman Date: Sun, 20 Dec 92 07:56:42 PST To: yanek@novavax.nova.edu (Yanek Martinson) Subject: Re: Destroying Data (Re: Remailer Policies) In-Reply-To: <9212201344.AA26203@novavax.nova.edu> Message-ID: <9212201556.AA22792@toad.com> MIME-Version: 1.0 Content-Type: text/plain > Make sure you don't think 'rm -rf /remailer-logs' actually destroys data. > It merely de-allocates the i-nodes. You need to know which physical > device the filesystem is on, (let's call id /hdxxx) and then do > 'cat /dev/null > /dev/hdxxx' which overwrites with zeroes all data > on that partition. not quite. you need something like dd if=/dev/null of=/dev/xxx bs=verybig conv=sync this will zero out every block on the disk. but this is overkill -- why not just apply this technique to the individual logs, zeroing out their data blocks? peter ps: is it certain that zeroing out the data blocks thoroughly destroys the data? i've heard that a "shadow" of some sort may remain. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Bill Sommerfeld Date: Sun, 20 Dec 92 20:56:59 PST To: cypherpunks@toad.com Subject: DES source for the HP48SX calculator. Message-ID: <9212210240.AA00086@orchard.medford.ma.us> MIME-Version: 1.0 Content-Type: text/plain I have implemented a version of the core of the DES algorithm for the HP 48SX calculator; I mentioned this in passing on this list a couple of weeks ago. Anyhow, in the general cypherpunks spirit of things, I'm willing to share this code... Note that this only ECB-mode encryption and key schedule computation, and not decryption. Both operations take about 12 seconds.. mostly because they're written in user RPL rather than system RPL or machine code. If the person at Berkeley who maintains the cypherpunks FTP archive wants to get in touch with me, I'd be happy to contribute this file to the archive; also, I'll mail it to anyone with a US or Canadian email return address. - Bill From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: hkhenson@cup.portal.com Date: Mon, 21 Dec 92 10:21:48 PST To: cypherpunks@toad.com Subject: Re: Remailer Policies Message-ID: <9212210959.1.29952@cup.portal.com> MIME-Version: 1.0 Content-Type: text/plain Re logs and trying to destroy them when the cops are beating down your door, wouldn't it be a lot better to keep them encrypted? Keith From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Bruce F. Webster Date: Mon, 21 Dec 92 11:30:02 PST To: cypherpunks@toad.com Subject: PKP/RSA comments on PGP legality Message-ID: <9212211904.AA15552@pages.com> MIME-Version: 1.0 Content-Type: text/plain (Cross-posted with permission of Eben Moglen): Newsgroups: sci.crypt,alt.security.pgp From: em21@cunixf.cc.columbia.edu (Eben Moglen) Subject: Re: PKP/RSA comments on PGP legality Message-ID: <1992Dec17.150409.17696@news.columbia.edu> Date: Thu, 17 Dec 1992 15:04:09 GMT I have been following with interest, and distress, the conversation about legal risks in using PGP set off by Carl Ellison's posting of a document said to reflect the legal position of PKP. Perhaps a Columbia Law professor's views on these questions may be helpful. I'm going to discuss the realities of the situation, without jargon, rather than the legal technicalities. Those who want to discuss the legal detail should feel free to contact me, but for legal advice I usually get paid. PKP says that any user of PGP is "inducing" infringement. Here's the reality of the situation. PKP is the licensee of a presumptively valid US patent, which it claims PGP 2.1 infringes. If the patent is valid, and PGP infringes, every user is not just inducing infringement--he/she/it is infringing the patent. This is not a crime; it's a civil wrong, for which, as the PKP statement says, damages are available at law. But this is true every time a manufacturer sells or distributes an infringing article. As you may recall, for example, an inventor recently won an enormous damages judgment against a major US auto company for infringing his patent for intermittent windshield wipers. Theoretically, under the patent law, he could instead have notified all Ford buyers in the past decade that they were personally infringing his patent. But it is grossly impracticable to do that, and a suit against the manufacturer accomplishes exactly the same result, since the total amount of the damages available is the same either way, while the litigation cost is not. PKP can test the validity of its patent and recover its damages, if any, in a suit against the developers and distributors of PGP, if it cares to. Without any knowledge of their thinking, I predict the partners won't want to do that. It would be expensive, the damages to be recovered would be slight or none, and they would risk having the only patent anywhere in the world protecting their technology declared invalid. But in any event, it is virtually unheard-of to sue individual end-use consumers of allegedly infringing technology. If PKP's investors had $100 million or so they wanted to waste in litigation anything could happen, but they don't, and it won't. In any event, in such a situation a lawyer certainly might advise her client to wait for the patent-holder to assert his rights directly. When PKP sends you a personal letter claiming that you are infringing its patent, and asking you to take out a license, you can decide what you want to do about it. In the meanwhile, the patent claim against end users is mostly, probably entirely, just noise. The Munitions Act bluster contained in the post is not even that important. It's just ridiculous. Others have said some of the most important things well, so I'll be brief. First, even if PKP believes its own arguments interpreting the ITARs, PKP doesn't have squat to do with ITAR enforcement. This is a question addressed to the discretion of the Treasury, the Department of Justice, and local United States Attorneys. ITAR enforcement against distributors of PGP would require a decision by all those agencies that the highest-priority Munitions Act enforcement problem at some future moment is the prohibition of IMPORTATION of a CONSUMER SOFTWARE PRODUCT embodying TECHNICAL INFORMATION IN THE PUBLIC DOMAIN. I challenge PKP, or anyone else, to show any past example of such an approach to ITAR enforcement by any Administration. I cannot myself imagine any United States Attorney's office wanting to bring such a case, which is of nightmarish complexity, would be politically unpopular, and does nothing whatever to stem the global arms trade or increase the national security of the US. I very much doubt that PKP really believes that the domestic circulation of PGP violates the ITARs, since PKP itself terms as "unfortunate" the application of the Munitions Act to cryptographic technology. But even if that's really what PKP or its officers think, so what? The chances that the United States Government will ever agree, and put weight behind agreement, are within fuzz of zero. UseNet serves many social purposes. One, apparently, is the no-cost distribution of negative advertising and legal chest-pounding, intended to frighten people away from experimentation with a piece of interesting freeware. Myself, I would just put the PKP temper tantrum in the bitbucket. But since other people have taken it seriously (much more seriously than it deserves) I thought a few more sober comments might be warranted. _____________________________________________________________________ Fiat Justitia, "Quoi que vous fassiez, ecrasez l'infame, ruat Coelum. et aimez qui vous aime." Eben Moglen voice: 212-854-8382 Professor of Law & Legal History fax: 212-854-7946 Columbia Law School, 435 West 116th Street, NYC 10027 moglen@lawmail.columbia.edu -- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: wcs@anchor.ho.att.com (Bill Stewart) Date: Mon, 21 Dec 92 08:11:21 PST To: cypherpunks@toad.com Subject: Re: Destroying Data (Re: Remailer Policies) Message-ID: <9212211610.AA21587@anchor.ho.att.com> MIME-Version: 1.0 Content-Type: text Yanek points out that "rm" doesn't destroy data on disks, just inodes, and that you have to overwrite the data to destroy it. However, he suggests that you do this by > 'cat /dev/null > /dev/hdxxx' which overwrites with zeroes all as well as overwriting swap space and powering off RAM. Won't work, and it's the hard way to do it: cat /dev/null produces zero bytes of output (there's a /dev/zero on some systems which produces lots of bytes of zeros.) If you're dealing with amateurs (i.e. local cops or maybe FBI, but not NSA/KGB, who can take the disk apart and use fancy magnetic techniques), you can get away with overwriting the data once with zeros or other stuff; a simple approach is to create a file large enough to fill all the unallocated space on the disk (either using /dev/zero or writing your own); be sure to be root so you get the last 10% of a BSD file system. For professionals, overwrite it once with 0s, once with 1s, and once with some test pattern like Xs or /etc/termcap. This still won't help if there are bad blocks which the disk controller is mapping out transparently to your system, of course, but amateurs can't read them. Swap space is tougher - you'll need to look at how your kernel allocates it to know how to fill it all up, or else zap it all after rebooting your system, if this is practical. The government's rules for handling, um, special data say that you either need an officially approved software program, or an Official Big Magnet, or else you need to physically destroy the magnetic media from the disk. I don't like having Big Magnets near my lab, but sandblasting has a real physicality to it, and floppy disks make this satisfying scrunch in a paper-shredder :-) Needless to say, unless you're Ollie North, you shouldn't be shredding your data when the cops are busting you ... Bill Stewart, somewhere in New Jersey From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: jim@tadpole.com (Jim Thompson) Date: Mon, 21 Dec 92 10:08:34 PST To: cypherpunks@toad.com Subject: Re: Destroying Data Message-ID: <9212211807.AA25690@tadpole.tadpole.com> MIME-Version: 1.0 Content-Type: text/plain > Consider also the technique used in the Norton Utilities > program "Diskwipe" which takes a /g switch which "Follows > certain government rules for wiping". I can't find the manual > but I think it specifies how many repetitions are used and > different values to write in each. SunOS 4.X 'format/analyze/purge', (which was done at the request of SunFed, for some Fed contract) uses 4 repetitions with patterns: 0xaaaaaaaa (10101010) 0x55555555 (01010101) 0xaaaaaaaa (10101010) 0xaaaaaaaa (10101010) Followed by a final pass with: 0x40404040 (10000000) Consider this secure if you want. :-) For Unix variants, one might consider a 'patch' to libc that scribbled on the file passed to the 'unlink()' system call before actually performing the syscall. This will, of course, break Unix semantics because there is no way to tell from userland that no other process is holding the file open, so you'll scribble on the file prematurely. I guess itrunc() is what really need changing. Jim From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Peter Shipley Date: Mon, 21 Dec 92 17:07:02 PST To: Phiber Optik Subject: Re: Destroying Data (Re: Remailer Policies) In-Reply-To: <199212220042.AA27413@eff.org> Message-ID: <9212220106.AA06240@edev0.TFS> MIME-Version: 1.0 Content-Type: text/plain >> >> not quite. you need something like >> >> dd if=/dev/null of=/dev/xxx bs=verybig conv=sync >> > >Unix weenies of old will recall "clri" to clear an inode. If paranoia is in >effect, try something like the following: > >ls -li remailer-log or whatever to get the i-node number, >then >clri /dev/sdxx #_of_i-node this will zero out the inode it also does NOT clear the data blocks just the inode pointers to the data blocks. infact if you do this. (this you *will* need to umnount and fsck your system [or reboot if you did this to you root partition]). in fact if you do this with out deleteing the file first you run a good chance of crashing the system. normaly I would say "do not try this at home" but then I would rather you shot yourself in the foot at home (as opposed to shooting yourself and who ever is on a public system) I will post some C/Perl code that will work as a /bin/rm replacement in a few days. -Pete From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Phiber Optik Date: Mon, 21 Dec 92 16:43:07 PST To: honey@citi.umich.edu (peter honeyman) Subject: Re: Destroying Data (Re: Remailer Policies) In-Reply-To: <9212201556.AA22792@toad.com> Message-ID: <199212220042.AA27413@eff.org> MIME-Version: 1.0 Content-Type: text/plain > > > Make sure you don't think 'rm -rf /remailer-logs' actually destroys data. > > It merely de-allocates the i-nodes. You need to know which physical > > device the filesystem is on, (let's call id /hdxxx) and then do > > 'cat /dev/null > /dev/hdxxx' which overwrites with zeroes all data > > on that partition. > > not quite. you need something like > > dd if=/dev/null of=/dev/xxx bs=verybig conv=sync > Unix weenies of old will recall "clri" to clear an inode. If paranoia is in effect, try something like the following: ls -li remailer-log or whatever to get the i-node number, then clri /dev/sdxx #_of_i-node Of course, care should be taken to then unlink the file immediately, as if the i-node number is reused on that filesystem, the old entry would still point to that i-node, and removing the old file would remove the new one (an inadvertent hard link). Clri is in /usr/etc, and it's use is obviously subjected to your permission of the device file (and the file itself), though that's understood if you were going to use 'dd'. Not everyone running a remailer will have permission (usually root) to write directly to filesystem /dev files, so why not just write a little C program to open the logfile and overwrite it to the end with NULL's? Simple. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: miron@extropia.wimsey.com (Miron Cuperman) Date: Tue, 22 Dec 92 03:11:25 PST To: cypherpunks@toad.com Subject: My remailer and ARA's Message-ID: <199212221104.AA20951@xtropia> MIME-Version: 1.0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- My remailer does not support ARA's. This is because the requirement that incoming messages be completely encrypted with its key (any portion which is not encrypted in this way is dropped). In any case, the current scheme for ARA's is insecure. This is because people can send plaintext messages attached to the ARA. This allows breaking anonymity by monitoring of the traffic from all remailers and waiting until the message appears at one of the outputs. I will implement a more secure scheme. The ARA will include encryption instructions for each remailer. Since each remailer will be doing a transformation on the message, the attack above will not be feasible. - -- Miron Cuperman | NeXTmail/mime ok | Public key avail AMIX: MCuperman | cybercomputingimmortalcryptolaissezfaire | -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBKzb2O5NxvvA36ONDAQG/0QP9GVjH8zjBakbYChxCECGRPb02UJvPC9bj 1lS6GF4KTc5Z9yBejYMSLu5E7lVamgcQFuaBFrSusLyl1oXDcJtCUF4TjxgLCAOi dXnkbu+k5oB9vLqlZK3nTSmxAuddjrOxbg/AS6M+aIY7rtwkyfnTgj+7pq4pYj6P /nIpWAB9NHE= =/i5k -----END PGP SIGNATURE----- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: peter honeyman Date: Tue, 22 Dec 92 05:44:41 PST To: Phiber Optik Subject: Re: Destroying Data (Re: Remailer Policies) In-Reply-To: <199212220042.AA27413@eff.org> Message-ID: <9212221344.AA03085@toad.com> MIME-Version: 1.0 Content-Type: text/plain > Unix weenies of old will recall "clri" to clear an inode. ... clri destroys the file "handle" (the inode, thus the owner, mode, length, pointers to data blocks, etc.) but not the contents of the data blocks. stringing them together is another story, but not impossible if you know what you're looking for. > -- so why not just write a little C program > to open the logfile and overwrite it to the end with NULL's? u.w.o.o. often go to great lengths to avoid writing a few lines of c, which, i suppose, is not so bad. but i agree with hkhenson that the best way to secure the remailer logs is to encrypt them. which raises a sticky point, since i don't see an easy way to do that on a machine that you can't secure physically. i'm familiar with the andrew environment (e.g., afs or the andrew toolkit), which is more or less a kerberos environment, wherein secure service providers run on physically secure machines. this lets sysadmins store cleartext passwords (in essence) on their local disks to support reauthentication daemons (to refresh tokens for long-lived jobs, since kerberos tickets time out). this clearly would not achieve the objectives here. the only option i see is to enter a password at boot time (or when the remailer is started). ick. peter From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Tue, 22 Dec 92 07:04:18 PST To: cypherpunks@toad.com Subject: Another pax-type remailer Message-ID: <9212221503.AA26035@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain Forwarded message: > Date: Tue, 22 Dec 92 15:24:12 +0200 > From: daemon@anon.penet.fi > Message-Id: <9212221324.AA14827@anon.penet.fi> > To: yanek@novavax.nova.edu > Subject: Anonymous help. > > > The anon.penet.fi Anonymous Server > ================================== > > Yes, another anonymous server. Why? Well, several well-known servers have > bitten the dust recently. And most of them have served only a very limited > subset of newsgroups, and mail only to "registered", anonymous users. One > quite successful attempt at solving this problem was the server running at > godiva.nectar.cs.cmu.edu, written and operated by Karl Kleinpaste > . Karl's software has been posted to alt.sources. > > Due to reasons too complicated to mention here I wanted to set up an > anonymous server for the scandinavian user community. I contacted Karl, and > got a pre-release copy of his software. As the version I got relied heavily > on the advanced features of MMDFII, I had to modify it quite a bit. While > hacking around, I removed the restriction of only supporting selected > newsgroups. Within a week of startup, the server had been discovered by > transatlantic users, and more recent stats show european users are definitely > a minority. > > So what does the anon server really do? Well, it provides a front for > sending mail messages and posting news items anonymously. As you send your > very first message to the server, it automatically allocates you an id of > the form anNNN, and sends you a message containing the allocated id. This id > is used in all your subsequent anon posts/mails. Any mail messages sent to > your-id@anon.penet.fi gets redirected to your original, real address. Any > reply is of course anonymized in the same way, so the server provides a > double-blind. You will not know the true identity of any user, unless she > chooses to reveal her identity explicitly. > > In the anonymization process all headers indicating the true originator are > removed, and an attempt is made to remove any automatically-included > signatures, by looking for a line starting with two dashes (--), and zapping > everything from there on. But if your signature starts with anything else, > it's your own responsibility to remove it from your messages. > > There are two basic ways to use the system. The easiest way is by sending a > message to recipient@anon.penet.fi: > > To: alt.sex.bestiality@anon.penet.fi > > To: an9999@anon.penet.fi > > To: help@anon.penet.fi > > Of course, in the case of mailing to a known user, you have to use addresses of > the form user%host.domain@anon.penet.fi, or the pretty obscure source addressing > construct of @anon.penet.fi:user@host.domain. These constructs are not > necessarily handled properly by all mail systems, so I strongly recommend the > "X-Anon-To:" approach in these cases. This works by you sending a message to > "anon@anon.penet.fi", including a X-Anon-To: header line containing the desired > recipient. But this really has to be a field in the message header, before the > first empty line in the message. So: > > To: anon@anon.penet.fi > X-Anon-To: alt.sex.needlework,rec.masturbation > > To: anon@anon.penet.fi > X-Anon-To: jack@host.bar.edu > > Valid recipients in both cases are fully qualified user addresses in RFC-822 > format (user@host.domain), anon user id's (anNNN), newsgroup names > (alt.sex.paperclips) or one of the "special" user names of ping, nick, help, > admin and stat. > > Sending to "ping" causes a short reply to be sent confirming (and > allocating, if needed) your anon id. "nick" takes the contents of the > Subject: header and installs it as your nickname. If you have a nickname, it > appears in the From: header in the anonymized message along with your anon > id. "help" returns this text, and stat gives some statistics about the > system. Mail to "anon" goes directly to me unanonymized, and can be used to > report problems. If you want to send mail to me anonymously, you can use > "an0". > > When crossposting to several newsgroups, you can list several newsgroups > separated by commas (no whitespace) as recipients, but this only works using > the X-Anon-To: header. References: headers do work, so they can (and should) > be used to maintain reply threads. > > Ah yes, please remember that the posting takes place at my local site, so you > can only post to groups that are received at penet.fi. I get all "worldwide" > groups, but various exotic local groups don't make it here. I have gotten > a couple of comments about permitting anonymous postings to technical groups. > I can only answer that I believe very firmly that it's not for me to dictate > how other people ought to behave. Somebody might have a valid reason for > posting anonymously to a group I might consider "technical". But remember > anonymous postings are a privilege, and use them accordingly. I believe adult > human beings can behave responsibly. Please don't let me down. > > As the server was originally intended to be used by scandinavians, it > includes support for various languages. The system makes an educated guess > about your local language based on your top level domain. But it can > misfire. Fortunately the server doesn't (yet) support urdu, swahili or > basque... Ah, by the way, if you find it doesn't support your local > language, and you want to volunteer to translate the message files, get in > touch... > > The user-id database is based on RFC822-ized forms of your originating > address. This may cause problems for some users, either because their site > is not properly registered in the name servers, resulting in > non-deterministic addresses, or because their mail router doesn't hide the > identity of individual workstations, resulting in different originating > addresses depending on which workstation you mail from. Talk to your > administrator. If that doesn't help, let me know, and I will make a manual > re-mapping. > > You might wonder about the sense of using a server out somewhere, as the > song goes, "so close to Russia, so far from Japan". Well, the polar bears > don't mind, and the ice on the cables don't bother too much :-) > Well, in fact, as we live in a wonderfully networked world, the major delay > is not going over the atlantic, but my local connection to the Finnish EUnet > backbone, fuug.fi. Once you reach a well, connected host, such as > uunet.uu.net, there's a direct SMTP connection to fuug.fi. My connection to > fuug.fi is currently a polled connection over ISDN, soon to be upgraded to > on-demand-SMTP/NNTP. But for now, expect a turn-around delay of 2-4 hours for > trans-atlantic traffic. > > Oh yes, then there's the question of confidentiality/security. The service > runs on one of the 386 boxes in my back room at home, and the machine is not > directly accessible from the internet. So the only one who can get to the > database is myself. Well, if the police or the local Secret Service comes > knocking at my door, with a court order to hand over the database, I might > comply. But then I might, of course, accidentally delete the file instead of > copying it... And maybe possibly there could be cases where, if somebody could > come up with really hard evidence of activities such as blackmail, I could be > persuaded... > > Anyway, short of having everyone run a public-key cryptosystem such as PGP, > there is no way to protect users from malicious administrators. You have to > trust my personal integrity. Worse, you have to trust the administrators on > every mail routing machine on the way, as the message only becomes anonymous > once it reaches my machine. Malicious sysadmins and/or crackers could spy on > SMTP mail channels, sendmail queues and mail logs. But as there are more > than 350 messages being anonymized every day, you have to be pretty perverted > to scan everything... > > Another thing is mail failures. I've had cases of mail routers doing the wrong > thing with % addresses, "shortcutting" the path to the destination site. > This could cause your mail to go to the final destination without ever > touching my server (and thus without getting anonymized). This can be avoided > by using the X-Anon-To: method. > > And if your return address bounces for some reason (nameservers down, > temporary configuration failures etc.), the original sender and/or > postmasters on the way might get error messages showing your true > identity, and maybe even the full message. > > And crackers are just too clever. Undoubtedly somebody is going to come > up with some novel method.... Not much I can do about that... > > If you intend to mail/post something that might cost you your job or > marriage or inheritance, _please_ send a test message first. The software > has been pretty well tested, but some mailers on the way (and out of my > control) screw things up. And if you happen to find a problem, _please_ for > the sake of all the other users, _let me know asap_. > > And _please_ use the appropriate test newsgroups, such as alt.test or > misc.test. Yes, _you_ might get excited by reading 2000 "This is a test.." > messages on alt.sex, but I warn you that most psychologists consider this > rather aberrant... > > And remember this is a service that some people (in groups such as > alt.sexual.abuse.recovery) _need_. Please don't do anything stupid that > would force me to close down the service. As I am running my own company, > there is very little political pressure anyone can put on me, but if > somebody starts using the system for criminal activities, the authorities > might be able to order me to shut down the service. I don't particularly > want to find out, however... > > If you think these instructions are unclear and confusing, you are right. If > you come up with suggestions for improving this text, please mail me! Remember > English is my third language... > > Safe postings! > > Julf > > - - - ------------------------------------------------------------------- - - - > Johan Helsingius Kuusikallionkuja 3 B 25 02210 Espoo Finland Yourp > net: julf@penet.fi bellophone: int. +358 0400 2605 fax: int. +358 013900166 > -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Tue, 22 Dec 92 07:11:12 PST To: honey@citi.umich.edu (peter honeyman) Subject: Encrypting Remailer Logs In-Reply-To: <9212221344.AA03085@toad.com> Message-ID: <9212221510.AA26463@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > that the best way to secure the remailer logs is to encrypt them. > > which raises a sticky point, since i don't see an easy way to do that [...] > see is to enter a password at boot time (or when the remailer is started). There is an easier way. Just generate a public/private key pair. Store the public key on the machine, and have the remailer encrypt its logs with the public key. Someone seizing the machine could not find anything, since they do not have the private key. Store the private key on another machine, or on a floppy. When there's a problem, you can transfer the encrypted log to the machine with the private key, and then you can decrypt the log to see what went wrong. Generate a new key pair weekly, and destroy the old private key. You should never need logs older than a week for troubleshooting. p.s. > > Unix weenies of old will recall "clri" to clear an inode. ... > > > -- so why not just write a little C program ... > > u.w.o.o. often go to great lengths to avoid writing a few lines of c, So how about a few lines of perl? -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: peter honeyman Date: Tue, 22 Dec 92 08:21:43 PST To: cypherpunks@toad.com Subject: Cryptology Column -- New and Coming Books Message-ID: <9212221621.AA05549@toad.com> MIME-Version: 1.0 Content-Type: text/plain Excerpted and reprinted with the author's permission from SIGACT NEWS, Volume 23, Number 4 Cryptology Column -- New and Coming Books Gilles Brassard brassard@iro.umontreal.CA Departement d'informatique et de R.O. Universite de Montreal C.P. 6128, Succ. ``A'' Canada H3C 3J7 31 October 1992 Research supported in part by the E.W.R. Steacie Memorial Fellowship (Canada's Nserc). 1 Introduction An outstanding book on cryptology has hit the market this year. Although the news may be stale to many of my readers, Gustavus J. Simmons has edited a 640-page mammoth of a masterpiece titled Contemporary Cryptology: The Science of Information Integrity, published by IEEE Press. In addition, other new and exciting books are expected to come out soon. 2 Simmons' Book Simmons' Contemporary Cryptology grew out of a special issue of the Proceedings of the IEEE, which he edited in May 1988. I remember how proud -- and rightly so! -- Simmons was concerning that issue: his favourite line was that ``this is an example where the whole is better than the sum of its parts''. As a consequence of the excellent reception of his special issue, he was commissioned by the IEEE to edit the book we are now discussing. Speaking of excellent reception, the first printing of Simmons' book was sold out in months. The second printing, which I have not seen yet, corrected all mistakes that had been found in the first. In addition, reference citations for publications that had appeared after the first printing went to press were completed, and a number of footnotes, notes added in proof and inserted paragraphs to update significant statements of fact that had occurred in the interim were made. It is amusing to note that the book's cover is very similar to that of the Proceedings, except that Simmons corrected an embarrassing mistake that I pointed out to him on the Proceedings cover (see if you can spot it!). The book is hard cover, pleasant to manipulate, and handsome. Unfortunately, I found the binding of my own copy to be slightly defective, but I was told that this problem was corrected with the second printing. Contemporary Cryptology is a collection of chapters, many of which written by top researchers in the field, which together span most of the exciting developments that have changed cryptology forever in the past twenty years. Simmons himself contributed the foreword and three chapters. His master plan -- the table of contents -- is well conceived as few important topics have been left out. (Nothing is perfect, though ... the book is lacking a chapter on quantum cryptography!) Unfortunately, even a good coach cannot enforce perfect coordination concerning who says what in a multi-author work. This book is no exception: it suffers from many repetitions of the same concepts across chapters. The main sections of the book are Cryptography, Authentication, Protocols, Cryptanalysis, and Applications. This is preceded by two essays on the theme ``Contemporary Cryptology'': a foreword by Simmons and an introduction by James L. Massey. Massey's introduction to cryptology is among the clearest and most useful I have ever seen that can fit on as few as 36 pages (although another particularly noteworthy concise introduction is Simmons' own entry in the Encyclopaedia Britannica). Massey's introduction covers some history, motivations, all the basic notation, secret key cryptography (both in theory and in practice, including a review of Shannon's information theory, the DES, stream ciphers and Ueli Maurer's recent bid to get around Shannon's discouraging theorem that the one-time-pad is the most economical system that can provide perfect secrecy), authentication (a section that I found particularly useful last time I taught on the subject), public key cryptography (including one-way functions, public key distribution, RSA and variations on the theme), and protocols. Massey even includes an enlightening discussion of secret versus open research in cryptology. One thing I learned from Massey's introduction is that the notion of one-wayness goes back to at least 1873! On the negative side, nothing is said about probabilistic encryption and zero-knowledge protocols, and digital signatures are not covered adequately. But then, Massey makes an explicit point that it was not his purpose to survey research in cryptology. Moreover, these topics are treated in other chapters of Simmons' book. After the foreword and introduction, the first section deals with cryptography. The topics covered are ``The DES: Past and Future'' by Miles E. Smid and Dennis K. Branstad, ``Stream Ciphers'' by Rainer A. Rueppel, ``The First Ten Years of Public Key Cryptography'' by Whitfield Diffie, ``Public Key Cryptography'' by James Nechvatal, and ``A Comparison of Practical Public Key Cryptosystems Based on Integer Factorization and Discrete Logarithms'' by Paul C. van Oorschot. The chapter on DES goes from the birth of the system to predictions concerning the coming decade, not forgetting to cover the controversy surrounding it and its many applications. New, post-DES algorithms are also discussed. However, the coverage of attacks against DES is far from complete; in particular, differential cryptanalysis is not even mentioned. Rueppel is a leading expert in stream ciphers, and the author of a well-known book on the topic; he was therefore the natural choice of author for Simmon's second chapter. After introducing all the relevant background, Rueppel covers information-theoretic, system-theoretic and complexity-theoretic approaches to stream ciphers. A large number of pseudo-random generators are described. The chapter also considers randomized stream ciphers, which can provide practical provable security in the presence of a large, publicly accessible, body of randomness. Diffie's chapter on the history of public key cryptography is a pure gem, which could only have been told so well by the horse's mouth. In my opinion, Simmons' book would be worth buying even if only for those 39 pages. Of particular interest is the story of how Ralph Merkle, then at Berkeley, invented as early as 1974 the concept of public key distribution, and how unsuccessful he was in explaining and publishing his idea. (Merkle told me that Bob Fabry, contrary to many others, had understood the idea and had encouraged him to seek fame and fortune with it!) Diffie goes on explaining the principles of public key cryptography and the early solutions, including RSA. An interesting section on key management, the main aspect that was sorely missing from the early papers on public-key cryptography, is provided. Diffie's chapter continues with applications, such as the secure phone system, and implementations. Finally, Diffie goes beyond what his title promised, as he tackles new directions for public key cryptography. The next chapter, by Nechvatal, is by far the longest in this book (120 pages). It was written as a stand alone piece, which is unfortunate in this context as it presents significant overlap with other chapters of the book. In my opinion, the author would have been better advised to transform his writing into a monograph of its own. Nevertheless, this chapter is well written and contains a wealth of valuable information. In the last chapter of the first section, van Oorschot reviews the currently best algorithms for extracting discrete logarithms (both in GF(2^n) and in elliptic curves) and for factoring, including a detailed analysis of their efficiency. This is used as the basis of a comparison between El Gamal's cryptosystem and RSA. Elliptic curve cryptosystems are also considered. Section 2 deals with authentication. It is composed of one chapter on ``Digital Signatures'' by Chris J. Mitchell, Fred Piper and Peter Wild, and ``A Survey of Information Authentication'' by Simmons. The chapter on digital signatures provides thorough coverage of the theory, practice and applications of signatures, including a section on hashing. Nonetheless, it is sad that David Chaum's elegant notion of Undeniable Signature did not find its way in that chapter even though it was published as early as 1989. The next chapter was written by the man I consider to be no less than ``the Shannon of authentication'', the book's editor himself. Indeed, Simmons developed in the 1980's a theory of authentication that parallels that of Shannon for privacy. This chapter shows a good balance between theory and practice, which could also be said about its author. I must admit, however, that I found Massey's exposition of Simmons' theories in the Introduction easier to follow than Simmons' own. Nevertheless, I read this chapter with particular interest and enjoyment. The next section deals with protocols. It consists of an ``Overview of Interactive Proof Systems and Zero-Knowledge'' by Joan Feigenbaum and ``An introduction to Shared Secret and/or Shared Control Schemes and Their Applications'' again by Simmons. It must be pointed out that the very important (in my opinion) topic of multi-party computation, also known as ``post-cold war cryptography'', is missing altogether from this section on protocols and indeed from the entire book as far as I can tell. I like Feigenbaum's succinct exposition of interactive proofs and zero-knowledge, even though it was written more from a computational complexity point of view than from a cryptographic point of view. For instance, the existence of an interactive proof system for the permanent is of considerable interest in complexity theory, as it lead the way to Shamir's proof that IP = PSPACE (see my column in Vol. 21, no. 1, 1990) but I fail to see its direct cryptographic significance. Turning now to the chapter on secret sharing, I can think of no one better suited than Simmons for writing it. After reviewing Shamir's and Blakley's (very different) original ideas, he addresses access structures more general than simple threshold schemes. Most of the schemes explained are based upon geometric considerations. An application to key distribution is provided. A comprehensive bibliography follows. The fourth section deals with cryptography's sister discipline: cryptanalysis. It consists of one chapter on ``Cryptanalysis: A Survey of Recent Results'' by Ernest F. Brickell and Andrew M. Odlyzko, and one chapter on ``Protocol Failures in Cryptosystems'' by Judy H. Moore. The chapter on cryptanalysis surveys recent cryptanalytic achievements. Particularly thorough treatment is given to the breaking of the knapsack and of linear congruential generators. Other cryptosystems and signature schemes are covered. Information is also provided on the state-of-the-art concerning the cryptanalysis of yet unbroken systems such as RSA, discrete exponentiation schemes, the McEliece cryptosystem, and the DES. Recent developments such as the number field sieve for factoring and the differential cryptanalysis technique are mentioned, but Biham and Shamir's attack on the full 16-round DES was achieved only after Simmons' book went to press. Moore's chapter on protocol failures addresses an interesting problem: it tells you how to cheat an application centered around a cryptosystem without in fact breaking the cryptosystem itself. In other words, even good cryptosystems are potentially vulnerable when improperly used, or when used according to a badly designed protocol. Guidelines are given to avoid such traps. (Perhaps the most spectacular protocol failure in history concerned the Enigma during World War II, but this is of course not treated in Moore's chapter!) The book closes with a section on applications. It contains one chapter on ``The Smart Card: A Standardized Security Device Dedicated to Public Cryptology'' by Louis C. Guillou, Michel Ugon and Jean-Jacques Quisquater, and a chapter on ``How to Insure That Data Acquired to Verify Treaty Compliance Are Trustworthy'', once more by Simmons. The chapter on smart cards describes what a smart card is and what it can do. The important issue of standardization is treated at length. Significant information is given on the technology behind smart cards. Naturally, most of the chapter is concerned with security issues and cryptographic applications, such as authentication. The book's final chapter deals with real life field work pioneered by the editor at Sandia National Laboratories, which is the result of nearly two decades of development. I prefer to say no more so as to keep your appetite whetted! In conclusion, this is a remarkable book, which I very strongly recommend as necessary addition to the library of any serious researcher in the field of cryptology. 3 Other books These are exciting times for cryptoreaders. In addition to Simmon's, other promising books are due to appear soon. Even though I prefer to wait until they have come out to review them in detail (despite the fact that I have seen preliminary versions), I cannot resist the temptation to give you an avant gout. Eli Biham and Adi Shamir have written up in great detail their differential cryptanalysis technique and how it applies to the full 16-round DES as well as to other cryptosystems and hashing functions. This is along the lines of Volume 4, number 1 of the Journal of Cryptology, only more of it and better. The preliminary title of their book is Differential Cryptanalysis of the Data Encryption Standard. It will be published by Springer-Verlag. Starting from notes taken by the students of a class he taught at the University of California, Berkeley, Mike Luby has written Pseudorandomness and Applications, which will be published by Princeton University Press. The book, now complete in the opinion of its author, is undergoing a review process. In it, Luby places pseudorandomness at the heart of cryptography. He explains how to produce cryptographically secure pseudorandomness and how to use it for various cryptographic purposes. As one of the researchers to whom we owe the proof that one-way functions are necessary and sufficient to obtain cryptographically strong pseudorandom generators, Luby was the logical author to write this authoritative book. In addition, allow me to indulge in mentioning that my own Springer-Verlag monograph Modern Cryptology: A Tutorial is expected to come out in French this November. It will be published by Masson under the title of Cryptologie Contemporaine. Contrary to the previous translation into Italian (also published by Masson), the French version (translated by Claude Goutier) was fully revised and updated by the author. For instance, the number of references went up from 250 to 366 (you better tackle them on a leap year if you cannot handle more than one per day!). Have you written something lately? If you have, I would appreciate hearing about it. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Hal <74076.1041@CompuServe.COM> Date: Tue, 22 Dec 92 09:03:06 PST To: CYPHERPUNKS Subject: Remailers. Message-ID: <921222165319_74076.1041_DHJ39-1@CompuServe.COM> MIME-Version: 1.0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- One problem with the current encrypted remailers that people should be aware of is that, since they operate unattended, they have to be able to decrypt messages automatically. This means that when an incoming messages arrives, the remailing software automatically runs PGP on the incoming message to do the decryption. But to decrypt, PGP has to be given the pass phrase for the remailer's secret key. The only way this can be done is to have the pass phrase, IN THE CLEAR, in the remailing software scripts. The scripts are (or should be) protected using the Unix file system so that only the owner and root can read them. But it's important to know that root has access both to the secret key ring which holds the remailer's key, and to the pass phrase which will activate that key. This means that, at any time, root can find out the secret key of the remailer, and read all messages encrypted for that remailer. I don't think there is any way around this problem if the remailer is going to run unattended. The only real solution is to operate on a machine where it doesn't matter whether root knows the key; that is, a machine where root is the operator of the mailing list. Hal 74076.1041@compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBKzcZ0agTA69YIUw3AQEFhAQAlloC1eyaIuJDG91VzPoRv0MjzKlob8Te C3N7XWLvszypOgKNBoEb1z8fF5ZsS20NhhRhtr7A3J4jxe88vGuea0Kvxzj4NGd4 bQeewhYk01ygoLzZOwv8BnN6pE7/uxk5POWq3XQuX80VQzistePfRRdNozTA09EY 4bBOr3s9Ig8= =nJ/a -----END PGP SIGNATURE----- My public key, signed by PRZ: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAiqsNkwAAAEEAMKWM52m5EWi0ocK4u1cC2PPyHT6tavk9PC3TB5XBYDegf3d sldRpnjJj1r+aO08FFO+QLEI9wtBqvf1PPP5iLX7sD2uIVlJH14MPtyVtjm9ZKb8 JMtCW74045BgtHBC9yQ3V7vXNV5jM6dE2ocnH4AI/pBFrGLJPKgTA69YIUw3AAUR tCZIYWwgRmlubmV5IDw3NDA3Ni4xMDQxQGNvbXB1c2VydmUuY29tPokAlQIFECqu M1Tidd4O/2f3CwEByrUD/3uoV2y+Fuicrrd2oDawgOw9Ejcx6E+Ty9PVPqKvflLs 0zYyGfeFVSgBbTSDP3X91N3F68nydl9J9VA6QRCGelHM1cZRukCJ0AYbKYfpwUN0 xjEGHsDrd2gT5iWlB3vBZvi+6Ybs4rSq+gyZzVm1/+oRrMen32fz2r0CLgUtHok2 =fF6Z -----END PGP PUBLIC KEY BLOCK----- Distribution: CYPHERPUNKS >INTERNET:CYPHERPUNKS@TOAD.COM From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Hal <74076.1041@CompuServe.COM> Date: Tue, 22 Dec 92 09:02:47 PST To: CYPHERPUNKS Subject: Remailer encryption. Message-ID: <921222165347_74076.1041_DHJ39-2@CompuServe.COM> MIME-Version: 1.0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- From: miron@extropia.wimsey.com (Miron Cuperman) > In any case, the current scheme for ARA's is insecure. This is > because people can send plaintext messages attached to the ARA. > This allows breaking anonymity by monitoring of the traffic from > all remailers and waiting until the message appears at one of > the outputs. > > I will implement a more secure scheme. The ARA will include > encryption instructions for each remailer. Since each remailer > will be doing a transformation on the message, the attack above > will not be feasible. I'd like to hear more about this plan. What kind of encryption instructions would be used in the ARA? Would they be public key or secret key? Chaum's "Mix" paper in CACM (1981? I don't have my refs handy) had a concept where at each step the remailer would encrypt the outgoing non-address part of the message with a DES key found in the anonymous address. The user would remember all the DES keys used in the ARA and un-apply them in reverse order to reconstruct the original message. This would require some special software, I'd think, to remember the DES keys and unapply them (and to construct the anonymous address). (Actually, Chaum didn't specify DES but rather just an unspecified secret key system. If PGP were used for some of this then perhaps IDEA would be a good choice.) This system sounded pretty complicated, and it still had the problem that by sending multiple messages to the same address a remailer could do some simple traffic analysis and break the ARA. E.g. it would send 5 messages to an ARA today, and discovers that it later gets 5 messages for user X (because it happens to be the last remailer in the ARA chain). Tomorrow, it sends 10 messages to that same ARA, and discovers 10 messages for that same user. The next day it sends 7 messages to the ARA, and discovers 7 messages for that user. Eventually it can deduce that the user and the ARA go together. To avoid this, Chaum calls these "one-time" ARA's and recommends that mixes not accept messages for the same ARA more than once. I don't think this is a practical suggestion, though, since a one-time ARA is not useful enough. Hal Finney 74076.1041@compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBKzcdKKgTA69YIUw3AQFK9wP/a27AgcL4ppMpYIbDfBy6Vw8NTjJzKpsL hQibQ3XO3wPFURS3Mn51eYLyYRuJPY1/Ve+Y1Kbb6oLiW1u8Btw8CxvB1xe05f32 j0JwzSN1yL8blGMh4JxxXZI0t3SViJ1COt6p+I1SYLjftte/0YX0gc6dweFNUnkZ 5VC4FH2WCbQ= =+Jx9 -----END PGP SIGNATURE----- Distribution: CYPHERPUNKS >INTERNET:CYPHERPUNKS@TOAD.COM From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Tue, 22 Dec 92 10:59:24 PST To: cypherpunks@toad.com Subject: IEEE Ordering Info Message-ID: <9212221858.AA07594@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain If you want to order the book Peter posted about, call 800 678 4333, press 1, then ask for Contemporary Cryptology book by Simmons. It's $79.95 (+$6 s/h). Probably less if you are a member of IEEE. I am in no way associated with IEEE Press, I just ordered the book, and wanted to make it simple for anyone else who wants to. (I ftp'd an info file from ieee.org, got a non-800 phone number, called, was transfered and put on hold for x number of times, until someone was able to give me the above 800 number that can be used to order their publications. I didn't want everyone to have to do this). -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: edgar@spectrx.Saigon.COM (Edgar W. Swank) Date: Tue, 22 Dec 92 19:40:22 PST To: Cypherpunks Subject: Remailers Message-ID: MIME-Version: 1.0 Content-Type: text/plain I'd like to thank Eric Hughes and Mike Sherwood (who wrote privately) and Hal Finney (who responded here) to my requests for enhancements to Eric's remailer code. By the way, Hal, your signature did not match the associated plaintext: WARNING: Bad signature, doesn't match file contents! Bad signature from user "Hal Finney <74076.1041@compuserve.com>". Signature made 1992/12/19 21:43 GMT This is likely due to some trailing blanks in your plaintext. I've written to Branko to try to get PGP to remove trailing blanks if -t is active. First, I'm glad Eric agrees that anonymous posting to newsgroups is a good idea and is on his "to do" list. Until then, thanks to Hal for posting the info about the ucbvax gateway. I had that info at one time, before hearing about remailers, but discarded it since I thought I'd never use it. I'm sorry Eric doesn't agree that stripping the .sig is a good idea. I respectfully dissent. I've found that I can probably disable my own automatic .sig, so I suppose this isn't too urgent. Nevertheless, I would think it desirable to make remailers as easy to use as posible. Having to remember to disable the automatic .sig is certainly an inconvenience. Forgetting to do so could potentially be very embarrassing or even incriminating!! The pax remailer uses "--" or "__" as sig delimiters (according to their docs) & apparently this is satisfactory. I think this means that "----" would NOT be a delimiter, so it would be unlikely to be used by mistake. I wouldn't mind a more explicit delimiter, for example ::--Remailer cut HERE-- if Eric thinks "--" is too ambiguous or is likely to be used inadvertantly in the middle of a msg. Anyway I guess I can muddle through for the time being. I agree with Hal that the pax remailer can probably be the first in a chain to Eric remailers. Probably also the last in a chain of Anonymous returns. But I don't see how pax could be used in the middle of a chain. I would encourage Eric to correspond with the guy running the pax remailer: anon.admin@pax.tpa.com.au (a human) to see if you couldn't come up with a common remailer code with best features of both. Certainly it would be great to have an Eric-style remailer running in Australia!! -- edgar@spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: gnu@cygnus.com Date: Tue, 22 Dec 92 18:00:24 PST To: cypherpunks@toad.com Subject: Amtrak San Jose - San Diego for Usenix Message-ID: <9212230159.AA19415@cygnus.com> MIME-Version: 1.0 Content-Type: text/plain Costs $107 round trip, and takes about 14 hours each way. FYI. John From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: D Anton Sherwood Date: Tue, 22 Dec 92 20:00:22 PST To: cypherpunks@toad.com Subject: Re: Remailer Policies Message-ID: <199212230354.AA20595@well.sf.ca.us> MIME-Version: 1.0 Content-Type: text/plain Keith Henson asked: > Re logs and trying to destroy them when the cops are beating down your > door, wouldn't it be a lot better to keep them encrypted? Keith Here's a lame question from a beginner who hasn't even downloaded PGP: Am I supposed to memorize my private key, lest cops beat down the door while I'm out? Anton Sherwood dasher@well.sf.ca.us +1 415 267 0685 1800 Market St #207, San Francisco 94102 USA From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: karn@qualcomm.com (Phil Karn) Date: Tue, 22 Dec 92 20:07:09 PST To: cypherpunks@toad.com Subject: Signing ascii text Message-ID: <9212230406.AA28094@servo> MIME-Version: 1.0 Content-Type: text/plain I see some potential problems here as people start signing ASCII text (e.g., email messages, etc). Is there a convention for the end of line sequence that is to be used for the copy of the file that is run through the hash function? If there isn't, then the file hash will depend on the local end-of-line convention, which is bad. I'm facing this problem right now in an experimental "XMD5" command that I've added to my FTP server. The idea is to let you compute a hash on a remote file so you can compare it with a local file without actually having to send it. It works great in binary mode, but ascii mode is problematic. Phil From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: karn@qualcomm.com (Phil Karn) Date: Tue, 22 Dec 92 21:10:41 PST To: yanek@novavax.nova.edu Subject: Re: Signing ascii text Message-ID: <9212230509.AA28220@servo> MIME-Version: 1.0 Content-Type: text/plain Okay, the cr/lf convention is what I suspected was the case. That's what I'll implement. Can't do much about the munged messages... Phil From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Tue, 22 Dec 92 20:32:03 PST To: karn@qualcomm.com (Phil Karn) Subject: Re: Signing ascii text In-Reply-To: <9212230406.AA28094@servo> Message-ID: <9212230431.AA25182@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > (e.g., email messages, etc). Is there a convention for the end of line > sequence that is to be used for the copy of the file that is run through > the hash function? If there isn't, then the file hash will depend on the Canonical Text has a CR and LF at the end of each line. This is documented in some RFC. All (most?) protocols used on internet such as smtp, finger, etc, use this format. The possible justification is that an extra linefeed or a carriage return is not as bad as a missing one. For e-mail you may have other problems, if the messages go through gateways that like to munge messages. For example your tabs could be expanded into spaces, or the other way around. Some character set conversions may be done. Blank lines may be removed or added. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Hal <74076.1041@CompuServe.COM> Date: Tue, 22 Dec 92 21:53:28 PST To: CYPHERPUNKS Subject: Signing text messages... Message-ID: <921223054929_74076.1041_DHJ39-1@CompuServe.COM> MIME-Version: 1.0 Content-Type: text/plain My public key, for those wanting to check the sig on the message below: -----BEGIN PGP PUBLIC KEY BLOCK----- mQCNAiqsNkwAAAEEAMKWM52m5EWi0ocK4u1cC2PPyHT6tavk9PC3TB5XBYDegf3d sldRpnjJj1r+aO08FFO+QLEI9wtBqvf1PPP5iLX7sD2uIVlJH14MPtyVtjm9ZKb8 JMtCW74045BgtHBC9yQ3V7vXNV5jM6dE2ocnH4AI/pBFrGLJPKgTA69YIUw3AAUR tCZIYWwgRmlubmV5IDw3NDA3Ni4xMDQxQGNvbXB1c2VydmUuY29tPokAlQIFECqu M1Tidd4O/2f3CwEByrUD/3uoV2y+Fuicrrd2oDawgOw9Ejcx6E+Ty9PVPqKvflLs 0zYyGfeFVSgBbTSDP3X91N3F68nydl9J9VA6QRCGelHM1cZRukCJ0AYbKYfpwUN0 xjEGHsDrd2gT5iWlB3vBZvi+6Ybs4rSq+gyZzVm1/+oRrMen32fz2r0CLgUtHok2 =fF6Z -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNED MESSAGE----- Phil Karn asks about end-of-line conventions for signed text messages. PGP uses the convention of lines terminated by carriage-return-line-feed. On Unix systems or other systems which don't use that convention, it attempts to change the message into this "canonical" text mode before calculating or checking the signature. The issue of trailing blanks is more problematical. Some mail gateways and some mail "user agent" software apparently take liberties with blanks at the end of lines. The PGP canonical text format does not include any specification for whether lines could or could not have blanks at the end. If mailers will leave trailing blanks alone, then PGP cleartext signed messages will have correct signatures. If some intervening mailer has added or removed trailing blanks, then the signatures will be wrong. Presumably something like this has happened to my signed message on which Edgar found a bad signature. Perhaps Edgar could try stripping any trailing blanks from his copy of my message and see if it then signature-checks OK. I'll double-check that this message is signed with no trailing blanks. Then if you get a bad signature, I predict that you must have trailing blanks in your copy of the file. I'd appreciate hearing whether this prediction is correct. It would be possible to change PGP's canonical text format to specify that lines have no blanks at the end. In that case, PGP would, whenever it computed or checked a signature on a text file, process the file to make sure that each line ended with a CRLF preceded by no trailing blanks. I think this would solve a lot of the gateway problems. But it would be a somewhat more "aggressive" change to what the user is asking PGP to sign. The design of PGP's cleartext signature was influenced by PEM, which also uses a canonical text format for line terminators, but doesn't deal with trailing spaces, as far as I know. The real solution, IMO, is to fix those broken mailers that add or remove spaces. I don't see why this behavior has ever been put into mail gateways. Hal Finney 74076.1041@compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBKzfNHqgTA69YIUw3AQGNdwP/Q51Lvmee1cTb865aInePsRxMTe4qfjeU DSP8o5hHlBKbII8mCrU/WHZ7upjO3ak4E6wZDyOexsfJFH4FIMnDueihrVVXevlA FWUQopZIyG4P5Wzofgra8BSjw5WzVZncW2alPQFuB40D9N9VgyopX8IktktVPs4p qDkHsn9zIpU= =K/Ui -----END PGP SIGNATURE----- Distribution: CYPHERPUNKS >INTERNET:CYPHERPUNKS@TOAD.COM From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Hal <74076.1041@CompuServe.COM> Date: Tue, 22 Dec 92 21:55:46 PST To: CYPHERPUNKS Subject: Pax and .fi remailers Message-ID: <921223054957_74076.1041_DHJ39-2@CompuServe.COM> MIME-Version: 1.0 Content-Type: text/plain Upon more thought, I don't see a really good way to use the PAX remailer in conjunction with our remailers based on the scripts of Eric Hughes. The PAX remailer can only be used to send messages to those who have "registered" with the remailer to receive an anonymous ID there. So, for PAX to work with our remailers we would have to register. For example, my remailer at hal@alumni.caltech.edu would have to register with PAX and receive an anonymous ID, like "anon.100@pax.tpa.com.au". Then, to use a two-hop remailer consisting of first PAX and then mine, you would prepare a message as usual for my remailer: ==================== :: Request-Remailing-To: dest This is a message for two-hop anonymous remailing. ==================== Perhaps you would encrypt this using my remailer's public key, getting: ==================== :: Encrypted: PGP -----BEGIN PGP MESSAGE----- Version: 2.1 hEwCG6rHcT8LtDcBAfwLWYgWXpCoi7TjoeVttBYpk3KPbiYf9L9CCegfYlvj56RA OFrijYag+jqNlHQXmO52bXL8PaNUowD7a2pFY80WpgAAAGt/RXNzaWkI/b3CkviB eh/piaUDxgfPd4npcURHtUCEeh8bPpzVaI9qm6xZlxSaJif+CtFqyuaRezj+hcXR YT9JOl93LAxQJITeYUlPXgkBEvyB4u3HjpCDSS5NETDcqd8rtBspzUvlcmqT1g== =d356 -----END PGP MESSAGE----- ==================== You would then send this to anon.100@pax.tpa.com.au. (NOTE: Don't try this - I haven't yet gotten an anonymous ID at PAX.) PAX would forward it to my remailer, unchanged, which would then decrypt it and send it onward. Oh, yes, PAX would also strip the .sig, which is perhaps why you'd want to do this. But for this to work, I have to publically announce that my remailer, hal@alumni.caltech.edu, can be reached at PAX "anonymous" address anon.100@pax.tpa.com.au. This seems a little strange, as the PAX address is then no longer anonymous. I have to tell everybody what the address is in order for it to be useful. So, the PAX remailer doesn't really add much anonymity, but it does excise your .sig. It's not clear that it's worth it just for that. On a more positive note, the other remailer, in Finland, is much more promising for our purposes. It has a remailing capability similar to ours. You could send mail to: hal%alumni.caltech.edu@anon.penet.fi, and it would forward the mail to hal@alumni.caltech.edu. This is similar functionality to a non-encrypting form of the remailers we are operating, and so it can help confuse things. Also, this remailer could be used in a chain of our remailers by using an address of the proper form. For example, mail sent to the Rebma remailer, then to Finland, then to the Rosebud remailer, could be done by putting, at the front of your message: :: Request-Remailing-To: elee7h5%rosebud.ee.uh.edu@anon.penet.fi :: Request-Remailing-To: Then a blank line, then your message itself. Mail it to remailer@rebma.mn.org. I haven't tried this but it should work, theoretically. Hal 74076.1041@compuserve.com Distribution: CYPHERPUNKS >INTERNET:CYPHERPUNKS@TOAD.COM From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Tue, 22 Dec 92 22:35:05 PST To: ddfr@aol.com Subject: Encryption Technology Message-ID: <9212230634.AA27849@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > I am going to be teaching a seminar on computer law next quarter. One area > the casebooks seem to entirely ignore is encryption--the area where > technology is currently supporting privacy and weakening state power. I would > appreciate either references to or on line copies of useful material. The > three main things I need are a clear explanation of the technology (public > key cryptography in particular), I assume that you just want an explanation of what the technology does, not how exactly it works, i.e. I am not going to include the formulas and algorithms, just a description of what it does and how it can be used. Here's a summary of a couple of the most relevant technologies: PUBLIC KEY CRYPTOGRAPHY -- each person generates two keys, one is called teh public key the other is private. These two are related in that what is encrypted with one can only be decrypted with the other. It is impossible (computationally infeasible) to derive one knowing the other. The most popular public key cryptography algorithm is RSA, which is based on the ease of multiplying large primes, and the difficulty of factoring the product. How it is used: you publish the public key, while keeping the private key to yourself. Anyone can send a secret message to you by encrypting it with your public key. You are the only one that can decrypt the message, since only you have the private key. You can reply by encrypting your message with their public key, and they can decrypt it with their private key. DIGITAL SIGNATURES -- techniques that are used to verify that a message claiming to be from you was actually written by you. To do that, you compute a "message digest", which is similar to a "checksum" in that it can be used to check that the message has not been altered. Then you encrypt the "digest" with your private key and attach to the message. Currently the most popular "digest" algorithm is MD5. To verify a signature: the person verifying computes the same checksum, then decrypts the checksum attached to the message. If the two match, the message must have been signed by you, since no-one else has your private key, and could not have generated the signature. DIFFEY-HELLMANN KEY EXCHANGE -- a protocol by which two communicating parties can arrive at a secret piece of information that can not be known to a passive eavesdropper (as in a wiretap), and can not be recovered from analysis of recorded communication. This secret piece of information is usually used as the key for a conventional cryptography algorithm such as DES or IDEA to encrypt following communication. SENDER UNTRACEABILITY -- use of a protocol by which one of a group of commnicating entities can send a public message, while it is impossible to trace the message to the sender. This can be used to send messages anonymously or pseudonymously and untraceably. One of the protocols that makes this possible is David Chaum's dc-net protocol, in which every participant sends some data, and when all the data are combined, the anonymous message emerges. Another is the mix-net, or "remailer" approach. In this case, you send your message to a re-mailer, with encrypted instructions on where to send it. By sending your message through a chain of such remailers, untraceability is achieved. RECEIVER UNTRACEABILITY -- a method by which you can retrieve a message sent to you, without anyone having any way of knowing that you received the message, or indeed if you received any message at all. How it works: anyone wanting to leave a message to you encrypts it with your public key, and posts it on a "bulletin board". You download all the messages from the bulletin board periodically, and see if you can decrypt any using your private key. DIGITAL CASH -- one entity creates some amount of digital "tokens", which may then be transfered to other people, who can transfer them between each other, and when they are returned to their creator, he can not trace the transactions that have occured, only the total balance of a person at the end of the set of transactions. > a clear explanation of how it can be used and why it matters, Each of these technologies by itself can not accomplish much. But if all these are put together, any person can send messages to any other person, without anyone but the two of them knowing that a message was sent, or what it said. As for why it matters, I include here Timothy C. May's Crypto Anarchist Manifesto: The Crypto Anarchist Manifesto Timothy C. May tcmay@netcom.com A specter is haunting the modern world, the specter of crypto anarchy. Computer technology is on the verge of providing the ability for individuals and groups to communicate and interact with each other in a totally anonymous manner. Two persons may exchange messages, conduct business, and negotiate electronic contracts without ever knowing the True Name, or legal identity, of the other. Interactions over networks will be untraceable, via extensive re- routing of encrypted packets and tamper-proof boxes which implement cryptographic protocols with nearly perfect assurance against any tampering. Reputations will be of central importance, far more important in dealings than even the credit ratings of today. These developments will alter completely the nature of government regulation, the ability to tax and control economic interactions, the ability to keep information secret, and will even alter the nature of trust and reputation. The technology for this revolution--and it surely will be both a social and economic revolution--has existed in theory for the past decade. The methods are based upon public-key encryption, zero-knowledge interactive proof systems, and various software protocols for interaction, authentication, and verification. The focus has until now been on academic conferences in Europe and the U.S., conferences monitored closely by the National Security Agency. But only recently have computer networks and personal computers attained sufficient speed to make the ideas practically realizable. And the next ten years will bring enough additional speed to make the ideas economically feasible and essentially unstoppable. High-speed networks, ISDN, tamper-proof boxes, smart cards, satellites, Ku-band transmitters, multi-MIPS personal computers, and encryption chips now under development will be some of the enabling technologies. The State will of course try to slow or halt the spread of this technology, citing national security concerns, use of the technology by drug dealers and tax evaders, and fears of societal disintegration. Many of these concerns will be valid; crypto anarchy will allow national secrets to be trade freely and will allow illicit and stolen materials to be traded. An anonymous computerized market will even make possible abhorrent markets for assassinations and extortion. Various criminal and foreign elements will be active users of CryptoNet. But this will not halt the spread of crypto anarchy. Just as the technology of printing altered and reduced the power of medieval guilds and the social power structure, so too will cryptologic methods fundamentally alter the nature of corporations and of government interference in economic transactions. Combined with emerging information markets, crypto anarchy will create a liquid market for any and all material which can be put into words and pictures. And just as a seemingly minor invention like barbed wire made possible the fencing-off of vast ranches and farms, thus altering forever the concepts of land and property rights in the frontier West, so too will the seemingly minor discovery out of an arcane branch of mathematics come to be the wire clippers which dismantle the barbed wire around intellectual property. Arise, you have nothing to lose but your barbed wire fences! -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: by arrangement. > and a brief summary of the present legal/political > situation--in particular, attempts and suggestions that have been made to > control the technology. The FBI has proposed a "Digital Telephony" bill, which would require all providers of any kind of communications service to build in a wiretap capability for the government. Department of State is restricting the export of any crypto software, claiming that it is a weapon, and therefore falls under ITAR (International Traffic in Arms Regulations) rules. Public Key Partners (PKP) holds the control of patents that cover RSA, and possibly the very idea of public key cryptography. Someone (I can't provide a reference) has proposed that anyone that uses encryption should be required to register their key with the Justice Department, so that the text could be decrypted if a search warrant is issued. These are all the attempts to control this technology that come to my mind right now. The Electronic Frontier Foundation (EFF) can probably provide more information (e-mail to eff@eff.org). > David Friedman > DDFr@Midway.UChicago.Edu > DDFr@AOL.Com -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Tue, 22 Dec 92 22:56:29 PST To: 74076.1041@CompuServe.COM (Hal) Subject: Re: Pax and .fi remailers In-Reply-To: <921223054957_74076.1041_DHJ39-2@CompuServe.COM> Message-ID: <9212230655.AA28469@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > But for this to work, I have to publically announce that my remailer, > hal@alumni.caltech.edu, can be reached at PAX "anonymous" address > anon.100@pax.tpa.com.au. This seems a little strange, as the PAX > address is then no longer anonymous. I have to tell everybody what You don't have to tell anyone that your remailer is behind the anon.100 address. You could just (anonymously, of course) announce that a remailer is running, and can be reached by sending message to the anon.100 address. This way, no-one but the admins at pax can know where the remailer itself lives. This could be useful in case remailers are banned. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: John W Noerenberg Date: Wed, 23 Dec 92 09:08:22 PST To: yanek@novavax.nova.edu (Yanek Martinson) Subject: Re: Signing ascii text Message-ID: <9212231707.AA03963@harvey> MIME-Version: 1.0 Content-Type: text/plain At 11:31 PM 12/22/92 -0400, Yanek Martinson wrote: >> (e.g., email messages, etc). Is there a convention for the end of line >> sequence that is to be used for the copy of the file that is run through >> the hash function? If there isn't, then the file hash will depend on the > >Canonical Text has a CR and LF at the end of each line. This is >documented in some RFC. All (most?) protocols used on internet such >as smtp, finger, etc, use this format. The possible justification >is that an extra linefeed or a carriage return is not as bad as a missing >one. Which RFC are you referring to? While it is true that 821, 822 (and other RFC's which are concerned with email messages) define the end of line as a CRLF, I'm not aware of an RFC which defines canonical text. The style of late has been to define a line "as described in rfc822" or some such. But I don't recall any rfc which defines canonical text spanning session-layer (or higher) protocols. Is there one? john noerenberg jwn2@qualcomm.com noerenberg.j (Applelink) =========================================================== Do not uselessly lament your luck that is giving way, your work that has failed, your life's plans that have all ended in despair. Like a man long prepared, like a man of courage, bid her farewell, the Alexandria that leaves you. -- "The God Abandons Anthony", Constantine Peter Cavafy [1911] =========================================================== From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Messick Date: Wed, 23 Dec 92 11:57:58 PST To: cypherpunks@toad.com Subject: Re: Signing ascii text Message-ID: <9212231902.AA25740@parallax.com> MIME-Version: 1.0 Content-Type: text/plain I would like to argue for a weaker ascii text signature function in PGP in addition to the current one. It would canonicalize a file by turning all sequences of white space into a single space and trimming leading and trailing whitespace from the file before computing the hash. This clearly involves some major changes to the file, allowing many files to hash to the same value, but a human would presumably consider all of those files to have the same information content. The only case that I can think of where the information content of the message could be changed with the signature remaining valid is if information was contained in the pattern of whitespace in the file. This should make the signature robust to most of the changes that a mailer could make. I would not advocate extending this to any non-whitespace characters. -- eric messick eric@toad.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: "Doctor Zaphod" Date: Wed, 23 Dec 92 11:30:19 PST To: CypherPunks@Toad.Com Subject: RE: Signing text messages... Message-ID: <40694.drzaphod@ncselxsi> MIME-Version: 1.0 Content-Type: text/plain In Message 23 Dec 92 00:49:30 EST, Hal writes: >My public key, for those wanting to check the sig on the message below: By including your public key WITH your signed messages, aren't you inviting people to intercept it, replace it with they're own public key, and re-sign the message? If I didn't have a trusted copy of your public key already I wouldn't be able to verify your signature. TTFN! DrZaphod [AC/DC] / [DnA][HP] [drzaphod@ncselxsi.uucp] Technicolorized From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Hal <74076.1041@CompuServe.COM> Date: Wed, 23 Dec 92 08:42:59 PST To: CYPHERPUNKS Subject: Re: Pax and .fi remailer Message-ID: <921223163446_74076.1041_DHJ35-1@CompuServe.COM> MIME-Version: 1.0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Yanek points out a purpose for a PAX-hidden remailer: > You don't have to tell anyone that your remailer is behind the anon.100 > address. You could just (anonymously, of course) announce that a > remailer is running, and can be reached by sending message to the > anon.100 address. This way, no-one but the admins at pax can know > where the remailer itself lives. This could be useful in case > remailers are banned. The problem with this, it seems to me, is that the address of this "secret" remailer is compromised whenever it sends something out. I could just send a "Request-Remailing-To: " message to this PAX anon.100 address, and then look at the return address when the message comes to me from this remailer. So again the anonymity provided by PAX seems to be lost. Now, one way to avoid this would be for the secret remailer not to send its outgoing mail directly to the requested destination, but rather always to insert one or other remailers into the chain. I think it was Yanek himself (or Dr. Z?) who suggested this earlier. This might work, but as was pointed out, if everyone does this we'll just get into infinite mail loops. Still, it might be OK if a well-known public remailer were chosen, especially one that was likely to be relativelly immune to pressure. I noted in the discussion of the anon.penet.fi remailer the author made the point that it was running on a machine in his house, one that he owned and used in his independent business. So presumably his machine is not going to be easy to shut down. (My remailer, OTOH, is running as part of what is basically a guest account on a machine which is to be used just for email and a little telnet/ftp activity. I figure that the remailer performs an email function, speaking broadly, so it's OK under the agreement I signed. But I'm sure that if the admin received some complaints I'd be kicked off. So I can't make any guarantees about how long it will be around.) (This would be another piece of information that would be useful in the remailer database being constructed by Eric Hollander - some comments on how immune the remailer operator would be to political pressure due to unpopular or illegal messages.) If this well-known machine guaranteed NOT to do this remail-via-a-remailer outgoing step, then it could be used by less politically secure remailers to protect themselves from pressure. In such a system, Yanek is right that a remailer could run completely anonymously. Perhaps someone would like to start up a remailer which runs under such a system. Hal Finney 74076.1041@compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBKzhqjKgTA69YIUw3AQFNmAQAgioJMosbMCoit2XflfzK/wgIOkG8qBfG JO3iTWRskVP5Gp43N1bs7W6YhgEXKWdJ/dqNoWrYV2/181zFhXh0xe7lsGifut1b UQGW6DipYIMlW0TbNjhpiIWwAQChn/3NvTJtcBGL0GY3l4ZjMZFs2qBonc/Y1Boe jWfWgQbHSXw= =6y5/ -----END PGP SIGNATURE----- Distribution: CYPHERPUNKS >INTERNET:CYPHERPUNKS@TOAD.COM From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: ghsvax!hal@uunet.UU.NET (Hal Finney) Date: Wed, 23 Dec 92 13:46:51 PST To: cypherpunks@toad.com Subject: Re: Signing text messages... Message-ID: <9212232118.AA23889@nano.noname> MIME-Version: 1.0 Content-Type: text/plain Dr. Zaphod writes: > By including your public key WITH your signed messages, aren't you inviting > people to intercept it, replace it with they're own public key, and re-sign > the message? If I didn't have a trusted copy of your public key already I > wouldn't be able to verify your signature. I'm not sure what attack you are proposing here. Are you suggesting that someone else could take credit for my (brilliant?) message by removing the PGP signature and substituting one of their own? But digital signatures can't stop other people from doing this. Or are you suggesting that someone else could create a bogus public key claiming to mine, re-sign the message using that public key, and then get people to think it was from me? Or, worse, they could create a whole new message saying "I am a turkey, signed Hal Finney", sign it with this bogus "Hal Finney" public key, and post it. Then I'd really have egg on my face, right? But no, I wouldn't, because people would (or should) know not to trust a random public key to be from whom it claims. My posted key is signed by Phil Zimmermann. This doesn't absolutely prove it is from me, but I think it makes it worthwhile to post the key. Anyway, the real reason I posted the key in this case was so that people could check the cleartext signature to see if it had been mangled by various mail gateways. That was the topic of discussion in the message, so I wanted to make it easy for people to try checking the signature. Hal 74076.1041@compuserve.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Messick Date: Wed, 23 Dec 92 19:01:52 PST To: cypherpunks@toad.com Subject: Re: Signing ascii text Message-ID: <9212232303.AA26569@parallax.com> MIME-Version: 1.0 Content-Type: text/plain I wrote: >It would canonicalize a file by >turning all sequences of white space into a single space and trimming >leading and trailing whitespace from the file before computing the >hash. mark@coombs.anu.edu.au resopnded: > If the message contained a table of figures formatted and seperated with > spaces then that method would destroy the readability of the table. The important part here is that the collapsing of whitespace would only affect the message digest, not the text as seen by the user. Two texts which read the same, but differ in whitespace, would have the same signature. If you recieved both files, you could see the difference in spacing, yet the same signature would be valid for both files. The main vulnerability is that a message whose meaning is partially encoded it its whitespace (like an ascii graphic, map, or chart) could have its meaning altered, without affecting the validity of the signature. Clearly one would not want to use this signature method on such texts. It would be a good feature for the signature algorithm to warn the user if it detects a pattern of whitespace that might convey information. I am not sure how to detect this reliably, though. -- eric messick eric@toad.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: "Doctor Zaphod" Date: Wed, 23 Dec 92 16:16:27 PST To: CypherPunks@Toad.Com Subject: Re: Signing text messages... Message-ID: <57860.drzaphod@ncselxsi> MIME-Version: 1.0 Content-Type: text/plain In Message Wed, 23 Dec 92 13:18:54 PST, uunet.uu.net!ghsvax!hal@netcomsv.netcom.com (Hal Finney) writes: >Or are you suggesting that someone else could create a bogus public >key claiming to mine, re-sign the message using that public key, and >then get people to think it was from me? Perhaps they could alter the message, use a bogus public key, and re-sign the message. >But no, I wouldn't, because people would (or should) know not to trust >a random public key to be from whom it claims. My posted key is >signed by Phil Zimmermann. This doesn't absolutely prove it is from >me, but I think it makes it worthwhile to post the key. I didn't realize you had included a signed key. Minus one point for research. Yes, people SHOULD know not to use a publicly posted key. But do they? >Anyway, the real reason I posted the key in this case was so that >people could check the cleartext signature to see if it had been >mangled by various mail gateways. That was the topic of discussion in >the message, so I wanted to make it easy for people to try checking >the signature. Then posting your public key was clearly the right thing to do. I have noticed; however, that people have posted their public key along with a signed message before [there was a discussion on mangled, signed plaintext] and thought I would mention this to anybody who thought they were using infallible methods or authentication. I must urge everybody not to accept any key from a source other then person to person [or using a fone call to exchange MD5 hashes] unless it is signed by smoebody you HAVE exchanged keys with in this way. I hope nobody sees a message with a public key attached to it and says, "Oh! There's a key I can add to my keyring", and abandons the entire key-exchange method. TTFN! nobody saw DrZaphod [AC/DC] / [DnA][HP] [drzaphod@ncselxsi.uucp] Technicolorized From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Marc Horowitz Date: Wed, 23 Dec 92 13:36:28 PST To: edgar@spectrx.Saigon.COM (Edgar W. Swank) Subject: Stripping signatures (was Re: Remailers) In-Reply-To: Message-ID: <9212232135.AA00768@deathtongue.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain I think that signatures should be kept. If you really want to be anonymous, you have bigger things to worry about than your sig showing up or not. And if I want to build a pseudonymous identity for myself, I might want to have a sig for that identity. I wouldn't want the remailers stripping that out. Perhaps it would make sense to have a header field which indicated if the sig should be kept or not. Marc From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: dmandl@shearson.com (David Mandl) Date: Wed, 23 Dec 92 14:49:48 PST To: cypherpunks@toad.com Subject: Interview with Tim May on WFMU Message-ID: <9212232149.AA23069@tardis.shearson.com> MIME-Version: 1.0 Content-Type: text/plain For interested cypherpunks (or anyone else) in the NYC area, I'm going to be interviewing Tim May on my radio show this Saturday. The show's on WFMU (East Orange, NJ), 91.1 FM, from noon-3:00. Tim'll be on starting at 2 PM. --Dave. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Wed, 23 Dec 92 14:31:14 PST To: jwn2@qualcomm.com (John W Noerenberg) Subject: Re: Signing ascii text In-Reply-To: <9212231707.AA03963@harvey> Message-ID: <9212232230.AA21068@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > >Canonical Text has a CR and LF at the end of each line. > Which RFC are you referring to? I am not aware of any single RFC that defines this, but every RFC that I have read, if it mentions end-of-line at all, it is defined as, or assumed to be, a carriage return followed by a newline. Even in cases where the native representation is different, it is converted to this format before transmission through the net, and then converted back. This is in some RFC-s referred to as "internet tradition", or "NetAscii". This is similar to the Network Byte Order. No matter what order your machine stores bytes (little/big endian), it gets converted to one standard format. It is also referred to as "NVT Standard". The only mention of a different end of line convention is in relation to EBCDIC, which has an explicit newline character. Here are excerpts from various RFCs that deal with, or mention, use of CRLF at the end of lines: Request For Comments: 1078 SRI-NIC TCP Port Service Multiplexer (TCPMUX) A TCP client connects to a foreign host on TCP port 1. It sends the service name followed by a carriage-return line-feed . acknowledgment, immediately followed by an optional message of explanation, terminated with a . If the reply was positive, Request for Comments: 1123 R. Braden, Editor Requirements for Internet Hosts -- Application and Support To allow interoperability between arbitrary Telnet clients and servers, the Telnet protocol defined a standard representation for a line terminator. Since the ASCII character set includes no explicit end-of-line character, systems have chosen various representations, e.g., CR, LF, and the sequence CR LF. The Telnet protocol chose the CR LF sequence as the standard for network transmission. Request for Comments: 1184 D. Borman, Editor Telnet Linemode Option line should be transmitted with "CR LF" as the line terminator. When responsible for doing all output processing. Specificly, it should send "CR LF" when it wants the "newline" function Request for Comments: 1204 D. Lee Message Posting Protocol (MPP) USER PASS DATA NOOP QUIT 354 Enter mail, end with . Request for Comments: 1288 Center for Discrete Mathematics and The Finger User Information Protocol Any data transferred MUST be in ASCII format, with no parity, and with lines ending in CRLF (ASCII 13 followed by ASCII 10). Request for Comments: 1312 Crynwr Software Message Send Protocol 2 New lines should be represented using the usual Netascii CR + LF. (Following the Internet tradition, a server should probably be prepared to accept a message in which some other end-of-line convention is followed, but a conforming client must use CR + LF.) NWG/RFC# 561 AKB KP RST JEW 5-SEP-73 11:19 18516 Standardizing Network Mail Headers RFC 561 / NIC 18516 Formal Syntax: ::=
::= ::= ! ::= a string containing any of the 128 ASCII characters except CR and LF ::= a string containing any of the 128 ASCII characters except CR, LF, and SP ::= CR LF ::= space RFC 821 SIMPLE MAIL TRANSFER PROTOCOL MAIL FROM: RCPT TO: DATA SEND FROM: SOML FROM: SAML FROM: HELO QUIT The SMTP commands define the mail transfer or the mail system function requested by the user. SMTP commands are character strings terminated by . The command codes themselves are alphabetic characters terminated by if parameters follow and otherwise. RFC # 822 STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES A message consists of header fields and, optionally, a body. The body is simply a sequence of lines containing ASCII charac- ters. It is separated from the headers by a null line (i.e., a line with nothing preceding the CRLF). field = field-name ":" [ field-body ] CRLF field-body = field-body-contents [CRLF LWSP-char field-body] Each header field may be represented on exactly one line con- sisting of the name of the field and its body, and terminated by a CRLF; Request for Comments: 959 J. Reynolds FILE TRANSFER PROTOCOL (FTP) In accordance with the NVT standard, the sequence should be used where necessary to denote the end of a line of text. (See the discussion of file structure at the end process will interpret appropriately. , in exactly this sequence, also denotes end-of-line. the FTP implementation should use the end-of-line sequence, for ASCII, or for EBCDIC text files, as the For the purpose of standardized transfer, the sending host will translate its internal end of line or end of record denotation into the representation prescribed by the transfer mode and file structure, and the receiving host will perform the inverse translation to its internal denotation. End-of-line in an ASCII or EBCDIC file with no record structure should be indicated by or , respectively. information. The data will be transferred in ASCII or EBCDIC type over the data connection as valid pathname strings separated by or . (Again the user must Request for Comments: 977 Phil Lapsley (U.C. Berkeley) Network News Transfer Protocol Each command line must be terminated by a CR-LF (Carriage Return - Line Feed) pair. that indicates that text will follow. Text is sent as a series of successive lines of textual matter, each terminated with CR-LF pair. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Russell Earl Whitaker Date: Wed, 23 Dec 92 16:03:21 PST To: cypherpunks@toad.com Subject: Forwarded article. Message-ID: <7595@eternity.demon.co.uk> MIME-Version: 1.0 Content-Type: text/plain This article was forwarded to you by whitaker@demon.co.uk (Russell Earl Whitaker): --------------------------------- cut here ----------------------------- Newsgroups: demon.security From: twillis@pintu.demon.co.uk (Tom Willis) Path: eternity.demon.co.uk!demon!pintu.demon.co.uk!twillis Subject: Attempt at a signing policy Distribution: world Organization: DGA Ltd X-Mailer: Simple NEWS 1.90 (ka9q DIS 1.19) Lines: 122 Date: Tue, 15 Dec 1992 23:46:16 +0000 Message-ID: <724463176snz@pintu.demon.co.uk> Sender: usenet@demon.co.uk I would welcome any comments on the following, as a signing policy. What do you think? -----BEGIN PGP SIGNED MESSAGE----- This is my policy for signing keys ================================== (dated 12th December, 1992 1992-12-12) - --Type bits/keyID Date User ID - --pub 1024/6AD0D1 1992/10/24 Tom Willis - -- Key fingerprint = 04 D7 B9 24 50 BE B2 30 BD 23 1A 98 B5 01 F1 46 - -- Tom Willis - -- Tom Willis - -- - -- Tom Willis <100042.446@Compuserve.com> - -- Tom Willis - -- Introduction - ------------ It is my intention that you should be able to trust my signature on any key that you see. However, what you mean by trust and what I mean by it may differ. In overview, I will only sign keys that I have received directly from an individual that claims to own the key, and that I am confident does so. My confidence is based upon the policy I maintain for signing keys. Policy - ------ 1. I will only sign a key that I have received physically during a face-to-face meeting with the person claiming to own the key. 2. I will only sign a key once the claimed key-owner has proved to me that they possess the secret key corresponding to the public key that they have given me. 3. I will only sign a key/ID pair that I believe identifies the person claiming to own the key. 4. I do not claim to have verified that the name the person is using is actually their own legal name; I accept reasonable aliases/handles but require that I am confident that the person regularly uses the name given in public. 5. I do not claim to know that the key owner is trustworthy in signing keys, and is not an agent provocateur. The obvious ones: 6. I will not allow my secret key and password to fall into anyone else's hands. 7. If I find that my secret key has been compromised, I shall do my best to distribute a compromise certificate to anyone who has received a key with my signature. Notes on Policy - --------------- 1. I will accept keys presented on paper or electronically (e.g. on diskette), but the key must have been handed over during a personal meeting with the (claimed) key-owner. 2. To satisfy me that the claimed owner actually *does* possess the secret key, they must return to me a sequence of bytes (chosen by me) signed with their secret key and encrypted with my public key. For example, if I meet someone I do not know well, and we exchange keys, I will not sign their key until I have sent them a sequence of text bytes (e.g. an item in radix-64 form signed by my key), and they have returned the same item to me in a message that is signed and encrypted, and I have checked that my original `challenge' and the returned response are *identical*, and that the message signature agrees with their public key that I posssess. (Otherwise, the physical exchange could well prove nothing about the person involved except they possess the public key of the person they are claiming to be.) 3. My signature says that the key and the associated ID that I sign belong together, so far as I can tell. In order not to mislead you, I won't sign key/ID pairs that look wrong to me. For example, I wouldn't sign even my own father's key, if the ID said something like `President of the United States of America'; because he ain't (and I *know* that!). If my father's key also had a (secondary) ID on it that gave his name as I know it, I *would* sign that association, even if another ID is clearly garbage. 4. I would cheerfully sign a key/ID pair, even if I *knew* that the ID was not the real ID of the owner, if it is a reasonable ID. For example, if my Mother had a stage name, I would certainly sign her key with that ID; I would also sign her key with her maiden name. I wouldn't sign her key/ID where the ID wasn't one I had ever heard her use, though. Not even my Mother, much as I trust her otherwise! 5. My best friend, known since childhood, may be a gonzo when dealing with security; I have no objection to signing his key, but you should not assume that says anything about whether or not I would trust *his* signature myself! (It's OK, mate, just joking, I trust you *really*...) -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBKyqRM6soIBpyatDRAQH96AP/RMa0+MENYZ2EZTHZFiS04mgA40A0ncL5 rpuRePDrhBjAqxN/K5xX9rWWKgxiQgo3OvsY93tjFUZ1mn4ESUEscf57rnXE26cL B/jEz+Kn4P4en8107ydl5VvZkkqMj3f3Vyfkuu5YN6KX2NIbpVzQgKSrV4Ah8vob F0GKx8DdsOs= =O2fB -----END PGP SIGNATURE----- -- Tom \/\/illis | 1. twillis@pintu.demon.co.uk | Have PGP 2.0 key DGA Ltd | 2. GBR55N55@IBMMAIL | ... will swap LONDON UK | 3. 100042.446@Compuserve.com | --------------------------------- cut here ----------------------------- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: wcs@anchor.ho.att.com (Bill Stewart +1-908-949-0705 wcs@anchor.ho.att.com) Date: Wed, 23 Dec 92 15:31:40 PST To: cypherpunks@toad.com Subject: Re: Signing ascii text Message-ID: <9212232331.AA20426@anchor.ho.att.com> MIME-Version: 1.0 Content-Type: text The problem with signing whitespace-compressed canonicalized text isn't the loss of readability, since you can send the non-canonicalized version for humans. The problem is that sometimes the white space IS significant Project-Schedule 1992 1993 1994 Phase 1 X Phase 2 X Phase 3 X would acquire the same signature if you moved the Xs to different columns. If we're going to treat white space in text as significant, we made need to adopt a scheme such as MIME's =xx content-transfer-ncodings; Otherwise we need to declare by fiat that white space is not significant unless protected by an encoding. Bill Stewart From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Richard Childers Date: Thu, 24 Dec 92 00:28:11 PST To: cypherpunks@toad.com Subject: 1993 RSA Data Security Conference Message-ID: <9212240826.AA23973@rchilder.us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain ( I'm sitting here, waiting for Sequent to call back after a late-night systems crash ... may as well put the time to some good use ... )-: Looking for computer & communications products that have real public-key security built in ... maybe interested in enhancing your _own_ products with encryption and authentication technologies ... or just want to know what all the excitement is about ? RSA invites end users, developers and OEMs to attend the 1993 RSA Data Security Conference The only conference and expo devoted exclusively to public-key cryptography. Talk to colleagues, developers, potential customers and experts from the best and the brightest companies in the security business. Get the real story on licensing, standards, algorithm strength, and export restrictions. See the newest public-key products from the biggest vendors in the computer industry. Attend tutorials on secure application design and developing with RSA's cryptography toolkits, such as TIPEM and the new BSAFE 2.0. Find out how others in your line of business are using RSA technology to differentiate their products and improve their own internal security. The conference is being underwritten by RSA Data Security, Inc., and is free to all attendees and exhibitors. Interested ? Registration is extremely limited, and is first-come, first-served. Call RSA today and reserve your seat. 415/595-8782, ask for Conference Registration. Thursday January 14th : Conference Friday January 15th : Tutorials & Exposition Redwood Shores, California -- richard ===== -- richard childers rchilder@us.oracle.com 1 415 506 2411 oracle data center -- unix systems & network administration "If Life is a drama, then, surely, the hardest parts go to the most skillful." From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: mark@coombs.anu.edu.au (Mark) Date: Wed, 23 Dec 92 13:19:37 PST To: cypherpunks@toad.com Subject: Re: Signing ascii text Message-ID: <9212232118.AA01592@coombs.anu.edu.au> MIME-Version: 1.0 Content-Type: text/plain >Date: Wed, 23 Dec 92 11:02:31 PST >From: Eric Messick >It would canonicalize a file by >turning all sequences of white space into a single space and trimming >leading and trailing whitespace from the file before computing the >hash. If the message contained a table of figures formatted and seperated with spaces then that method would destroy the readability of the table. If the file was processed to change tabs to spaces, according to your .exrc settings, then the message would be cleared of any ambiguities from differing lengths of tabs. This is assuming none of the forwarding mail systems between parties replaces a sequence of spaces with a single tab. I personally havent seen such behaviour, nor would I expect it. It makes too many (bad) assumptions. Trailing spaces should of course be nulled as they serve little purpose. Mark mark@coombs.anu.edu.au From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: sdw@sdwsys.lig.net (Stephen D. Williams) Date: Thu, 24 Dec 92 06:09:09 PST To: eric@parallax.com (Eric Messick) Subject: Re: Signing ascii text In-Reply-To: <9212232303.AA26569@parallax.com> Message-ID: <9212241403.AA26014@sdwsys.lig.net> MIME-Version: 1.0 Content-Type: text/plain ... > > The important part here is that the collapsing of whitespace would > only affect the message digest, not the text as seen by the user. Two > texts which read the same, but differ in whitespace, would have the > same signature. If you recieved both files, you could see the > difference in spacing, yet the same signature would be valid for both > files. The main vulnerability is that a message whose meaning is > partially encoded it its whitespace (like an ascii graphic, map, or > chart) could have its meaning altered, without affecting the validity > of the signature. Clearly one would not want to use this signature > method on such texts. It would be a good feature for the signature > algorithm to warn the user if it detects a pattern of whitespace that > might convey information. I am not sure how to detect this reliably, > though. How about two signatures, verbatim and space-collapsed. That way if the latter was valid but the former was not, you would know that spacing was altered but other info remained valid. sdw From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: miron@extropia.wimsey.com (Miron Cuperman) Date: Thu, 24 Dec 92 02:11:40 PST To: cypherpunks@toad.com Subject: Belated holiday travel In-Reply-To: <9212180907.AA07411@portnoy.MIT.EDU> Message-ID: <1992Dec24.092516.2347@extropia.wimsey.bc.ca> MIME-Version: 1.0 Content-Type: text/plain I'll be flying into LA on the 5th of Jan, staying in Santa-Barbara and flying out of LA on the 14th. If anyone is interested in swapping public keys and/or just getting together, please let me know. My house is protected. ;) -- Miron Cuperman | NeXTmail/Mime ok | Public key avail AMIX: MCuperman | cyberspacecomputingcryptoimmortalitynetworkslaissezfaire From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: edgar@spectrx.saigon.com (Edgar W. Swank) Date: Mon, 28 Dec 92 00:54:14 PST To: Cypherpunks Subject: Miron's Remailer Message-ID: MIME-Version: 1.0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- I tried Miron Cuperman's remailer, which requires encrypted input. I noted happily that my automatic signature did not echo back, because it was not part of the encrypted text. I was going to ask how this effected ARA, but Miron has already recognized this problem and proposed a solution. Except for messages to be posted to newsgroups or sent to lists, message bodies are likely to be encrypted with the public key of the recipient. Certainly anyone sending or posting an ARA should also post an "anonymous" public key for the body of the reply. (An anonymous public key is just a key with some nom de plume in the User ID field). Another topic: signed plaintext. Miron's signed plaintext failed the signature check here. This is probably because my editor eliminates trailing blanks. Someone here pointed out that a trailing blank in a blank line may be introduced by an ASCII upload. Until PGP is fixed to eliminate trailing blanks in text, I may have another solution. The editor on this WAFFLE system has an ability to UPLOAD files using (for example) ZMODEM. I have modified the Telix SLT file I use so I have a choice of ASCII or Zmodem upload. Proof of pudding is in eating. Check the signature on this upload, which contains several blank lines. I will be checking with you when I get the echo back. -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBKzi5VN4nNf3ah8DHAQH+dAP/eD8opIrO19Led9SwNDIX6LOiZqlmpOZV jX/30PJ50/1n8BlYowvDaDcPSp6R0JNggYcOg17G88MrpYHq0ODxw0w/wXd+1MHS Twhu2HUy03tJFmbOOX+kVlk2N2RFGag3063QV6SaweVMLg9DEMyPDHiSbeCTxFR7 RapDSiNV/w4= =imWV -----END PGP SIGNATURE----- -- edgar@spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: dmandl@shearson.com (David Mandl) Date: Thu, 24 Dec 92 06:58:20 PST To: cypherpunks@toad.com Subject: Interview with Tim May on WFMU Message-ID: <9212241449.AA25477@tardis.shearson.com> MIME-Version: 1.0 Content-Type: text/plain Yipes. I got a whole bunch of (advance) requests for tapes of the interview, so I'm posting this to the group to make things a bit easier for myself... I'll be more than happy to send copies to anyone for the cost of postage and the blank tape. I'll also be sending a copy to Tim, so if it's easier, you can try to get him to dupe it for you. Of course, being a worrywart, I'll hold off until Monday to confirm that the thing went off without a hitch. I'll post to the group then and let you know. --Dave. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: pmetzger@shearson.com (Perry E. Metzger) Date: Thu, 24 Dec 92 08:30:25 PST To: cypherpunks@toad.com Subject: Re: Signing ascii text Message-ID: <9212241539.AA23696@maggie.shearson.com> MIME-Version: 1.0 Content-Type: text/plain > From: mark@coombs.anu.edu.au (Mark) > > >Date: Wed, 23 Dec 92 11:02:31 PST > >From: Eric Messick > > >It would canonicalize a file by > >turning all sequences of white space into a single space and trimming > >leading and trailing whitespace from the file before computing the > >hash. > > If the message contained a table of figures formatted and seperated with > spaces then that method would destroy the readability of the table. The notion was NOT that the text would be altered in transmition, but that the signature would be computed on canonicalized text. No one was proposing hacking tabs, only that a version of the text with hacked tabs be used to compute the checksum as by hacking the tabs we will have an easy to produce canonical format. The concern Eric presented was that this would allow two files containing substantially different content from a computer's point of view to MD5 the same, but he noted that this isn't a problem in practice because humans don't get much information out of the presense of multiple spaces versus one space. Perry From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Bill Sommerfeld Date: Thu, 24 Dec 92 09:57:49 PST To: sdw@sdwsys.lig.net Subject: Signing ascii text In-Reply-To: <9212241403.AA26014@sdwsys.lig.net> Message-ID: <9212241705.AA00221@orchard.medford.ma.us> MIME-Version: 1.0 Content-Type: text/plain I don't think space-collapsed signatures make any sense; they're only going to mess up If you're going to do any canonicalization, do either exactly what PEM does, or canonicalize tabs and trailing spaces out of the message at posting time. Then do the same canonicalization on the receive end before the signature is verified. If a message transfer path is still "lossy", stop using the unencoded body and just live with radix64 encoding. - Bill From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: rsteiger@denver.cba.du.edu (Todd_Steigerwald) Date: Thu, 24 Dec 92 12:26:56 PST To: cypherpunks@toad.com Subject: Re: Destroying Data Message-ID: <9212242020.AA13761@ denver.cba.du.edu > MIME-Version: 1.0 Content-Type: text/plain > Consider also the technique used in the Norton Utilities > program "Diskwipe" which takes a /g switch which "Follows > certain government rules for wiping". I can't find the manual > but I think it specifies how many repetitions are used and > different values to write in each. The Norton Utilities Wipedisk /g does three passes writing 1's and then 0's, it follows this with the hex 'FF'. This shoud pretty much remove any residual traces of the data previously held on the disk. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Thu, 24 Dec 92 11:13:41 PST To: pmetzger@shearson.com Subject: significance of spaces Message-ID: <9212241912.AA15402@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > of view to MD5 the same, but he noted that this isn't a problem in > practice because humans don't get much information out of the presense of > multiple spaces versus one space. This is true for most text, like this message. But sometimes people send messages where spacing is VERY important: This is especially true of tables such as this one: Name Yes No Smith X Jones X Brown X Xyzzy X If the signature algorithm disregarded spaces, the X's could be moved from one column to the other without affecting the signature. I know that this information COULD have been represented as: Smith Yes Jones No Brown No Xyzzy Yes But sometimes people use the other format. Another solution is to surround all significant spaces with some other character, such as the vertical bar: |Name | Yes | No | |Smith | X | | |Jones | | X | |Brown | | X | |Xyzzy | X | | If this were done, an X could not be moved without affecting the signature even if tabs/spaces were insignificant. The point is that if whitespace is made insignificant, the users must be educated about it, and trained to use one of the two last formats instead of the first one. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: edgar@spectrx.saigon.com (Edgar W. Swank) Date: Mon, 28 Dec 92 00:54:17 PST To: Cypherpunks Subject: Re: Secret PGP Keys Message-ID: MIME-Version: 1.0 Content-Type: text/plain In response to Anton Sherwoods Dec 22 posting: Here's a lame question from a beginner who hasn't even downloaded PGP: Am I supposed to memorize my private key, lest cops beat down the door while I'm out? You would find it difficult to memorize your PGP secret key. It's 384-1024 bits assigned by PGP when it generates a key pair. There's not even any provision for manually entering your secret key. It's only useful in electronic form, on your disk. Which is not to say it may be useful to store it on a floppy at some location removed from the computer in some situations. However, PGP has added something called a "pass phrase" which you can assign to your secret key when you generate a key pair. The pass phrase is optional, but strongly advised. Since you make it up, it should be easy to memorize, so *don't* write it down or store it anywhere where unfriendly forces could find it. PGP uses the pass phrase you assign to encrypt the stored version of the secret key it generates for you. The pass phrase is therefore required (and is prompted for) before the secret key can be used to either decrypt incoming mail or sign outgoing mail. This is your defense against the cops beating down the door. They will find the (encrypted) secret key on your disk. The pass phrase is in your head and you have a right to remain silent; use it. There might be some situation where a judge could order you to give up the pass phrase: you are granted immunity from criminal prosecution (but you don't want to incriminate your friends) or in a civil discovery action. In this case, just claim to have forgotten the pass phrase in the stress of the situation. Stick to that; no-one can prove otherwise. -- edgar@spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: edgar@spectrx.saigon.com (Edgar W. Swank) Date: Mon, 28 Dec 92 00:53:59 PST To: Cypherpunks Subject: Re: Signing ASCII text Message-ID: MIME-Version: 1.0 Content-Type: text/plain I was able to verify Hal Finney's signed plaintext message posted here on Dec 23 with a good signature. Hal says he prepared the original plaintext with no trailing blanks. The editor I use removes trailing blanks whenever it saves text to disk. So there could have been trailing blanks in the plaintext I received (which would have spoiled the signature match) put there by ASCII uploading (of blank lines) or otherwise and I wouldn't know it. I can't really fault mailers that remove trailing blanks; they are trying to avoid consuming bandwidth with null information. I think the answer is a change to PGP to remove trailing blanks anytime -t is active. I have written to Branko to suggest this, but his response was somewhat lukewarm. Perhaps he would change his mind if he received the same suggestion from several individual PGP users. -- edgar@spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: edgar@spectrx.saigon.com (Edgar W. Swank) Date: Mon, 28 Dec 92 00:54:12 PST To: Cypherpunks Subject: Re: remailer signature suppression Message-ID: MIME-Version: 1.0 Content-Type: text/plain Marc Horowitz wrote on Dec 23: I think that signatures should be kept. If you really want to be anonymous, you have bigger things to worry about than your sig showing up or not. I don't follow Marc's logic here. If the wrong sig shows up, it obviously negates all other precautions taken in using remailers, etc. And if I want to build a pseudonymous identity for myself, I might want to have a sig for that identity. I wouldn't want the remailers stripping that out. The problem is if you want to send a mixture of anonymous and regular mail. This involves changing the "sig" on the fly; difficult to do reliably with an automatic script. With loss of anonymity the consequence of the wrong sig appearing with either anonymous or non- anonymous messages. Perhaps it would make sense to have a header field which indicated if the sig should be kept or not. This might be a good compromise. Of course I would prefer the signature-screen: Yes to be the default. Also don't forget that for those of us who can't specify net-headers at will this new header would also have to be specifiable within text via the :: convention or otherwise. -- edgar@spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: hugh@domingo.teracons.com (Hugh Daniel) Date: Mon, 28 Dec 92 01:32:42 PST To: cypherpunks@toad.com Subject: A solution remailer signature suppression In-Reply-To: Message-ID: <9212280931.AA08065@domingo.teracons.com> MIME-Version: 1.0 Content-Type: text/plain There are very good reasons to build remailers (and all mail tools) to pass on all the bytes they can, trailing spaces and .sigs included. Might I sugjest that we set up the remailers with a feature where it tests mail sent from its owner to make sure there is no "compromising" content and that the outer shell verifies correctly, if it fails either of these tests it is dumped in a file and a note returned to you saying someings not right. This has two good features, first you know that what you send out is good looking stuff and that if someone complains that its likely the falut of some machine between the two of you and not you. Second this gets folks running remailers everywhere just as part of the infrastructure of using cryptoware. Does this sound like something we can build upon for everyone? ||ugh Daniel From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Mon, 28 Dec 92 05:58:52 PST To: exi-essay@gnu.ai.mit.edu Subject: INFO: Encryption Technology Message-ID: <9212281358.AA06947@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain The following was written by me in response to David Friedman's request for an overview of various encryption technologies, what they can do, and why they are important. This summary does not discuss any mathematics of this technology, it is meant for someone that wants to know what it is, and what it can do, without having to know all the mathematical details. This message can be stored in the exi-essay ftp archive. Forwarded message: PUBLIC KEY CRYPTOGRAPHY -- each person generates two keys, one is called the public key the other is the private key. These two are related in that what is encrypted with one can only be decrypted with the other. It is impossible (computationally infeasible) to derive one knowing the other. The most popular public key cryptography algorithm is RSA, which is based on the ease of multiplying large primes, and the difficulty of factoring the product. How it is used: you publish the public key, while keeping the private key to yourself. Anyone can send a secret message to you by encrypting it with your public key. You are the only one that can decrypt the message, since only you have the private key. You can reply by encrypting your message with their public key, and they can decrypt it with their private key. DIGITAL SIGNATURES -- techniques that are used to verify that a message claiming to be from you was actually written by you. To do that, you compute a "message digest", which is similar to a "checksum" in that it can be used to check that the message has not been altered. Then you encrypt the "digest" with your private key and attach to the message. Currently the most popular "digest" algorithm is MD5. To verify a signature: the person verifying computes the same checksum, then decrypts the checksum attached to the message. If the two match, the message must have been signed by you, since no-one else has your private key, and could not have generated the signature. DIFFEY-HELLMANN KEY EXCHANGE -- a protocol by which two communicating parties can arrive at a secret piece of information that can not be known to a passive eavesdropper (as in a wiretap), and can not be recovered from analysis of recorded communication. This secret piece of information is usually used as the key for a conventional cryptography algorithm such as DES or IDEA to encrypt following communication. This can be used, for example, for secure telephones. Two people with these phones connect through the usual telephone network, push the "go secure" button, the phones perform Diffey-Hellmann key exchange, and encrypt the following conversation with the resulting secret key. Not that these two people did not have to meet in person, or transmit a key through any other channel. The key was generated as needed. After the conversation is finished, both phones erase the key from their memory. For the next conversation, a new key is set up. Someone who has a recording of a wiretap has absolutely no way of knowing what they key was, and therefore can not decode the conversation. This technology makes wiretaps obsolete. SENDER UNTRACEABILITY -- use of a protocol by which one of a group of communicating entities can send a public message, while it is impossible to trace the message to the sender. This can be used to send messages anonymously or pseudonymously and untraceably. One of the protocols that makes this possible is David Chaum's dc-net protocol, in which every participant sends some data, and when all the data are combined, the anonymous message emerges. This has been called the "cryptographic ouja board", because a message appears, but it is impossible to find out who sent it. If one-time pads are used, this system is unconditionally secure, which means that even an enemy with an infinite amount of time and processing power van not deduce the sender from available information. Another sender untraceability system is the mix-net, or "remailer" approach. In this case, you send your message to a re-mailer, with encrypted instructions on where to send it. By sending your message through a chain of such remailers, untraceability is achieved. This depends on the remailers not keeping logs that can correlate incoming and outgoing messages, or unwillingness to reveal such logs to your enemy. RECEIVER UNTRACEABILITY -- a method by which you can retrieve a message sent to you, without anyone having any way of knowing that you received the message, or indeed if you received any message at all. How it works: anyone wanting to leave a message to you encrypts it with your public key, and posts it on a "bulletin board". You download all the messages from the bulletin board periodically, and see if you can decrypt any using your private key. Since everyone downloads all the messages, and THEN attempts to decrypt them on their own machine, no-one observing the communications link has any way of knowing who received what message, or even if someone received any messages at all. This system, along with the dc-net, can provide completely untraceable global communications. It does, however, require substantial communications bandwidth and storage capacity. DIGITAL CASH -- one entity creates some amount of digital "tokens", which may then be transferred to other people, who can transfer them between each other, and when they are returned to their creator, he can not trace the transactions that have occurred, only the total balance of a person at the end of the set of transactions. This combines the anonymity and untraceability of cash with the convenience and efficiency of electronic transactions. In combination with the above systems, it is superior to cash since any person can pay anyone else, anonymously and untraceably, without having to meet in person. David Friedman asks: "How can it be used, and why does it matter?" Each of these technologies by itself can not accomplish much. But if all these are put together, any person can send messages to any other person, or transact business without anyone but the two of them knowing what occurred, or, even that something at all occurred between these two persons. Furthermore, these two people don't need to know anything about each other, but their public key. They can be completely anonymous, or use a pseudonym. As for why it matters, I include here Timothy C. May's Crypto Anarchist Manifesto: The Crypto Anarchist Manifesto Timothy C. May tcmay@netcom.com A specter is haunting the modern world, the specter of crypto anarchy. Computer technology is on the verge of providing the ability for individuals and groups to communicate and interact with each other in a totally anonymous manner. Two persons may exchange messages, conduct business, and negotiate electronic contracts without ever knowing the True Name, or legal identity, of the other. Interactions over networks will be untraceable, via extensive re- routing of encrypted packets and tamper-proof boxes which implement cryptographic protocols with nearly perfect assurance against any tampering. Reputations will be of central importance, far more important in dealings than even the credit ratings of today. These developments will alter completely the nature of government regulation, the ability to tax and control economic interactions, the ability to keep information secret, and will even alter the nature of trust and reputation. The technology for this revolution--and it surely will be both a social and economic revolution--has existed in theory for the past decade. The methods are based upon public-key encryption, zero-knowledge interactive proof systems, and various software protocols for interaction, authentication, and verification. The focus has until now been on academic conferences in Europe and the U.S., conferences monitored closely by the National Security Agency. But only recently have computer networks and personal computers attained sufficient speed to make the ideas practically realizable. And the next ten years will bring enough additional speed to make the ideas economically feasible and essentially unstoppable. High-speed networks, ISDN, tamper-proof boxes, smart cards, satellites, Ku-band transmitters, multi-MIPS personal computers, and encryption chips now under development will be some of the enabling technologies. The State will of course try to slow or halt the spread of this technology, citing national security concerns, use of the technology by drug dealers and tax evaders, and fears of societal disintegration. Many of these concerns will be valid; crypto anarchy will allow national secrets to be trade freely and will allow illicit and stolen materials to be traded. An anonymous computerized market will even make possible abhorrent markets for assassinations and extortion. Various criminal and foreign elements will be active users of CryptoNet. But this will not halt the spread of crypto anarchy. Just as the technology of printing altered and reduced the power of medieval guilds and the social power structure, so too will cryptologic methods fundamentally alter the nature of corporations and of government interference in economic transactions. Combined with emerging information markets, crypto anarchy will create a liquid market for any and all material which can be put into words and pictures. And just as a seemingly minor invention like barbed wire made possible the fencing-off of vast ranches and farms, thus altering forever the concepts of land and property rights in the frontier West, so too will the seemingly minor discovery out of an arcane branch of mathematics come to be the wire clippers which dismantle the barbed wire around intellectual property. Arise, you have nothing to lose but your barbed wire fences! -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@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^756839 | PGP Public Key: by arrangement. David Friedman asks for a brief summary of the present legal/political attempts and suggestions that have been made to control the technology. The FBI has proposed a "Digital Telephony" bill, which would require all providers of any kind of communications service to build in a wiretap capability for the government. Department of State is restricting the export of any crypto software, claiming that it is a weapon, and therefore falls under ITAR (International Traffic in Arms Regulations) rules. Public Key Partners (PKP) holds the control of patents that cover RSA, and possibly the very idea of public key cryptography. Someone (I can't provide a reference) has proposed that anyone that uses encryption should be required to register their key with the Justice Department, so that the text could be decrypted if a search warrant is issued. These are all the attempts to control this technology that come to my mind right now. The Electronic Frontier Foundation (EFF) can probably provide more information (e-mail to eff@eff.org). -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Eric Messick Date: Mon, 28 Dec 92 11:19:24 PST To: cypherpunks@toad.com Subject: Re: Signing ascii text Message-ID: <9212281831.AA14733@parallax.com> MIME-Version: 1.0 Content-Type: text/plain Stephen D. Williams writes: > How about two signatures, verbatim and space-collapsed. > > That way if the latter was valid but the former was not, you would > know that spacing was altered but other info remained valid. > > sdw This seems to be the correct solution to me. If PGP did this automatically in text signature mode, then it would be up to the reciever to decide if spaces were significant or not, and they would be prompted to think about this when the verbatim signature verification failed. If one often recieved messages with mangled spacing, one could become desensitized to this, but there's not much to be done about that. -- eric messick eric@toad.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: wendtj@jplpost.Jpl.Nasa.Gov (Jeffrey P Wendt) Date: Mon, 28 Dec 92 12:01:22 PST To: cypherpunks@toad.com Subject: TEMPEST companies Message-ID: <9211287255.AA725572669@jplpost.jpl.nasa.gov> MIME-Version: 1.0 Content-Type: text/plain I have recieved information from Veratec re: the product Safe`n'Shield, and I have to say that for an inf0 packet, they have done a great job. The folder comes with 2 sample squares of the Safe`n' Shield material, and the specs for their product are as follows: >----------------------------------------------------------- > Shielding Effectiveness of SAFE`N'SHIELDED (R) >(in dB Attenuation) >___________________________________________________________ >SAF`N'40 tm 10' x 20' x 8' Room >___________________________________________________________ > 10KHz 1MHz 50MHz 400MHz 1GHz >----------------------------------------------------------- > >100 76 53 57 62 >___________________________________________________________ >___________________________________________________________ >SAF`N'60 tm 8' x 8' x 8' Room >___________________________________________________________ > 10KHz 1MHz 50MHz 400MHz 1GHz >----------------------------------------------------------- > >100 N/T* 67 72 87 >___________________________________________________________ >___________________________________________________________ >SAF`N'80 tm 8' x 8' x 8' Room >___________________________________________________________ > 10KHz 1MHz 50MHz 400MHz 1GHz >----------------------------------------------------------- > >100 >81 100 90 90 >___________________________________________________________ In addition to some general notes and a customer list, they provide a 25 page booklet on construction techniques; both new and existing. The material is very thin, about the same weight and feel as good bond paper. The manufacturer states that this material meets the NSA 65-6 spec using this nonwoven material as the priamary shield. The material is applied just like wall paper, with comercial wallpaper glue, and from a construction point of view this stuff looks like you could do an 8x8x8 romm in a few hours. Alas, I did not recieve a price list on the material, but I am sure it will be a hell-of-a-lot cheaper that buying TEMPEST certified computers, and best of all...you don't have to register a damn thing ;-)). The address is: Veretec Long Meadow Road Tuxedo, New York 10987 (919) 577-7447 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: dmandl@shearson.com (David Mandl) Date: Mon, 28 Dec 92 12:54:50 PST To: cypherpunks@toad.com Subject: Radio Interview w/Tim May Message-ID: <9212282013.AA05024@tardis.shearson.com> MIME-Version: 1.0 Content-Type: text/plain OK, folks, the interview went off beautifully (thanks Tim). As mentioned earlier, if anyone wants a copy of the tape, I'll be happy to send one. Unfortunately, I'm going to be a little slow making copies because my cassette deck is crippled at the moment, so be patient. Email me if you're interested. ** Important request: Is there a kind soul out there who would be willing to transcribe the interview (~40 minutes total)??? I just don't have the time. If you can do it, I will mail you a copy of the tape gratis (total value: $1.50 + postage!). --Dave. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: eric@parallax.com (Eric Messick) Date: Tue, 29 Dec 92 14:06:03 PST To: cypherpunks@toad.com Subject: Self Addressed Stamped Envelopes Message-ID: <9212292048.AA19819@parallax.com> MIME-Version: 1.0 Content-Type: text/plain ||ugh and I were talking (over an unsecure phone line :-) last night and came up with an interesting idea. The problem: anonymous replies. Under the current system, the solution is simple: create an `envelope' which implements a path back to you. You include this envelope with your outgoing message, and the respondant places the envelope at the front of any messages to be sent back to you. The envelope is a nested encrypted set of Anon-To: lines that remailers strip off as the message is routed back to you. This system has at least two weaknesses for future use, however. The most serious is that the body of the reply is not altered by the remailers, allowing the message to be more easily traced. The second is that there is no provision for remailers to charge for the service. If postage is included in the envelope itself, it becomes a single use device; it is useless for posting to a newsgroup, for example. Both of these problems can be solved by having each remailer forward the message *with*postage*due*. What that means is that the remailer encrypts the message before sending it on, and saves the key used in an account file along with a message id and the amount due. The body is thus altered on each hop, complicating the process of tracing the message. You also are unable to read the message until you have paid the postage on it, which you do by sending a message to yourself via a similar envelope. That message contains stamps which get removed at each step by the remailers, and replaced with the necessary key for reading the mail. When you recieve the second message back, you have the necessary info to read the first, and have paid for its delivery. A variation would allow the respondant to include the necessary postage (you need to specify how much, thus compromising at least the hop count of your route). To keep each remailer's postage seperate, key pairs could be generated, with the public portion kept outside the envelope, and the secret portion sealed within the envelope, openable only by a single remailer. The postage would be wrapped up in successive keys as specified on the outside of the envelope. The envelope would then specify the keys to be used by each remailer to transform the body. All of this requires defining a message as containing an envelope and a contents. The envelope must be able to specify how the contents are to be encrypted at each hop. Perhaps the envelope could be placed in the header of the message as a single field. Details still need to be worked out. Comments? -- eric messick eric@toad.com From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: hugh@domingo.teracons.com (Hugh Daniel) Date: Tue, 29 Dec 92 16:16:27 PST To: cypherpunks@toad.com Subject: Crypto Bus to Winter Usenix in San Diego Message-ID: <9212300014.AA08503@domingo.teracons.com> MIME-Version: 1.0 Content-Type: text/plain [The Bays (SF and Monteray) area CypherPunks are thinking of takeing a bus to Usenix, if you don't live near the Bays you might want to ingore this message.] Ok a bus will cost about $2500 round trip (keeping the bus in the parking lot for the three or four days of Usenix). If we get 20 people to ride the bus the cost per person is about $125, if we get 30 folks the cost per person is about $83, both of these are ROUND trip prices. If you are interested in rideing the Crypto Bus I need a commitment from you as to a price point. If you are willing to ride the bus at say, $115, then send me (and NOT the group!) email saying what your price point is and if we get enough people then we will do a bus. I need as many commitments as possable this week (before the new year) to get a bus reserved, if you don't read this before the new year then respond on monday or tuesday next week. Late commers will be taken on a first come first served basis, if there are enough folks to do a bus in the next few days. Bus will leave SF Bay area and make a day trip into Mexico, and return to SF Bay area. We get to stop and eat where we want! If you are willing to leave early Sunday, Monday, Thursday or Friday so that we can do a long streach of Mexico coast or something please include that in your email to me. If you have questions please feal free to contact me. ||ugh Daniel Just a 555 acting as a Bus Driver... From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: Marc.Ringuette@GS80.SP.CS.CMU.EDU Date: Tue, 29 Dec 92 15:10:54 PST To: cypherpunks@toad.com Subject: Re: Self Addressed Stamped Envelopes Message-ID: <9212292310.AA23801@toad.com> MIME-Version: 1.0 Content-Type: text/plain If the remailer is willing to keep some state information around for a limited time, auto-reply can be even simpler: when a remailer forwards mail, it saves the return address and replaces it with a unique ID for that mail, which it creates and saves. The recipient can just use the 'reply' command of his mailer. When the remailer gets mail with this unique ID, it plugs in the old return address, encrypts the message to the new destination, and sends it along, retracing its original path. This does provide a weaker security guarantee than if the remailer _throws away_ the correspondence with input and output, though, so a slightly more complicated alternative is probably better. -- Marc Ringuette (mnr@cs.cmu.edu) From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Tue, 29 Dec 92 16:33:58 PST To: Marc.Ringuette@GS80.SP.CS.CMU.EDU Subject: Anonymous Reply Capability (re: Self Addressed Stamped...) In-Reply-To: <9212292310.AA23801@toad.com> Message-ID: <9212300033.AA07511@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain > unique ID for that mail, which it creates and saves. The recipient > can just use the 'reply' command of his mailer. When the remailer > gets mail with this unique ID, it plugs in the old return address, > retracing its original path. For best security with a mix-net remailer, it should immediately forget where a message came from. So if you want anonymous reply capability, the remailer could create that unique id, but instead of associating it with a return address, associate it with a public key (transmitted along with the message). Then when someone sends a reply, the remailer would encrypt it with the public key, and broadcast it. You monitor the broacasts for ones with public keys that match private keys you have. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: ghsvax!hal@uunet.UU.NET (Hal Finney) Date: Wed, 30 Dec 92 13:36:33 PST To: cypherpunks@toad.com Subject: Return addresses Message-ID: <9212302111.AA09802@nano.noname> MIME-Version: 1.0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Eric Messick has an interesting idea in his "postage due" anonymous addresses, where the forwarders would encrypt the message contents as it passed through, and then the receiver would have to pay them to get the message decrypted. Chaum's idea was that the message contents would be encrypted at each step, as Eric suggests, but Chaum would have the encryption key be part of the anonymous address, created by the same person who made the anonymous address. The idea would be, after decrypting the incoming message, the remailer would see something like: Anon-To: Encrypt-With: It would then encrypt the message "contents" (but not the "envelope", as Eric points out) using the specified key. When the owner of the anonymous address received the message, he would decrypt it using the chain of "Encrypt-With" keys that he put into the anonymous address. This does not support Eric's feature of allowing remailers to charge for anonymous addresses, but it does provide more security than the current remailers by changing the message contents at each step. Hal 74076.1041@compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK0IQLqgTA69YIUw3AQHqawQAozCAXrHB1+dksB2fQKeqIoY530340chd PZlznNGv0wp5gZdIJnFqJ/40scABHjuMc7B7e9QnUglMm1j59b6ZJOGON8kOaYsm J19vsCOWEWuQhFtMl6oC4hXxPtjZ1BOdm8lr+RQ7KZlpBTe4eusoEMaV5zMMk1TI vkAT6A4YZ5o= =DZE1 -----END PGP SIGNATURE----- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: gnu@cygnus.com Date: Wed, 30 Dec 92 23:52:29 PST To: cypherpunks@toad.com Subject: Random number generators In-Reply-To: <199212310057.AA02517@eff.org> Message-ID: <9212310751.AA21888@cygnus.com> MIME-Version: 1.0 Content-Type: text/plain > MONTE CARLO TECHNIQUES, > widely used in computer simulations of physical systems, entail the > wholesale generation of random numbers. A new study by scientists at > the University of Georgia (Alan Ferrenberg, 404-542-8460) shows that > even the most advanced random-number generators are biased under > certain circumstances (A.M. Ferrenberg et al., 7 Dec. Physical Review > Letters). Using one state-of-the-art program, the Marsaglia-Zeman > random-number generator, Ferrenberg discovered that a simulated > performance of the two-dimensional Ising model (which models the > behavior of a plane of neighboring spins) did not agree with the > results when calculated exactly by mathematical methods. He traced the > discrepancy to the random- number generator. Other generators tried > had differing faults. > (Science News, 19 & 26 Dec.) Can someone get the paper(s) and/or talk to the researcher? Does he have any programs he can throw into the pot for generating or testing random numbers? John From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: whitaker@eternity.demon.co.uk (Russell E. Whitaker) Date: Thu, 31 Dec 92 07:51:30 PST To: cypherpunks@toad.com Subject: MEETING: Cypherpunks UK (2nd) Message-ID: <7971@eternity.demon.co.uk> MIME-Version: 1.0 Content-Type: text/plain 2nd Meeting, Cypherpunks UK --------------------------- Chris Tame, of FOREST and the Libertarian Alliance, has generously offered the use of the meeting room at his offices for our gathering, Sunday, 10 January 1993, from 1300 onwards, at: FOREST 4th Floor 2 Grosvenor Gardens London SW1W 0DH 071-823-6550 This is just around the corner from Victoria Station, at the end of the mansion block near Hobart Place. There's a dark green cabbie shelter across the street from the entrance, and some British Telecom payphones. Can't miss it, really. However, if you have trouble, call the telephone number above, or call my pager, on 081-812-2661. If it helps, we're in the direction of Buckingham Palace, which is (very) partially visible from our windows. If you wish to attend, you should bring a 3.5" DOS-formatted diskette (sorry! My UN*X machine is an Intergraph workstation, and I can't use it for crypto) with a copy of your PGP 2.0+ public key. I'll sign it there. Mac users: if you don't have Apple File Exchange (what!?), I'll be extra nice and take your keys anyway ( ;-)) for AFE conversion on my IIcx. Not to fear. It might not be a bad idea to copy your public key on each of several diskettes, so you've got a copy to distribute to each of the others. Don't trust me to copy *your* key to others! As a matter of fact, as there are plenty of power points in the meeting room, you should bring your laptop, and/or a desktop PC: when someone hands you a disk-with-key, you can sign her key, and hand her back her diskette, with your own pubkey added. [Note to the novice: don't hand another person your secret key... the one named secring.pgp. Read the documentation.] This should be a lively meeting. Among the topics likely to be discussed are: o The proliferation of public key cryptography in the U.K. o The local development of anonymous remailers and a proposed automated public key repository at Demon Internet Systems o Electronic networking/email security for the novice o Pro-active proliferation of PGP 2.1+ to interesting European, African, and Asian sites - ftp placement - BBS distribution - sneakernet across borders o The use of HPACK in securing local file installations .. and much more! Mark Turner, from Demon Internet Systems, is likely to be on hand to demo DIS for non-DIS users. We've set up our own local, high-quality newsgroups: demon.security demon.security.keys and established the /pub/pgp and /pub/ibmpc/pgp archives on gate.demon.co.uk (expanding recently to include all versions of PGP, and interesting related files). Hope to see you there! Semper vigilans, Semper vigilans, From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: yanek@novavax.nova.edu (Yanek Martinson) Date: Thu, 31 Dec 92 16:02:03 PST To: cypherpunks@toad.com Subject: CFP'93 Electronic Brochure 1.2 (fwd) Message-ID: <9301010001.AA16211@novavax.nova.edu> MIME-Version: 1.0 Content-Type: text/plain Forwarded message: > From: Bruce R Koball > > The Third Conference on Computers, Freedom and Privacy -- CFP'93 > 9-12 March 1993, San Francisco Airport Marriott Hotel, Burlingame, CA > > Sponsored by: Association for Computing Machinery, > Special Interest Groups on: > Communications (SIGCOMM) > Computers and Society (SIGCAS) > Security, Audit and Control (SIGSAC) > > Co-Sponsors and Cooperating Organizations: > > American Civil Liberties Union > American Library Association > Asociacion de Technicos de Informatica > Commission for Liberties and Informatics > Computer Professionals for Social Responsibility > Electronic Frontier Foundation > Freedom to Read Foundation > IEEE Computer Society > IEEE-USA Committee on Communications and Information Policy > Internet Society > Library and Information Technology Association > Privacy International > USD Center for Public Interest Law > U.S. Privacy Council > The WELL (Whole Earth 'Lectronic Link) > > Patrons and Supporters (as of 24 December 1992): > > American Express Corp. > Apple Computer, Inc. > Dun & Bradstreet Corp. > Equifax, Inc. > Information Resource Service Company > Mead Data Central, Inc. > National Science Foundation (pending) > RSA Data Security, Inc. > > > CFP'93 Electronic Brochure 1.2 > > > SCOPE: > > The advance of computer and telecommunications technologies holds great > promise for individuals and society. From convenience for consumers and > efficiency in commerce to improved public health and safety and > increased participation in democratic institutions, these technologies > can fundamentally transform our lives. > > At the same time these technologies pose threats to the ideals of a free > and open society. Personal privacy is increasingly at risk from invasion > by high-tech surveillance and eavesdropping. The myriad databases > containing personal information maintained in the public and private > sectors expose private life to constant scrutiny. > > Technological advances also enable new forms of illegal activity, posing > new problems for legal and law enforcement officials and challenging the > very definitions of crime and civil liberties. But technologies used to > combat these crimes can pose new threats to freedom and privacy. > > Even such fundamental notions as speech, assembly and property are being > transformed by these technologies, throwing into question the basic > Constitutional protections that have guarded them. Similarly, > information knows no borders; as the scope of economies becomes global > and as networked communities transcend international boundaries, ways > must be found to reconcile competing political, social and economic > interests in the digital domain. > > The Third Conference on Computers, Freedom and Privacy will assemble > experts, advocates and interested people from a broad spectrum of > disciplines and backgrounds in a balanced public forum to address the > impact of computer and telecommunications technologies on freedom and > privacy in society. Participants will include people from the fields of > computer science, law, business, research, information, library science, > health, public policy, government, law enforcement, public advocacy and > many others. > > > General Chair > ------------- > Bruce R. Koball > CFP'93 > 2210 Sixth Street > Berkeley, CA 94710 > 510-845-1350 (voice) > 510-845-3946 (fax) > bkoball@well.sf.ca.us > > Steering Committee > ------------------ > John Baker Mitch Ratcliffe > Equifax MacWeek Magazine > > Mary J. Culnan Peter G. Neumann > Georgetown University SRI International > > Dorothy Denning David D. Redell > Georgetown University DEC Systems Research Center > > Les Earnest Marc Rotenberg > GeoGroup, Inc. Computer Professionals > for Social Responsibility > Mike Godwin > Electronic Frontier Foundation C. James Schmidt > San Jose State University > Janlori Goldman > American Civil Liberties Union Barbara Simons > IBM > Mark Graham > Pandora Systems Lee Tien > Attorney > Lance J. Hoffman > George Washington University George Trubow > John Marshall Law School > Donald G. Ingraham > Office of the District Attorney Willis Ware > Alameda County, CA Rand Corp. > > John McMullen Jim Warren > NewsBytes MicroTimes & Autodesk, Inc. > > Simona Nass > Student - Cardozo Law School > > Affiliations are listed for identification only. > > > Pre-Conference Tutorials: > On Tuesday 9 March, the day before the formal conference begins, CFP'93 > is offering a number of in-depth tutorials on a wide variety of subjects > on four parallel tracks. These presentations will range from interesting > and informative to thought-provoking and controversial. The tutorials > are available at a nominal additional registration cost. > > Conference Reception: > Following the Tutorials on Tuesday evening, you are invited to meet new > and old friends and colleagues at an opening reception. > > Single Track Main Program: > The technological revolution that is driving change in our society has > many facets and we are often unaware of the way they all fit together, > especially the parts that lie outside of our own expertise and interest. > The primary goal of CFP'93 is to bring together individuals from > disparate disciplines and backgrounds, and engage them in a balanced > discussion of all CFP issues. To this end our main program, starting on > Wednesday 10 March, is on a single track enabling our attendees to take > part in all sessions. > > Registration is Limited: > CFP'93 registration will be limited to 550 attendees, so we advise you > to register as early as possible and take advantage of the early > registration discounts. > > Luncheons and Banquets: > A key component of the CFP conferences has been the interaction between > the diverse communities that constitute our attendees. To promote this > interaction CFP'93 is providing three luncheons and evening two banquets > with the cost of conference registration. > > EFF Pioneer Awards > All conference attendees are invited to the Awards Reception sponsored > by the Electronic Frontier Foundation (EFF) on Wednesday evening, 10 > March. These, the second annual EFF Pioneer Awards, will be given to > individuals and organizations that have made distinguished contributions > to the human and technological realms touched by computer-based > communications. > > Birds of a Feather Sessions: > CFP'93 will provide a limited number of meeting rooms to interested > individuals for special Birds of a Feather sessions after the formal > program each evening. These sessions will provide an opportunity for > special interest discussions that were not included in the formal > program and will be listed in the conference materials. For further > information contact CFP'93 BoF Chair: > > C. James Schmidt > University Librarian > San Jose State University > One Washington Square > San Jose, CA 95192-0028 > voice 408-924-2700 > voice mail 408-924-2966 > e-mail schmidtc@sjsuvm1.sjsu.edu > > > CFP'93 Featured Speakers: > > Nicholas Johnson > > Nicholas Johnson was appointed head of the Federal Communications > Commission by President Johnson in 1966, serving a seven year term. In > his role as commissioner, he quickly became an outspoken consumer > advocate, attacking network abuses and insisting that those who use the > frequencies under the FCC license are the public's trustees. He has been > a visiting professor of law at the College of Law at the University of > Iowa since 1981 and is currently co-director of the Institute for > Health, Behavior and Environmental Policy at the University of Ohio. > > Willis H. Ware > > Willis H. Ware has devoted his career to all aspects of computer > science--hardware, software, architectures, software development, public > policy and legislation. He chaired the "HEW committee" whose report was > the foundation for the Federal Privacy Act of 1974. President Ford > appointed him to the Privacy Protection Study Commission whose report > remains the most extensive examination of private sector record-keeping > practices. Dr. Ware is a member of the National Academy of Engineering, > a Fellow of the Institute of Electronic and Electrical Engineers, and a > Fellow of the American Association for Advancement of Science. > > John Perry Barlow > > John Perry Barlow is a retired Wyoming cattle rancher, a lyricist for > the Grateful Dead, and a co-founder of the Electronic Frontier > Foundation. He graduated from Wesleyan University with an honors degree > in comparative religion. He writes and lectures on subjects relating to > digital technology and society, and is a contributing editor of numerous > publications, including Communications of the ACM, NeXTworld, > MicroTimes, and Mondo 2000. > > Cliff Stoll > > Cliff Stoll is best known for tracking a computer intruder across the > international networks in 1987; he told this story in his book, "The > Cuckoo's Egg" and on a Nova television production. He is less known for > having a PhD in planetary science, piecing quilts, making plum jam, and > squeezing lumps of bituminous coal into diamonds. > > > CFP'93 Tutorials: > > Tuesday 9 March - Morning Tutorials > > Information Use in the Private Sector > Jack Reed, Information Resource Service Company > Diane Terry, TransUnion Corp. Dan Jones, D.Y. Jones & Assoc. > > This tutorial will deal with the use of personal information from the > point of view of some private sector information vendors and users. It > will include a discussion of the Fair Credit Reporting Act and the > "Permissible Purposes" for obtaining a consumer credit report. > Information used for purposes outside the FCRA will be discussed in > relationship to privacy and societal needs for businesses and > individuals. > > Access to Government Information: > James Love, Director, Taxpayer Assets Project > > The tutorial will examine a wide range of problems concerning citizen > access to government information, including how to ask for and receive > information under the federal Freedom of Information Act, what types of > information government agencies store on computers, what the barriers > are to citizen access to these information resources, and how citizens > can change government information policy to expand access to taxpayer- > funded information resources. > > Exploring the Internet -- a guided journey > Mark Graham, Pandora Systems Tim Pozar, Late Night Software > > This tutorial will give participants a practical introduction to the > most popular and powerful applications available via the world's largest > computer network, the Internet. There will be hands-on demonstrations > of communications tools such as e-mail, conferencing, Internet Relay > Chat, and resource discovery and navigation aids such as Gopher, WAIS, > Archie and World Wide Web. Extensive documentation will be provided. > > Constitutional Law for Non-lawyers (1/2 session): > Mike Godwin, Staff Counsel, Electronic Frontier Foundation > > This tutorial is designed to inform non-lawyers about the Constitutional > issues that underlie computer-crime and computer civil-liberties cases. > The tutorial focuses on the First and Fourth Amendments, but includes a > discussion of the Fifth Amendment and its possible connection to the > compelled disclosure of cryptographic keys. It also includes a > discussion of the appropriateness of "original intent" as a method for > applying the Constitution in the modern era. > > Civil Liberties Implications of Computer Searches & Seizures (1/2 ses.): > Mike Godwin, Staff Counsel, Electronic Frontier Foundation > > This tutorial assumes only a very basic knowledge of Constitutional law > (the prior tutorial provides an adequate background), and outlines how > searches and seizures of computers may raise issues of First and Fourth > Amendment rights, as well as of federal statutory protections. It > includes a discussion of what proper search-and-seizure techniques in > such cases may be. > > > Tuesday 9 March - Afternoon Tutorials > > Practical Data Inferencing: What we THINK we know about you. > Russell L. Brand, Senior Computer Scientist, Reasoning Systems > > What do your transaction trails reveal about you? Are you a good risk > to insure? Are you worth kidnapping, auditing or suing? Which products > should I target at you? Are you a member of one of those groups that I > would want to harass or discriminate against? This tutorial will be a > hands-on approach to digging for data and to piecing it back together. > Time will be divided between malicious personal invasions and sweeping > searches that seek only profit, followed by a brief discussion about > improper inferences and their practical impact on innocent files and > lives. Legal and moral issues will not be addressed. > > Telecommunications Fraud > Donald P. Delaney, Senior Investigator, New York State Police > > Illegal call sell operations in New York City are estimated to be a > billion dollar industry. This tutorial will provide an overview of the > problem, from finger hacking to pay phone enterprises, and will include > an up-to-date assessment of the computer cracker/hacker/phone phreak > impact on telephone company customer losses. Also discussed will be > unlawful access of telephone company switches; unlawful wiretapping and > monitoring; cards, codes and 950 numbers; New York State law and police > enforcement; methods of investigation and case studies. > > Private Sector Marketplace and Workplace Privacy > Ernest A. Kallman, Bentley College, H. Jeff Smith, Georgetown University > > This tutorial will give participants a general overview of privacy > issues affecting uses of personal information (e.g., medical > information, financial information, purchase histories) in the > marketplace as well as privacy concerns in the workplace (e.g., privacy > of electronic and voice mail, work monitoring). The tutorial will also > set the boundaries for privacy arguments in the middle and latter 1990s. > > SysLaw > Lance Rose, Attorney and Author "SysLaw" > > The SysLaw tutorial session will explore in depth the freedom and > privacy issues encountered by computer bulletin boards (BBS), their > system operators and their users. BBSs are estimated to number over > 45,000 today (not counting corporate systems), and range from small, > spare-time hobby systems to systems with thousands of users, grossing > millions of dollars. BBSs are a grassroots movement with an entry cost > of $1,000 or less, and the primary vehicles for new forms of electronic > communities and services. Subjects covered will include: First Amendment > protection for the BBS as publisher/distributor; data freedom and > property rights on the BBS; how far can sysops control BBS user > activities?; and user privacy on BBSs today. > > Note: Tutorial presenters will offer expert opinions and information. > Some may advocate particular viewpoints and thus may put their own > "spin" on the issues. Caveat Listener. > > > CFP'93 Main Program Sessions: > > Wednesday 10 March > > Electronic Democracy > Chair - Jim Warren, MicroTimes and Autodesk, Inc. > > The effects of computer and telecommunications technologies on > democratic processes and institutions are increasing dramatically. This > session will explore their impacts on political organizing, campaigning, > access to representatives and agencies, and access to government > information that is essential for a free press and an informed > electorate. > > Electronic Voting -- Threats to Democracy > Chair - Rebecca Mercuri, University of Pennsylvania > > This panel session will invite representatives covering a broad spectrum > of involvement with the controversial subject of electronic vote > tallying to address such issues as: Is a secure and reliable electronic > voting system feasible? What threats to these systems are identifiable? > Should electronic voting systems be open for thorough examination? Can > auditability be assured in an anonymous ballot setting? Can voting by > phone be practical and confidential? Did Congress exempt voting machines > from the Computer Security Act? > > Censorship and Free Speech on the Networks > Chair - Barbara Simons, IBM > > As online forums become increasingly pervasive, the notion of "community > standards" becomes harder to pin down. Networks and BBSs will link--or > create--diverse, non-geographic communities with differing standards, > laws, customs and mores. What may be frank discussion in one forum may > be obscenity or defamation or sexual harassment in another. This session > will explore the questions of what kinds of freedom-of-speech problems > face us on the Net and what kinds of legal and social solutions we need. > > Portrait of the Artist on the Net > Chair - Anna Couey, Arts Wire > > Computer forums and networks make possible both new artforms and new > ways of remote collaboration and exhibition. The growth of the Net > creates opportunities for the blossoming of dynamic and interactive > artforms and of artistic cultures -- provided that networks become > widely accessible and remain open to artistic expression without > political interference. This session will examine the potentials and the > problems of art and artists on the Net. > > > > Thursday 11 March > > Digital Telephony and Crypto Policy > Chair - John Podesta, Podesta and Associates > > The increasingly digital nature of telecommunications potentially > threatens the ability of law enforcement agencies to intercept them when > legally authorized to do so. In addition, the potential widespread use > of cryptography may render the ability to intercept a communication > moot. This session will examine these issues and the proposals that > have been put before Congress by law enforcement agencies to address > these perceived problems. > > Health Records and Confidentiality > Chair - Janlori Goldman, American Civil Liberties Union > > As the new Administration and Congress consider proposals to reform the > United States health care system, it is imperative that confidentiality > and security safeguards be put in place to protect personal information. > Currently, no comprehensive legislation exists on the confidentiality of > health information. This session will explore the current and potential > uses of health care information, and proposals to safeguard the > information. > > The Many Faces of Privacy > Chair - Willis Ware, Rand Corp. > > Privacy at any cost is foolish, unwise and an untenable position, and > privacy at zero cost is a myth. This two-part session will explore the > balancing act between the two extremes and the costs and benefits that > accrue. The first part will present several examples of systems and > applications in the public and private sectors that stake out a position > in this continuum. The second part will be a panel discussion > exploring the issues raised by the examples previously presented. > > The Digital Individual > Chair - Max Nelson-Kilger, San Jose State University > > We are all represented by personal records in countless databases. As > these records are accumulated, disseminated and coalesced, each of us is > shadowed by an ever larger and more detailed data alter-ego, which > increasingly stands in for us in many situations without our permission > or even awareness. How does this happen? How does it affect us? How will > it develop in the future? What can we do? This session will investigate > these questions. > > > Friday 12 March > > Gender Issues in Computing and Telecommunications > Chair - Judi Clark, Bay Area Women in Telecommunications > > Online environments are largely determined by the viewpoints of their > users and programmers, still predominantly white men. This panel will > discuss issues of freedom and privacy that tend to affect women -- such > as access, identity, harassment, pornography and online behavior -- and > provide recommendations for gender equity policies to bulletin board > operators and system administrators. > > The Hand That Wields the Gavel > Chair - Don Ingraham, Asst. District Attorney, Alameda County, CA > > An inevitable result of the settlement of Cyberspace is the adaptation > of the law to its particular effects. In this session a panel of > criminal lawyers addresses the fallout from a hypothetical computer > virus on the legal responsibilities of system managers and operators. > The format will be a simulated court hearing. Attendees will act as > advisory jurors in questioning and in rendering a verdict. > > The Power, Politics, and Promise of Internetworking > Chair- Jerry Berman, Electronic Frontier Foundation > > This session will explore the development of internetworking > infrastructures, domestically and worldwide. How will this > infrastructure and its applications be used by the general public? What > will the global network look like to the average user from Kansas to > Kiev? How will politics, technology and legislation influence the > access to, and cost of, the Net? How can the potential of this powerful > medium be fully realized? > > International Data Flow > Chair - George Trubow, John Marshall Law School > > The trans-border flow of information on international computer networks > has been a concern for governments and the private sector. In addition > to concerns for privacy and data security, the economic and national > security implications of this free flow of information among scientists, > engineers and researchers around the world are also cause for concern. > This session will assemble a number of speakers to compare the various > perspectives on the problem > > > > Some of the Speakers in the CFP'93 Main Program: > > Phillip E. Agre, Dept. of Communication, Univ. of California, San Diego > Jonathan P. Allen, Dept. of Information & Computer Science, > University of California, Irvine > Sheri Alpert, Policy Analyst, author: "Medical Records, Privacy, and > Health Care Reform" > William A. Bayse, Assistant Director, Federal Bureau of Investigation > William Behnk, Coordinator, Legislative Information System, State of > California > Paul Bernstein, Attorney > Kate Bloch, Hastings College of the Law > Anita Borg, DEC Network Systems Lab > Richard Civille, Computer Professionals for Social Responsibility > Roger Clarke, Reader in Information Systems, Department of Commerce, > Australian National University > Dorothy Denning, Chair, Computer Science Department, Georgetown > University > Janet Dixon, Stanford Linear Accelerator Center > Robert Edgar, Simon and Schuster Technology Group > Kathleen Frawley, American Health Information Management Association > Emmanuel Gardner, District Manager, Government Affairs, AT&T > Mike Godwin, Staff Counsel, Electronic Frontier Foundation > Joe Green, University of Minnesota > Sarah Grey, Computer Department, We The People, Brown presidential > campaign organization (invited) > Will Hill, Bellcore > Carl Kadie, Co-editor, Computers and Academic Freedom News newsletter > Mitch Kapor, Chairman, Electronic Frontier Foundation > David Lewis, Deputy Registrar, Department of Motor Vehicles, > Commonwealth of Massachusetts > James Love, Director, Taxpayers Assets Project > Judy Malloy, Associate Editor, Leonardo Electronic News > Irwin Mann, Mathematician, New York University > David McCown, Attorney > Rob Mechaley, Vice President, Technology Development, McCaw Cellular > Communications, Inc. > Robert Naegele, Granite Creek Technology Inc., Voting Machine Examiner, > consultant to NY State > Barbara Peterson, Staff Attorney, Joint Committee on Information > Technology Resources, Florida Legislature > Jack Reed, Chairman, Information Resource Service Company > Virginia E. Rezmierski, Assistant for Policy Studies to the Vice > Provost for Information Technology, University of Michigan > Jack Rickard, Editor, Boardwatch Magazine > Randy Ross, American Indian Telecommunications > Roy Saltman, National Institute of Standards and Technology > Robert Ellis Smith, Publisher, Privacy Journal > David Sobel, Computer Professionals for Social Responsibility > Ross Stapleton, Research Analyst, Central Intelligence Agency > Jacob Sullum, Associate Editor, Reason Magazine > Greg Tucker, Coordinator, David Syme Faculty of Business, > Monash University, Australia > Joan Turek-Brezina, Chair, Health and Human Services Task Force on > Privacy of Private-Sector Health Records > > > Registration: > Register for the conference by returning the Conference Registration > Form along with the appropriate payment. The registration fee includes > conference materials, three luncheons (Wednesday, Thursday and Friday), > two banquet dinners (Wednesday and Thursday) and evening receptions > (Tuesday, Wednesday and Thursday). Payment must accompany registration. > > Registration Fees are: > If mailed by: 7 February 8 March on site > Conference Fees: $300 $355 $405 > Tutorial Fees: $135 $165 $195 > Conference & Tutorial $435 $520 $600 > > Registration is limited to 550 participants, so register early and save! > > By Mail: By Fax: > (with Check or Credit Card) (with Credit Card only) > CFP'93 Registration Send Registration Form > 2210 Sixth Street (510) 845-3946 > Berkeley, CA 94710 Available 24 hours > > By Phone: By E-Mail: > (with Credit Card only) (with Credit Card only) > (510) 845-1350 cfp93@well.sf.a.us > 10 am to 5 pm Pacific Time > > CFP'93 Scholarships: > The Third Conference on Computers, Freedom and Privacy (CFP'93) will > provide a limited number of full registration scholarships for students > and other interested individuals. These scholarships will cover the full > costs of registration, including three luncheons, two banquets, and all > conference materials. Scholarship recipients will be responsible for > their own lodging and travel expenses. Persons wishing to apply for one > of these fully-paid registrations should contact CFP'93 Scholarship > Chair, John McMullen at: mcmullen@mindvox.phantom.com > > Hotel Accommodations: > The Third Conference on Computers, Freedom and Privacy will be held at > the San Francisco Airport Marriott Hotel in Burlingame, CA. This > facility is spacious and comfortable, and is easily accessible from the > airport and surrounding cities. Because of the intensive nature of the > conference, we encourage our attendees to secure their lodging at the > conference facility. Special conference rates of $99/night, single or > multiple occupancy, are available. Our room block is limited and these > conference rates are guaranteed only until 9 February 1993, so we urge > you to make your reservations as early as possible. When calling for > reservations, please be sure to identify the conference to obtain the > conference rate. Hotel Reservations: (415) 692-9100 or (800) 228-9290. > > Refund Policy: > Refund requests received in writing by February 19, 1993 will be > honored. A $50 cancellation fee will be applied. No refunds will be made > after this date; however, you may send a substitute in your place. > > Registration Form > > Name (Please print):__________________________________________________ > > Title:________________________________________________________________ > > Affiliation:__________________________________________________________ > > Mailing Address:______________________________________________________ > > City, State, Zip:_____________________________________________________ > > Country:______________________________________________________________ > > Telephone:_____________________________Fax:___________________________ > > E-mail:_______________________________________________________________ > > Privacy Locks: > We will not sell, rent, loan, exchange or use this information for any > purpose other than official Computers, Freedom and Privacy Conference > activities. A printed roster will be distributed to attendees. Please > indicate the information you wish to be excluded from the roster: > __Print only name, affiliation and phone number > __Print name only > __Omit all information about me in the roster > > Registration Fees (please indicate your selections): > If mailed by: 7 February 8 March on site > Conference Fees: $300__ $355__ $405__ > Tutorial Fees $135__ $165__ $195__ > Conference & Tutorial $435__ $520__ $600__ > > If you have registered for the Tutorials, select one from each group: > 9:00 AM - 12:00 Noon > __Information Use in Private Sector > __Constitutional Law for Non-lawyers & Civil-liberties > Implications of Computer Searches and Seizures > __Access to Government Information > __Exploring the Internet > > 1:30 PM - 4:30 PM > __Practical Data Inferencing: What we THINK we know about you. > __Telecommunications Fraud > __Private Sector Marketplace and Workplace Privacy > __SysLaw > > Payments: Total Amount____________ > > Please indicate method of payment: __Check (payable to CPF'93) > (payment must accompany registration) __VISA > __MasterCard > > Credit card #______________________________Expiration date____________ > > Name on card__________________________________________________________ > > Signature_____________________________________________________________ > > -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 From: jim@RSA.COM (Jim Bidzos) Date: Tue, 22 Dec 92 15:12:44 EST To: mrr@scss3.cl.msu.edu Subject: RIPEM message for your approval In-Reply-To: <9212221821.AA16897@scss3.cl.msu.edu> Message-ID: <9212222010.AA22792@RSA.COM> MIME-Version: 1.0 Content-Type: text/plain Mark- As you can imagine, many changes have been proposed, and, I think, some good ones incorporated, in the most current form of the RSAREF license. These changes are based on constructive comments from over twenty people. These changes may encourage folks to distribute RSAREF and RIPEM who otherwise would not have. We plan to make all RSAREF applications (such as RIPEM) availble WITH RSAREF. Why shouldn't someone get all the stuff built on it if they get RSAREF? (Including helpful code such as the Thompson/Schiller emacs adapter.) I assume you have no objection. I'm hopeful that you see these changes as positive; please let me know if that's not true! I offer a summary of them, the rationale, perceived benefits, and a complete copy of the revised license. ------------------------------------------------------------------ Here's a summary of the changes between what's attached (the one we plan to now "standardize" on for RSAREF) and what you sent me: changed 1(a) and added (8): the license is now perpetual. Some have claimed RSA might "suddenly" decide to cancel RSAREF licenses. It is now crystal clear that the license can only be cancelled by violating the agreement. RSA cannot cancel it at its discretion. And even if you violate it, it doesn't cancel the license of those who got it from you. I think this is an importnat clarification, from what I've heard. changed 1(c) and added 2(d): We don't care about any porting or performance mods, but we don't feel we should allow automatic access under the normal interface. We've granted it to you since RIPEM predates RSAREF (also to John Gilmore for a secure RLOGIN using Diffie-Hellman) and we'll grant it to anyone for any reasonable use. (We state so in the Agreement.) We just want to know what it is we're allowing to go around the interface. End of Section 1 - a clarification in the form of an addition is made here. Some have said that unrelated software on a tape with RSAREF could be covered by the restrictions imposed on RSAREF Application Programs. This should clear that up. (I believe this helps you in the separate distribution of the RIPEM code minus the RSAREF code.) changed (6): We simply have removed RSA's $5,000 cap on protecting RSAREF users against charges from some other patent holders. (Like PKP!) Some have claimed that RSAREF was posibly a way to "set up" users for PKP (the patent holders) since $5K was hardly enough to defend against patent infringement. (They actually thought RSAREF was a way to get people to infringe just so that PKP could sue them! RSA pays $5,000, but PKP collects more, therefore it's a 'you hold em, and I'll hit em' thing, or so I guess they thought.) I believe this makes it clear we intend to sue no one for using RSAREF, and in fact defend users ALL THE WAY if someone else does. I think these are all for the better, and will engender trust in RSA's intentions with RSAREF, to support free PEM. --------------------------------------------------------------------- New RSAREF License (December 1992 version) ---------------------------------------------------------------------- RSA LABORATORIES PROGRAM LICENSE AGREEMENT RSA LABORATORIES, A DIVISION OF RSA DATA SECURITY, INC. ("RSA") GRANTS YOU A LICENSE AS FOLLOWS TO THE "RSAREF" PROGRAM: 1. LICENSE. RSA grants you a non-exclusive, non-transferable, perpetual (subject to the conditions of section 8) license for the "RSAREF" program (the "Program") and its associated documentation, subject to all of the following terms and conditions: a. to use the Program on any computer in your possession; b. to make copies of the Program for back-up purposes; c. to modify the Program in any manner for porting or performance improvement purposes (subject to Section 2) or to incorporate the Program into other computer programs for your own personal or internal use, provided that you provide RSA with a copy of any such modification or Application Program by electronic mail, and grant RSA a perpetual, royalty-free license to use and distribute such modifications and Application Programs on the terms set forth in this Agreement. d. to copy and distribute the Program and Application Programs in accordance with the limitations set forth in Section 2. "Application Programs" are programs which incorporate all or any portion of the Program in any form. The restrictions imposed on Application Programs in this Agreement shall not apply to any software which, through the mere aggregation on distribution media, is co-located or stored with the Program. 2. LIMITATIONS ON LICENSE. a. RSA owns the Program and its associated documentation and all copyrights therein. You may only use, copy, modify and distribute the Program as expressly provided for in this Agreement. You must reproduce and include this Agreement, RSA's copyright notices and disclaimer of warranty on any copy and its associated documentation. b. The Program and all Application Programs are to be used only for non-commercial purposes. However, media costs associated with the distribution of the Program or Application Programs may be recovered. c. The Program, if modified, must carry prominent notices stating that changes have been made, and the dates of any such changes. d. Prior permission from RSA is required for any modifications that access the Program through ways other than the published Program interface or for modifications to the Program interface. RSA will grant all reasonable requests for permission to make such modifications. 3. NO RSA OBLIGATION. You are solely responsible for all of your costs and expenses incurred in connection with the distribution of the Program or any Application Program hereunder, and RSA shall have no liability, obligation or responsibility therefor. RSA shall have no obligation to provide maintenance, support, upgrades or new releases to you or to any distributee of the Program or any Application Program. 4. NO WARRANTY OF PERFORMANCE. THE PROGRAM AND ITS ASSOCIATED DOCUMENTATION ARE LICENSED "AS IS" WITHOUT WARRANTY AS TO THEIR PERFORMANCE, MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE RESULTS AND PERFORMANCE OF THE PROGRAM IS ASSUMED BY YOU AND YOUR DISTRIBUTEES. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU AND YOUR DISTRIBUTEES (AND NOT RSA) ASSUME THE ENTIRE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 5. LIMITATION OF LIABILITY. EXCEPT AS EXPRESSLY PROVIDED FOR IN SECTION 6 HEREINUNDER, NEITHER RSA NOR ANY OTHER PERSON WHO HAS BEEN INVOLVED IN THE CREATION, PRODUCTION, OR DELIVERY OF THE PROGRAM SHALL BE LIABLE TO YOU OR TO ANY OTHER PERSON FOR ANY DIRECT, INCIDENTAL OR CONSEQUENTIAL DAMAGES, EVEN IF RSA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. 6. PATENT INFRINGEMENT OBLIGATION. Subject to the limitations set forth below, RSA, at its own expense, shall: (i) defend, or at its option settle, any claim, suit or proceeding against you on the basis of infringement of any United States patent in the field of cryptography by the unmodified Program; and (ii) pay any final judgment or settlement entered against you on such issue in any such suit or proceeding defended by RSA. The obligations of RSA under this Section 6 are subject to: (i) RSA's having sole control of the defense of any such claim, suit or proceeding; (ii) your notifying RSA promptly in writing of each such claim, suit or proceeding and giving RSA authority to proceed as stated in this Section 6; and (iii) your giving RSA all information known to you relating to such claim, suit or proceeding and cooperating with RSA to defend any such claim, suit or proceeding. RSA shall have no obligation under this Section 6 with respect to any claim to the extent it is based upon (A) use of the Program as modified by any person other than RSA or use of any Application Program, where use of the unmodified Program would not constitute an infringement, or (B) use of the Program in a manner other than that permitted by this Agreement. THIS SECTION 6 SETS FORTH RSA'S ENTIRE OBLIGATION AND YOUR EXCLUSIVE REMEDIES CONCERNING CLAIMS FOR PROPRIETARY RIGHTS INFRINGEMENT. NOTE: Portions of the Program practice methods described in and subject to U.S. Patents Nos. 4,200,770, 4,218,582 and 4,405,829, and all foreign counterparts and equivalents, issued to Leland Stanford Jr. University and to Massachusetts Institute of Technology. Such patents are licensed to RSA by Public Key Partners of Sunnyvale, California, the holder of exclusive licensing rights. This Agreement does not grant or convey any interest whatsoever in such patents. 7. RSAREF is a non-commercial publication of cryptographic techniques. Portions of RSAREF have been published in the International Security Handbook and the August 1992 issue of Dr. Dobb's Journal. Privacy applications developed with RSAREF may be subject to export controls. If you are located in the United States and develop such applications, you are advised to consult with the State Department's Office of Defense Trade Controls. 8. TERM. The license granted hereunder is effective until terminated. You may terminate it at anytime by destroying the Program and its associated documentation. The termination of your license will not result in the termination of the licenses of any distributees who have received rights to the Program through you so long as they are in compliance with the provisions of this license. -----------------------------------------------------------------