17.1 Cryptographic Keys Explained

When you use cryptography, you simplify problems by relying on your ability to manage secret keys correctly; in essence, you exchange one problem (the need to communicate securely) for another (protecting the key), which you expect to be simpler. For example, when you use data encryption to keep messages confidential, you must protect your secret or private key, which should, in principle, be simpler than arranging to meet in person or using a secure courier service. You can simplify the problem of authentication by using digital signatures, but these are useful only as long as you are able to protect a private key; Bob can trust signatures from Alice for as long as it takes Eve to guess or otherwise acquire the private key.

The importance of managing your keys cannot be overstated; Alice and Bob must manage theirs carefully to protect encoded messages. Eve could undermine all of their efforts if she acquires the keys. We use the word "acquire," because as we discussed in Chapter 12, Eve can do more than simply guessing the value of the key—Eve may try to steal the key, or attempt to deceive Alice or Bob into revealing their keys to her.

17.1.1 Understanding Key Complexity

You want to create keys that provide suitable protection against attack and yet are easy to use. Choosing a key that provides suitable protection means assessing the amount of time that the confidential data should remain secure and selecting a key length that would take at least this amount of time to find using brute force; we touched on how key lengths affect security in Chapter 14 and Chapter 15. In general, the longer the key, the longer it takes to check all of the possible key values and the more secure it is.

It might seem as though the best approach is for Alice and Bob to create keys that are as long as possible, to provide the greatest level of security. The problem is that they must remember their keys, and type them in when they want to use them; the security advantages of a 2048-bit RSA key are obvious, but it is almost impossible to remember. For example, the sequence below is the private key parameter D for a 2048-bit RSA key (Chapter 15 contains full details of the RSA algorithm):

56 90 E2 5B F7 FA CB 85 0C CA F5 3B 0A 25 DC 07 F2 8D 32 4F 0D 4B EB 87 4C D1 E9
90 30 09 74 40 9B BE FA B3 CB C9 C1 5D C9 9D F9 B4 34 6F 27 CA 32 A0 0B FF 84 58 
E9 E7 47 4C F9 E3 33 DD DA 3A CF AE 4D DA F8 DB C5 07 97 B6 42 26 84 E8 F9 07 3C 
01 E3 D3 B7 C5 60 A9 8B 85 B2 1A 93 D1 74 27 64 4C 01 74 F7 5E 58 61 B9 C9 19 33 
73 43 2D F3 0C 29 43 40 98 A4 85 15 FD 50 8C 8C 42 F1 19 01

Alice will be very frustrated if she has to remember this sequence (and the sequences for the other key parameters) and type it correctly before she can decrypt data or sign a document; the chances of her being able to correctly do this are slim. Alice will do what all users do when faced with this kind of memory problem—she will write down the password. Alice has now changed the nature of her security; the length of time it takes Eve to acquire the key is affected by how hard it is to steal Alice's notepad.

By asking Alice to do the impossible, we have changed the nature of her cryptographic security. As soon as Alice writes down the key, we are dealing with a physical security problem. Even if Alice works in a "secure" building, Eve knows that it is easier to break into Alice's building and read her notes than it is to test every possible key value. We can make life easier for Alice and Bob by using very small key values, but while we reduce the chance of having the keys written down, we significantly increase the efficacy of brute force attacks.

We also need to consider the type of data that we use to create keys. The most secure way to create a key is to use a random data generator, which makes it harder for Eve to brute force the key value, because all key values are equally likely. The problem with random data is that it results in a sequence that is difficult to remember—people are not naturally able to remember an otherwise meaningless sequence of digits. Alice and Bob will start writing down their keys again if we ask them to use randomly generated keys.

If we ask Alice and Bob to select their own keys, we will find that they tend to pick words or phrases that have a personal significance. For example, Bob might use the name of his favorite sports team, the name of his cat, or his wife's birthday. The concern is that Eve will be able to acquire the key quickly by testing only key values derived from Bob's background and preferences. There are only a limited number of sports teams, and it does not take long to test them all.

The tension between the needs of the user and the needs to attain a certain level of security is one of the fundamental challenges you will face when designing systems that use cryptography. There is no simple answer to this problem, and the most common mistake we have seen is where software forces users to work with long and random keys, and the employer addresses this by making writing down keys a punishable offense. Users are incapable of remembering long data sequences, and outlawing the natural solution just forces users to write the keys down in secret.

One potential solution is to generate a sequence of words to create a key that is a nonsensical phrase on the basis that users will find this type of key easier to remember—for example, "Blue Jazz Fish Happy Green Walking Light Special." Though people can remember this kind of phrase, they can only do so for a short period and still end up writing down the phrase in the long term. Another problem is that we have made it easier to brute force the key by restricting the key to a set of English words; Eve can use a dictionary to test combinations of words and do so relatively quickly.

The most common technique is to rely on a shorter key to protect a long cryptographic key—for example, rely on a Windows log-on password to protect an RSA key. This approach has an obvious appeal, because the user has to remember only one thing, based on the assumption that it is harder to attack the user's computer than it is to guess the key, presumably because the computer, the network, and every other device connected to the network are completely secure. A quick glance through most IT security bulletins demonstrates why this is not a reasonable assumption to make.

17.1.2 Exchanging Symmetric Algorithm Keys

In Chapter 14, we explained that agreeing on a key for a symmetrical algorithm was problematic—Alice and Bob need to meet in a secure location, where they can be sure that Eve cannot eavesdrop on their conversation. As an alternative, Alice and Bob can use a trusted and secure courier service to send keys to one another. Both of these approaches present Eve with an attractive line of attack—breaking the security of the "secure" location or bribing one of the "trusted" couriers could be easier than brute forcing the keys. Worse still, Alice and Bob should change their key regularly (as discussed in Chapter 14), presenting Eve with further opportunities.

In this section, we explain how Alice and Bob can use asymmetric algorithms to perform symmetric key exchange, and exchange the problem of agreeing on symmetric keys for the simpler problem of using asymmetric keys. Figure 17-1 illustrates the basic protocol for key exchange, which works as follows:

Figure 17-1. Exchanging symmetric keys using asymmetric encryption

At the end of this process, Alice and Bob have decided on a new symmetric secret key without the difficulty of arranging a secure meeting. Eve may intercept the key exchange messages between Alice and Bob, but she cannot decrypt the secret key value without Bob's asymmetric secret key. In essence, Alice and Bob have simplified their key agreement problem by relying on the security of Bob's asymmetric key pair, and so another aspect of cryptography becomes an issue of key security.

Using the described key exchange protocol, the exchange of symmetric keys becomes a simple and secure process. To improve security further, there is no reason why Alice and Bob should not create new keys every time that they need to exchange confidential data; such keys are called session keys.

Alice and Bob could have encrypted all of their confidential data using an asymmetric encryption algorithm, but such algorithms process data very slowly compared to symmetric algorithms. This kind of key exchange makes the best use of both kinds of algorithm—symmetrical algorithms are fast and asymmetric algorithms are ideally suited to encrypting the small secret key values. Key exchange is also suitable for "impromptu" encryption, where someone who Bob has no prior relationship with wishes to send him confidential data. Figure 17-2 illustrates this technique, which we summarize as follows:

Figure 17-2. Anonymous encryption using key exchange techniques

Impromptu encryption allows Eugene to send confidential data to Bob that can be decrypted using Bob's secret key only, even though a symmetric algorithm has been used to encrypt the message data. Not only does this technique require no arrangement between Bob and Eugene, it also does not need Eugene to identify himself, allowing the impromptu encryption to be used anonymously.

Bob reads the message sent to him by Eugene by following this protocol: