When to Use Public Key Cryptography

184

Chapter 8. Public Key Algorithms

In the previous chapters, we discussed almost all of the algorithms used by the SSL protocol that make it secure. The one remaining class of algorithms is public key cryptography, which is an essential element of protocols like SSL, SMIME, and PGP. Depending on the algorithm employed, public key cryptography is useful for key agreement, digital signing, and encryption. Three commonly used public key algorithms are supported by OpenSSL: Diffie-Hellman DH, DSA Digital Signature Algorithm, and RSA so named for its inventors, Rivest, Shamir, and Adleman. Its important to realize that these algorithms are not interchangeable. Diffie-Hellman is useful for key agreement, but cannot be used for digital signatures or encryption. DSA is useful for digital signatures, but is incapable of providing key agreement or encryption services. RSA can be used for key agreement, digital signing, and encryption. Public key cryptography is expensive. Its strength is in the size of its keys, which are usually very large numbers. As a result, operations involving public key cryptography are slow. Most often, it is used in combination with other cryptographic algorithms such as message digests and symmetric ciphers. Knowing when to use public key cryptography and how to combine it securely with other cryptographic algorithms is important. Well begin with a discussion of when it is appropriate to use public key cryptography, and when it isnt. Well continue our discussion of public key cryptography by introducing each of the three algorithms supported by OpenSSL. For each one, well discuss what they can and cannot do, as well as provide some examples of how to access their functionality at a low level. In addition, well discuss how they can be used together to compliment each other. Finally, well revisit our discussion of the EVP interface from Chapters 6 and 7, demonstrating how the interface can also be used with public key algorithms, which should be the preferred method, as long as it suits your needs.

8.1 When to Use Public Key Cryptography

Suppose that we want to create a secure communications system in which a group of people can send messages to one another. Using symmetric encryption, such a system can be easily devised. Everyone in the group agrees on a key to use when encrypting messages to each other. While this system provides data secrecy by limiting access to the messages to only those people in the group, it also has some serious drawbacks. For example, Alice cannot send a message to Bob without Charlie also being able to read it. Additionally, Charlie could forge a message so that it appears to have come from someone else in the group—or even worse, he could change a message that someone else sent. In order to stop the threat of forgery or message corruption, we need to have some way to authenticate and verify the integrity of messages. At the same time, we need to provide for more granularity in encryption to allow private messages between individuals in the group. With symmetric encryption, these goals can be met by having each of our users share a unique key with each of the other users. With three members of the group, Alice, Bob, and Charlie, this would mean Alice has an Alice-Bob key and an Alice-Charlie key. When she receives a message from either Bob or Charlie, she decrypts it with the appropriate key, and if she recovers a message, she has authenticated the sender. Charlie is no longer able to forge or change a message from Alice to Bob because he does not have the Alice-Bob key. 185 While alleviating the original problems, weve managed to create new ones. The biggest problem is that this new system does not scale very well. If Dave is introduced into the group, he would need to agree on different keys to use with Alice, Bob, and Charlie. Every time that a new person joins the group, n-1 keys need to be created, in which n is the number of people now in the group. With 100 people in the group, there would have to be 4,950 different keys Imagine, then, what would happen if Bobs computer was broken into and all of his keys were compromised. New keys would now have to be created for Bob to communicate with everyone else in the group. Finally, this system does not provide non-repudiation. Non-repudiation prevents either party involved in a communication from denying involvement in that communication. For example, Alice could receive a message from Bob encrypted with the Alice-Bob key, but Bob can credibly deny ever sending it by claiming Alice fabricated the message and encrypted it herself; non-repudiation guarantees that this is not possible. The use of public key cryptography solves each of these problems, but it does not do so all by itself. It must be combined properly with message digests and symmetric encryption. Not only does public key cryptography tend to scale well, it also allows us to negotiate keys online, authenticate communications, maintain data integrity, and provide non-repudiation. Whenever any of these things is one of your goals, you should turn to public key cryptography for a solution. Public key cryptography is not a magical solution to all things cryptographic. It can often be better and clearer not to use public key algorithms. As an example, in Chapter 7 , we discussed storing data in a cookie. We used a symmetric cipher to encrypt the data and a MAC to maintain its integrity. It was not our intention to share the information with anyone, but only to protect it from prying eyes and tampering. In such a situation, the algorithms that we used were the right tools for the job. By themselves, they were able to do what was required. Had we used public key cryptography, we still would have required the use of a symmetric cipher and a message digest, in addition to requiring a private and public key. Using public key cryptography would have only introduced an unnecessary layer of complexity and required significantly more processing power from the server. Because public key cryptography also depends on other cryptographic algorithms to be secure, if those algorithms can be used securely without public key cryptography, then you shouldnt be using public key cryptography. It may seem as though were stating the obvious. All too often, inexperienced programmers tend to treat public key cryptography as though it was the one and only solution to all of their cryptographic needs. The fact of the matter is public key cryptography is frequently over-kill for most situations. Its all about choosing the right tool for the job.

8.2 Diffie-Hellman