December 2003 - cypherpunks-legacy

Information Highway Beautification Fund
by jim＠Tadpole.COM 17 Dec '03

17 Dec '03

Date: Fri, 4 Mar 1994 04:01:33 -0500 From: "Carl Malamud" <carl(a)radio.com> To: "Announcements" <announce(a)radio.com> Org: Internet Multicasting Service Channel: Internet Town Hall Subject: Information Highway Beautification Fund The Information Highway Beautification Fund Abstract: A Proposal To Turn on the Lights on the Information Superhighway This document outlines some of the background on the Clipper proposals and shows how Clipper is just one example of the underlying public key technology. We argue that in the Clipper debate has concentrated on national security and individual privacy and we may have lost sight of other fundamental constitutional issues, the need to promote commerce and establish a safe and secure information highway. Businesses will not open their doors to cyberspace until we provide clean, well-lit streets in the global village. This document proposes a royalty-free licensing pool for the technology, obtaining public use of the public key patents through the use of eminent domain or other mechanisms. The document then proposes a license for users of the public key technology, the proceeds of which would be placed in an Information Highway Beautification Fund. The license allows an individual or corporation (presumably with different fees structures for each type of user) the right to use the basic public key technology. The proceeds from the license fee would be used to pay back the original patent holders and to fund public works projects on our National Information Infrastructure. A crucial aspect of this proposal is that the license plates be on a per-person basis, not on a per-certificate basis. People must be able to change their certificates on a frequent basis: the license is a right to use the technology not a fee for a single certificate. This is not an invitation to have a single government certification hierarchy or to register the certificates. The license is a right to use the technology, not an invitation to form a universal ID system or a rigid, inflexible certification bureaucracy. In fact, it is possible (and often desirable) to use the basic public key technology without using a certificate at all. Background: The Clipper Controversy The current debate on cryptography and computer security centers around two often-conflicting government functions embodied in our constitution: maintaining our national security and preserving the rights to personal privacy. The public debate on the Clipper issue has revolved around the question of whether government should have a "back door" into a cryptographic chip. Should the government be able, under appropriate court orders, to decode a conversation? Should criminals be able to hide themselves behind a mask of strong cryptography? The Clipper proposal requires government users to purchase a chip that has a special key that is kept in the custody of two government agencies, a concept known as "key escrow." Under appropriate conditions, the government can decode a conversation that was encoded using the Clipper chip. The Clipper proposals use the theory that government, by purchasing large numbers of these chips, will encourage private users to adopt the same scheme, thus leading to lower prices from higher volumes and also leading to a standard for the use of cryptography on the information highway. While the national security and law enforcement goals are clear, there are strong reasons why this proposal may not work. The efficacy of a key escrow scheme and the ability of the government to keep these crucial secrets hidden has been questioned by computer and legal experts. Civil liberties experts have questions the constitutional propriety of a back door. Leaving aside the basic constitutional issues, the idea that the government will lead through its purchasing power has been shown to be flawed in a number of other situations. In the area of the Government OSI Profiles (GOSIP), for example, NIST and other agencies attempted to lead the market through purchases but ended up far behind the technology curve as government and business alike flocked to solutions that were more practical and cost effective. Just because the government purchases lots of $600 hammers doesn't mean that corporate users will necessarily follow suit. The real problem with the Clipper debate, however, is that we have neglected some much more fundamental issues: the question of how we deal with public key cryptography. Public key cryptography, the underlying technology behind the Clipper chip, does much more than simply encrypt data, it is a building block for our information highway. The Importance of Public Key Cryptography Public key cryptography is a fundamental technology that provides a basic security fabric for the national information infrastructure. The most important function it provides is authentication, the ability to know who another person or computer or program is in cyberspace. Public key cryptography is the basic stuff from which we make streetlights for the information highway. Authentication and privacy of data are two functions of a security infrastructure, but there are others. For example, public key cryptography allows us to append a digital signature to a document, a method that allows us to verify the integrity of the document and assure the recipient that the document was not changed since it was originally generated. Public key cryptography also allows us to provide services such as non-repudiation, a way of verifying that a document was actually received (analogous to a delivery receipt from a registered letter). Public key cryptography thus provides a bundle of extremely fundamental services: authentication, privacy, message integrity, and non-repudiation, among others. This technology is so basic that it must be embodied throughout our computer networks in a way as fundamental as the deployment of steel in a building. Public key cryptography is one of the basic building blocks for computer networks. Many people feel that they need to decide how this technology should be applied. The Clipper proponents, for example, feel that public key cryptography is to be used to encrypt bits on the wire. Another community is advocating a particular style of electronic mail, known as Privacy Enhanced Mail (PEM). A building block as fundamental as public key cryptography must be deployed throughout the infrastructure. No one person or group will know in advance everywhere we need to use something so basic. Take PEM for example. Even if PEM is your messaging solution, there are a host of other applications ranging from remote login to file transfer to listening to radio or making a telephone call. The important point is that we don't know now all the ways that we use a general-purpose infrastructure. We will only know as we deploy it and we can't deploy the technology until we get the basic tools to make it secure. We cannot make security a special service. We cannot make security a government program or the responsibility of a particular group. We must build security into the very framework of the NII or the streets of the global village will remain unpopulated. Without a fundamental security infrastructure, businesses will not conduct commerce on the NII, but will have to build special-purpose networks for each function. Sharing an infrastructure is essential if we are to realize the cost savings of an information highway and even more essential if we are to provide the framework that will encourage small, mom-and-pop digital delis open their doors for business. The current policy debate ignores the fundamental economic importance of services such as authentication. We cannot open our doors for business until we can see who is knocking at the door. We can't sell a fax for two cents or a movie on demand for a dollar or do any of the fundamental transactions of an economy without this basic technology. Commerce in the real world requires a multitude of different models and methods. Cash, barter, purchase orders, credit cards, and checks are just a few of the methods. There is no reason to think that we can avoid the same real-world motley technology in cyberspace. We need to build the fundamental technologies of public key cryptography into the very fabric of our infrastructure, applying security throughout the NII at all layers. How Public Key Works To understand why public key is so fundamental, it helps to have a basic idea of how it works. The public key technology is based on two related keys: a private key and a public key. You keep your private key secret and let people know your public key. A piece of data encoded with the private key can be only decoded with the public key and vice versa. The most obvious application of this technology is privacy. I take your public key and encode a message. You have your private key and can decode the message. Alternatively, I take my own private key and encode the message. You have my public key and can decode the message. In reality, public key cryptography is a very slow way of encoding and decoding an entire message. Instead, we use public key cryptography to exchange a shared secret: a symmetric key that we both know about and use to do encoding and decoding. For example, a common encryption algorithm is the Data Encryption Standard (DES). DES is very fast, but requires both parties to know the same DES key. In a typical scheme, we would use the public key method to exchange the DES key and then use the DES key to encode the message. For example, I could generate an arbitrary DES key and hide it by encoding it with your public key. You would then "unwrap" the package with your private key and use the resulting shared secret to quickly and efficiently decode my message to you. The fundamental benefit that public key gives us is authentication: knowing who we are talking to. If I know your public key, you can use your private key to send me a "certificate." I know that only you could have generated this certificate, since I am able to decode it successfully using your public key. Certificates ultimately only work if public keys are widely deployed and well-known. The scheme proposed by many is to define a standard certificate, containing a public key and information about the certificate holder, such as the name or institutional affiliation. Validation of certificates is done using a certificate hierarchy. If there are a few very well known public key, say for the federal government or for MIT, that key combination can be used to certify other public keys. I know that your public key is really yours because MIT certifies that it is and everybody knows the MIT key. There are thus two aspects to a security infrastructure. First, there must a wide deployment of public-key based certificates. Second, there must be many different kinds of programs throughout the computer network that understand what a certificate is and how to use it. One program might use the keys as the basis for encrypting data on the wire or in an electronic mail message. Another set of services might use keys as the basis for allowing access to telecommunications service or for deciding the type of access to libraries a person should get. The Current Status of Public Key Cryptography Public key cryptography has its roots in research conducted at Stanford by Diffie and Hellman and at MIT by Rivest, Shamir, and Adleman. In both cases, the academic research efforts spun off commercial companies. In the case of Stanford, the company Cylink was formed and in the case of MIT a company called RSA Data Security, Inc. was formed. The basic patents that govern public key cryptography are thus owned by four entities: MIT, Stanford, Cylink, and RSA. Because the basic technology is so intertwined, one cannot really do effective work in the field without using pieces of several different patents. To resolve licensing problems, the four entities formed Public Key Partners, which handles licensing of the technology. A commercial entity that wants to use public key technology needs a license from Public Key Partners. Because the basic technology was developed with federal dollars, the federal government has the right to use the technology. In addition, in many international jurisdictions the technology is widely available, to the extent that the basic algorithms can be downloaded anonymously from a variety of locations. To address the question of non-commercial use, RSA has worked with the Internet Engineering Task Force on the PEM proposals. In the case of PEM, there are versions of the software that are available for federal and academic institutions. It should be noted that the reference implementation that RSA provides for non-commercial users is specifically restricted to PEM- like mail systems and does not apply to general-purpose uses of the technology. Commercial users, of course, must use a licensed version from a software developer or negotiate a license directly with Public Key Partners. Commercial entities in the United States, groups that include software developers, computer hardware companies, and telecommunications companies, must secure a license from Public Key Partners. Public Key Partners has pursued a strategy that has resulted in a number of large corporations licensing the technology, including DEC, Lotus, and many others. However, commercial deployment has been limited because of the lack of the ability to build the technology into multi-vendor standards and because of the lack of a certificate system. More importantly, small businesses have often avoided the technology because of fears of high licensing costs. To complicate matters, the National Institute of Standards and Technology (NIST) has proposed a public key standard that is related to the RSA algorithms. In order to get around potential patent conflict problems, the commercial rights to this technology go to Public Key Partners. Public Key Partners thus has an exclusive grasp on this basic technology in the commercial realm. The current patent situation is very much like the situation earlier this century for vacuum tubes and for Frequency Modulation (FM). In both those cases, the fundamental patents were so intertwined that no progress was made in the field. In both cases, the federal government stepped in to help lead us towards a solution. A Proposal: The Information Highway Beautification Fund The main problem with the current situation is that it requires every developer to obtain a license. Licenses are priced high enough that small, ad hoc developers can be easily discouraged. More importantly, it leaves the decision on how to use the technology in the hands of a few entities, such as NIST or Public Key Partners. The decision on who gets a license is an appropriate one for some technologies, but not for one as basic as public key. We need the engineers building our NII to be able to use fundamental tools without asking each time they come up with a new application. Public key cryptography is a classic public good. If we can universally deploy certificates, there is a tremendous public benefit, benefits that are not reflected in a system based on commercial licensing of monopoly patents. Public key-based certificates are the license plates for the information highway, the light that lets us know who we are talking to. While Public Key Partners may derive some benefit from selling the technology to a few large corporations, society (and under our proposal, Public Key Partners) will benefit even more from universal deployment. If we recognize the fundamental importance of this technology, there are some policy options that easily come to mind. The first policy outcome, the one essential to conducting electronic commerce on the Internet, is to make public key technology widely available. We propose here a royalty-free license pool for the public key patents. It is essential that the pool allow use of the technology without prior approval: no one bureaucracy or regulation can determine in advance how this technology can be used. Such a pool could be established by negotiation between the federal government and Public Key Partners, or could be established by more assertive techniques such as the use of eminent domain. The use of eminent domain recognizes that the patents are valuable property. Eminent domain says that your property is very nice, but unfortunately we need to build a freeway through it. Eminent domain recognizes the taking and requires the government to compensate the property owners. Eminent domain is an extreme way of reaching the goal of making the technology widely available, and there are other, less drastic solutions available. However, the key point is that the technology must become widely available to allow us to build it into the infrastructure of our information highway. Once the technology is available, we suggest that the government establish a license, a fee which is levied upon a user or corporation. We beg the question here of the format of the certificate (and feel strongly that a single certificate hierarchy or certificate format would be a grave technical and constitutional mistake). We suggest instead that the government resolve the more fundamental issue of placing the technology in an open pool and levying a per-user license fee. Once the basic principle is in place, the government can convene a set of hearings to flesh out details such as which agency collects the license fee and the fee structure. Presumably, the user fee would be a one-time fee of $100 or less and corporations would pay on a sliding scale that would encourage small enterprises. A crucial aspect of this proposal is that the license fee be on a per user basis, not on a per certificate basis. We cannot have a government hierarchy of certificates, or a requirement to keep certificates in some standard format, or to keep certificates around to allow an audit or to control how the certificate is used, In fact, there are many instances where public key technology would not use a certificate. The fee pays for a license to use the technology not a way to audit how the technology gets used. The revenues from the proposed license fee would be placed in the Information Highway Beautification Fund. Part of the proceeds of this fund would go to pay back Public Key Partners for the taking under eminent domain, and the remainder would go towards paying for public works projects on the NII. The public works part of the fund would be available to pay for things like information interstates, publicly funded information sources, and establishing equal access to the information highway from our inner cities, our hospitals, our libraries, and our schools. Making payment to Public Key Partners a function of individual and corporate fees could easily lead to a windfall for the current patent holders. We feel this is perfectly appropriate: universal deployment of public key technology will benefit society to the tune of billions of dollars. It is an enabling technology and even a few hundred million dollars going to those who established the technology is not unreasonable. While many maintain that the patents should not have been granted in the first place, we feel that this issue has already been decided and we look for creative solutions that move us beyond the current impasse. The choice we face now is a simple one. The NII is a general-purpose infrastructure, a set of streets and roads for the information superhighway. If we can't make those roads safe and secure, then business will never use them. Instead, our corporations will continue to build special-purpose infrastructures, dedicated networks for one community or another. The cost to society is orders of magnitude higher: a general-purpose infrastructure is what allows our corporations to increase their productivity and be competitive on a world market. More importantly, a general-purpose infrastructure allows new businesses to be quickly established. The information highway is crying for leadership. Our choices are policy choices, not technical ones. The Clinton/Gore administration and the current Congress have come down firmly in support of a National Information Infrastructure. Public key cryptography is an example of an area where our government can help lead us, providing the basic building blocks for an information economy. For More Information More information on the issue of public key cryptography and the Clipper issue is available from a variety of sources, including: WIRED Online Services Gopher: gopher.wired.com E-mail: infobot(a)wired.com ("send clipper/index" in the body) WWW: http://www.wired.com Electronic Freedom Frontier FTP: ftp.eff.org Gopher: gopher.eff.org WAIS: wais.eff.org National Institute of Standards and Technology Gopher: gopher-server.nist.gov

1 0

Re: Security through Obscurity
by Hal 17 Dec '03

17 Dec '03

From: Sergey Goldgaber <sergey(a)delbruck.pharm.sunysb.edu> > > To sum up, obscurity is not bad. What is bad is to confuse obscurity > > with security. > > If I have understood you correctly, there is nothing wrong with equating > obscurity with a practical, albeit temporary, increase in security. > Equating obscurity with ultimate security is a mistake. As is equating a > "strong" algorithm with ultimate security. I would not put it like this. Rather, if you want a temporary increase in security, you need to calculate, or at least assume, how much extra time it will take for your opponent to defeat your temporarily-secret information. Just saying, "oh, well this complication ought to slow him down some, heh hey," doesn't cut it. Again, you need to be explicit about exactly what information you are keeping temporarily secret, and how long you expect it to be kept secret. > > In encryption, the opponent's desire is to find out the original message. > > What is the opponent's desire in steganography? I feel it is to be able > > to prove or determine with some degree of certaintly that there is a > > hidden message. We use steganography in a context where sending such a > > message openly is for some reason undesirable. Hence our goal is to > > prevent the opponent from knowing that a message exists. > > I would like to propose that there is a goal, in addition to those you have > revealed, for the opponent as well as the legitimate user of steganography. > The opponent would, ideally, wish to not only determine that there is a > message within the data; in addition, he would prefer to be able to extract > that message for analysis. Therefore, I believe that it would be to the > advantage of the stego-user to not only hide the existence of his message, > but to do so in such a way that the cost of successfully extracting that > message, by his opponent, is maximized. > I think this is a plausible, although less ambitious, goal. But what's this about "maximizing cost"? Where does that fit into the analysis? This does not tell you whether your "maximization" has actually helped or not. Instead, if you are going to adopt this goal, this means that the test of your steganography is whether the opponent can extract the message. It's not that your goal is to "maximize his difficulty". It's that your goal is to stop him. Again, NoStO emphasizes clear statements of your goals and costs. (The reason I say this is less ambitious is that if the opponent can determine there is a message, but not what it is, they may be able to bring penalties to bear on those communicating, depending on the circum- stances. For example, finding a stego'd file on someone's hard disk might represent probable cause that illegal encryption was used, in some hypothetical future.) > I have to take exception with the assertions made in this paragraph. > Using the principles of public-key systems, the steganography key itself > does not have to be kept secret. The sender, reciever, and indeed the > opponent would all have access to this key without compromising the > security of the system. The challenge, for the opponent, lies in figuring > out which public-key the sender has used. I have no statistics on > exactly how difficult this challenge would prove; but, considering the > number of public-keys currently availiable and projecting several years > into the future, the challenge may be a very significant one. What key are you talking about here? The public one? That is not secret. As you say, the opponent has access to it. Are you assuming that the opponent cannot guess which public key was used? How will you measure the accuracy of this assumption without statistics? I really don't think you have understood my essay. The point, again, of avoiding StO is to make it clear what you are keeping secret, and to count the costs of keeping it secret. If you are counting on keeping secret the recipient of the message then you have these costs: Any stego files found in the recipient's possession are broken. Stego files can be exhaustively searched against a list of public keys. If a particular group or person is targeted for surveillance his keys can be used against all widely-known stego channels. Further, your own test is so weak (inability to recover the actual message) you have not attempted to make it impossible to guess when you have recovered the message, even with the correct key information. So in each of the cases above the authorities know when they have the message in hand. Now if you are tempted to say that this isn't true, because we could arrange for the message ALSO to be unrecognizable even when successfully recovered (so that the opponents don't know when they have recovered it) then you have missed the whole point. You earlier rejected this test. If you had accepted it, you wouldn't have needed your keys at all. Hal

