Appendix C. Cryptography

C.1. What Are You Protecting and Why?

In order to determine what you need from cryptography, you have to first know what you need to protect and what you're trying to protect it from. For instance, suppose you are attempting to keep some piece of information secret. That might be a trivial piece of information that's going to change again soon (for instance, what present you picked out for a friend's birthday next week), or it might be an important piece of information that can be turned into cash any time in the next several years (for instance, the number of the credit card you just got). It might be the press release you're going to make public next week, which commercial competitors may be actively trying to discover but will be pointless to conceal as soon as it appears in the newspaper, or it might be your government's nuclear bomb plans, which professional spies are actively trying to discover and will still destroy the world no matter when they're used.

Clearly, you're going to want different things from the algorithms you use to protect these pieces of information. If you're keeping the birthday present a secret, you want something that's fast and easy to use; you don't care much if it's easy to figure out (unless your friend is a cryptographer who hates surprises). If you're keeping a credit card number secret, you mostly care about how secure it is, but most of the time, people won't be trying to find it out. If you're keeping a press release secret from competitors, you only need to protect it until you release it; if you're keeping nuclear bomb plans secret, you need to protect them forever.

Similarly, cryptography can be used to prove your identity (this is discussed later in this appendix). You may use cryptography to prove who you are when sending a note to a friend, when approving an expensive purchase at work, or when releasing a piece of software to the world. These things require different levels of certainty, last for different amounts of time, and require different kinds of infrastructure.

If you're sending a note to a friend, the friend probably doesn't need to be all that certain who it's from; if somebody else pretends to be you, it will probably all get sorted out in the end, even if a certain amount of comedy or unpleasantness results. The friend needs to be able to verify your identity only when the message arrives. If the verification data isn't good months later, that's OK; the message is probably of purely sentimental value by then. You and the friend can set up a system between the two of you for verifying your identity; you don't need a way that will work on a large scale. Finally, all your friend needs to know is that the message is from you. Presumably, anybody you consider a friend already knows who you are and why they want to read messages from you.

If you're authorizing a purchase at work, there are legal requirements to be fulfilled. Those legal requirements demand a higher level of certainty. If somebody else pretends to be you, the company's money is at stake, and the consequences include prosecution for fraud or incompetence. The legal requirements also demand that the information be verifiable for a longer period of time; not only does somebody need to be able to verify your identity when the purchase is made, they need to be able to verify it again during a later query or audit. Practical requirements also mean that there needs to be a consistent company-wide architecture for verifying your identity. It can't be done differently for every employee, so an infrastructure of some sort is required. That infrastructure has to include not only identity data ("This is how you know it's from Ethelraeda Perkins"), but also authorization data ("This is how you know Ethelraeda Perkins is allowed to authorize purchases up to $20,000").

If you're releasing software to the Internet, things change again. If somebody pretends to be you and releases destructive software in your name, your reputation can be permanently damaged, and the consequences include things like your name ending up on the front page of newspapers worldwide. You need a high level of certainty about identities, and you need that level of certainty for a long time (one of the authors still periodically receives questions about relatively obscure software distributed over 10 years ago). This has to be provided with a worldwide infrastructure, accessible to everybody you want to distribute software to, and that infrastructure must provide enough information so that people can readily tell not only who you are, but why they trust you enough to run programs you're distributing.