Cryptography can be all these things, both good and bad, because encryption can serve two fundamentally different ends. In its “confidentiality” function it can be “used to keep communications secret.” In its “identification” function it can be “used to provide forgery-proof digital identities.”¹ It thus enables freedom from regulation (as it enhances confidentiality), but it can also enable regulation (as it enhances identification).²

Its traditional use is secrets. Encrypt a message, and only those with the proper key can open and read it. This type of encryption has been around as long as language itself. But until the mid-1970s it suffered from an important weakness: the same key that was used to encrypt a message was also used to decrypt it. So if you lost that key, all the messages hidden with that key were also rendered vulnerable. If a large number of messages were encrypted with the same key, losing the key compromised the whole archive of secrets protected by the key. This risk was significant. You always had to “transport” the key needed to unlock the message, and inherent in that transport was the risk that the key would be lost.

In the mid-1970s, however, a breakthrough in encryption technique was announced by two computer scientists, Whitfield Diffie and Martin Hellman.³ Rather than relying on a single key, the Diffie-Hellman system used two keys—one public, the other private. What is encrypted with one can be decrypted only with the other. Even with one key there is no way to infer the other.

A. If I want to send a message to you that I know only you will be able to read, I can take your public key and use it to encrypt that message. Then I can send that message to you knowing that only the holder of the private key (presumably you) will be able to read it. But you cannot be sure it is I who sent you the message. Because anyone can encrypt a message using your public key and then send it to you, you have no way to be certain that I was the one who sent it. Therefore, consider the next example.

B. Before I send the message I have encrypted with your public key, I can encrypt it with my private key. Then when you receive the message from me, you can first decrypt it with my public key, and then decrypt it again with your private key. After the first decryption, you can be sure that I (or the holder of my private key) was the one who sent you the message; after the second decryption, you can be sure that only you (or other holders of your private key) actually read the content of the message. But how do you know that what I say is the public key of Larry Lessig is actually the public key of Larry Lessig? How can you be sure, that is, that the public key you are using is actually the public key it purports to be? Here is where the next example comes in.

C. If there is a trustworthy third party (say, my bank, or the Federal Reserve Board, or the ACLU) with a public key (a fact I am able to verify because of the prominence of the institution), and that third party verifies that the public key of Larry Lessig is actually the public key of Larry Lessig, then along with my message sent to you, encrypted first in your public key and second in my private key, would be a certificate, issued by that institution, itself encrypted with the institution’s private key. When you receive the message, you can use the institution’s public key to decrypt the certificate; take from the certificate my public key (which you now are fairly confident is my public key); decrypt the message I sent you with the key held in the certificate (after which you are fairly confident comes from me); and then decrypt the message encrypted with your public key (which you can be fairly confident no one else has read). If we did all that, you would know that I am who I say I am and that the message was sent by me; I would know that only you read the message; and you would know that no one else read the message along the way.

I could add any number of complications (for example, how can I be certain that you are who you say you are? Clue: the same way you can be certain that I am who I say I am), and I have hidden a number of important simplifications. For example, it turns out that it is simpler not to encrypt the whole message with a dual key system but rather to encrypt only a symmetric key⁴ using a dual key system.⁵ My aim, however, is simply to outline the basic elements of this architecture: a system of dual or asymmetric encryption, and a system of trusted third parties that can certify facts about you. The world I am describing would have both of these elements automatically and seamlessly executed.

The encryption I’ve been describing is called “public key” encryption—again, because it has two keys, one public, one private, unlike traditional single key encryption. As the last step of this encryption process makes clear, the system depends on an infrastructure—not an infrastructure of special wires or protected pathways, but an infrastructure of trust, which can provide not perfect confidence but enough confidence through the multiplication of assertions about authenticity to make it certain enough that the fact certified by a particular signature is true.

An infrastructure that supports a public key system is called “PKI” (public key infrastructure).⁶ The first point to see is the potential that a well-established PKI creates. With a robust PKI, the possibilities for identification become extraordinary. Individuals could carry certificates that authenticate any number of facts about themselves—who they are; personal attributes (age, citizenship, sex, marital status, sexual orientation, HIV status); professional credentials (college degrees, bar certification, and so on). These certificates could reside on their personal computers, and when they attempted to enter an Internet site, that site would check the certificate and let them pass if they held the proper certificate. It would deny access if they did not. A world with a robust PKI would enable an unlimited range of cheap authentication, and hence an unlimited range of zoning—of conditioning access to Internet sites based on the credentials held by the user.

Footnotes

¹ Ibid. Edit Delete

² See Hal Abelson, et al., “The Risks of Key Recovery, Key Escrow, and Trusted Third-Party Encryption,” World Wide Web Journal 2 (1997): 241, 245: “Although cryptography has traditionally been associated with confidentiality, other cryptographic mechanisms, such as authentication codes and digital signatures, can assure that messages have not been tampered with or forged.” Edit Delete

³ Whitfield Diffie and Martin E. Hellman, “New Directions in Cryptography,” IEEE Transactions on Information Theory it–22 (November 1976): 644–54. The idea had apparently been discovered earlier by James Ellis at the British Government Communication Headquarters, but it was not then published; see Baker and Hurst, The Limits of Trust, xvii. Edit Delete

⁴

A symmetric key algorithm is an encryption routine that requires the same key to encrypt and decrypt a message. An asymmetric key algorithm is one that uses a different key to encrypt and decrypt.

[You don't need this footnote, because just before this on p. 36 you explained essentially what a symmetric key is and what its weakness is. Just add the term back there.--Andy Oram]

⁵ There are other issues as well; see Bruce Schneier, Applied Cryptography: Protocols, Algorithms, and Source Code in C, 2d ed. (New York: Wiley, 1996), 4–5; Conference, “The Development and Practice of Law in the Age of the Internet,” American University Law Review 46 (1996): 327. Edit Delete

⁶ For a comprehensive analysis of the legal issues surrounding PKI, see “Public Key Infrastructure Symposium,” Jurimetrics Journal 38 (1998): 241. Edit Delete