2 1

Re: How to do encrypted telnet without being root (tutorial, includes src)
by Jef Poskanzer 17 Dec '03

17 Dec '03

That's quite interesting, but it sure looks like it's unable to encrypt the only part of the session that I really want to encrypt: the password. --- Jef

1 0

Mail server for crypto files on csn.org?
by exabyte!smtplink!mikej＠uunet.UU.NET 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Problem: the time-varying directory name changes too fast for reliable mail server access to the crypto software on csn.org:/mpj/ for those who don't have live ftp access, but are legally qualified to get that software under the ITAR. It IS possible, but you have to get README.MPJ then request the software right away (before I log in to csn.org to check my mail the next time -- usually one to three times a day whenever I feel like it). Proposed solution #1: change the ITAR. Unfortunately, I can't do this unilaterally. Write your Congressional Representative about changing the ITAR. Proposed solution #2: set up a "secure" mail server on csn.org itself. My idea is to have a filter program scan incoming mail for requests for crypto programs. The request would have to contain a statement that the requestor won't break the law, as well as the names of the files requested. If the mail scanning program is able to detect a valid destination for crypto software, it could then mail uuencoded or radix-64 encoded copies of the software requested in the message. Here is where I confess some ignorance and ask for help: How do I do this? Could someone send me source code for any automatic mail handling programs they have written for a Sun host, or perhaps point me at some good documentation? I could probably muddle through this in time, but I'm not to proud to accept a head start. ___________________________________________________________ |\ /| | | | | \/ |o| | Michael Paul Johnson Colorado Catacombs BBS 303-938-9654 | | | | / _ | mpj(a)csn.org ftp csn.org \mpj\README.MPJ for access info.| | |||/ /_\ | aka mpjohnso(a)nyx.cs.du.edu mikej(a)exabyte.com | | |||\ ( | m.p.johnson(a)ieee.org CIS 71331,2332 VPGP key by finger | | ||| \ \_/ |___________________________________________________________| -----BEGIN PGP SIGNATURE----- Version: 2.4 iQCVAgUBLXYgQj9nBjyFM+vFAQFccQQAo/zjyDzpsH0Ik1pGI6D+0ST8M7I84TYe /O9rqZRc4HpX5N4htPML9dm6+RrJoNzm9vXvxqhdptAB1nxzkRJgnVpTtH9nhFAM 6hX5k52H2t4Htq5diuAtk31CQG8t0GzA7iJ1qVhqwMG/pgoddRoX+cyVd5rdzX9j TN5+NZYugbU= =nSyZ -----END PGP SIGNATURE-----

