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