2 1

Re: Standard for Stenography?
by Jef Poskanzer 17 Dec '03

17 Dec '03

Eli makes a reasonable case for leaving out the length field altogether. The desteg program would produce a file of width*height bits, and it would be up to the next layer to produce text from that. However, I'm not sure it's a *compelling* case. If adding the length doesn't actually hurt security, I'm inclined to keep it. >Tangentially, why choose bit permutation for your second-level >encryption? There are plenty of schemes that will be a lot faster >than doing all that bitmangling. Slowness is not necessarily bad - it also makes it harder for attackers to search through large numbers of images for ones with hidden data. But the main thing that the permutation gives you is that it spreads out the data bits among unmodified bits, making statistical tests harder. For a 1000 byte message in a 640x480 image, only 2% of the bits will be changed. If that 2% was all jammed into the first 80000 pixels of the file, it might be detectable; if it's spread evenly throughout the file, it's probably safer. --- Jef

2 1

CA meeting
by mdbomber＠w6yx.stanford.edu 17 Dec '03

17 Dec '03

Is the CA Cypherpunks meeting on Saturday, 12 March? I want to try to go to it. Internet: mdbomber(a)w6yx.stanford.edu Matt Bartley GPS: 33 49' xx'' 117 48' xx'' (xx due to SA :-)

1 0

UK cypherpunks ready to meet at 2000 or 2200 on 12 March?
by russw＠netcom.com 17 Dec '03

17 Dec '03

To the UK participants on the cypherpunks list, and particularly those in the southeast (London, Kent, Essex, etc): Are any of you interested in holding a meeting synchronous with the physical/teleconference meeting of 12 March in Mountain View, CA and other US locations? Regardless of the technical arrangements, I can guarantee a venue that day in London for you. If you decide to go the way of a brief telephone call-in from London, I will pay for the call. If interested, let me know immediately, and I'll make calls to those nearby who are not on the list, but who are interested and sympathetic. Cheers, Russell Russell Earl Whitaker russw(a)netcom.com Director, Extropy Institute 408-366-5435 ================================================================

1 0

CFP roomshare...
by W Lee Nussbaum 17 Dec '03

17 Dec '03

I know this is not quite appropriate to this list, but here goes: Is anyone going to Computers, Freedom, & Privacy 4 in Chicago later this month, and interested in splitting a room to keep costs down? Please mail me at wln(a)tla.org if you are interested. Thanks. - Lee

1 0

Re: Standard for Stenography?
by Jef Poskanzer 17 Dec '03

17 Dec '03

> Firstly, congratulations for Sergey Goldgaber's stubborn pushing of >this topic, for Bill Stewart's observation: "simple stego-programs, >stealthy encryption programs" I disagree with pretty much everything in your message, and since I'm the one who opened the topic and who is writing the code, my opinion would seem to count for quite a bit more than yours. I'm not going to repeat the reasons why the kind of standard you propose is a bad idea, you can fetch the messages as easily as I can. Cc:ed to the list only so that no one thinks Gary's proposal was accepted. The permutation idea remains the best. By the way, this discussion is an example of something I have labelled the "silence is invisible" phenomenon. It goes like this: there's a discussion; some of the participants work out an answer, and as far as they're concerned the discussion is over. However, other participants don't understand the answer, and keep on talking. In a physical meeting, the talkers would notice the annoyed looks on the faces of everyone else; or if the meeting had a good facilitator, he or she would catch on to the misunderstanding and correct it; but in cyberspace, those feedback mechanisms don't happen. --- Jef

4 5

spooks
by fhalper＠pilot.njin.net 17 Dec '03

17 Dec '03

If there are any spooks on this list aren't they required by law to say that they are if somoeon asked if anyone on on th list was employed by CIA, DOD, FBI or NSA? Reuben Halper

3 2