The diagram below shows your basic cryptographic process. Plaintext P is encrypted with an encryption algorithm and an encryption key K. The resulting ciphertext, C, is transmitted over the network. The receiver decrypts the ciphertext with a decryption algorithm and a decryption key H. The encryption and decryption algorithms are public information. However, at least one of the keys (K and H) are private information. The keys consist of a relatively short string of bytes (e.g., 112 bits). The longer the key, the more difficult to break the cipher.
For a symmetric-key algorithm, the decryption key is the same as the encryption key, i.e., H=K in the above diagram. A popular symmetric-key algorithm is DES (Data Encryption Standard). With DES, plaintext is encrypted in blocks of 64 bits, yielding 64 bits of ciphertext. The algorithm has a 56-bit key.
With symmetric keys, in order for both Bob and Alice to have the same key, the key must be distributed from either Bob or Alice to the other. If the key is intercepted by Trudy, an intruder, then Trudy will be able to decrypt the messages sent between Bob and Alice. Public-key algorithms provide a solution to this fundamental problem. With a public-key algorithm, H and K are different, but either of the two keys can be the encryption key. Thus:
Each person has a private and public key. A popular public-key encryption algorithm in the Internet is RSA.
To illustrate how public-key encryption can work, suppose Bob wants to send an encrypted message to Alice. Bob obtains Alice's public key and encrypts the message with that key. Because any message encrypted with a public key can only be decrypted with the corresponding private key, Alice is the only person who can decrypt Bob's message.
Bob can obtain Alice's public key either by
Public-key technology can also provide digital signatures. Suppose Bob wants to send a message to Alice, and neither cares about the secrecy of the message. Alice, however, wants to be sure that the message originated from Bob and not from someone masquerading as Bob. This authentication problem is solved by having Bob encrypt the message with his private key. Alice then decrypts the message with Bob's public key. If Bob's public key successfully decrypts the message, then Alice knows that Bob sent the message (or at least that the message was encrypted with Bob's private key).
Now suppose that Bob wants to send a message to Alice, and they want both secrecy and authentication. Then Bob first encrypts the message with his private key and then encrypts the resulting message with Alice's public key:
A drawback of public-key encryption algorithms is that they are inherently slow, perhaps 100-1000 times slower than symmetric-key counterparts. For this reason, the sender does not typically encrypt an entire lengthy message with a public-key algorithm.
As an example, suppose that Bob wants to send a non-secret message to Alice along with his digital signature. He could then encrypt only his name with his private key and then attach the resulting signature to the lengthy plaintext message. This package is then sent over the network. It is not computationally expensive to generate the package because the public-key encryption algorithm is only applied to Bob's name.
The technique described in the preceding paragraph has a serious flaw: It ensures neither nonrepudiation nor message integrity. In particular, Trudy can intercept the package and replace the body in plaintext with whatever she wishes. This flaw has motivated the use of "message digests." The idea is to apply a function, called the hash funcation, to the message to obtain a message digest consisting of a relatively small number of bits:
The hash function has two important properties. First, it is impossible to recover the original message from the message digest. Second, if the hash function is applied to two different messages, then the resulting message digests are different.
To illustrate how hash functions are used, suppose that Bob wants to send a non-secret message to Alice. Alice, however, wants to be certain that Bob authored the message and that the message was not altered by an intruder. Bob first applies a publicly known hash function to his message, creating a message digest. Bob then encrypts the message digest with his private key. Bob then sends Alice the encrypted message along with the original plaintext message:
When Alice receives this package, she decrypts the encrypted part with Bob's public key and applies the hash function to the plaintext message. If the two resulting message digests are the same, then Alice knows that Bob authored the message and that the plaintext message was not altered. (If the message had been altered, then the two message digests would have not matched.).
Also observe that this process does not allow Bob to repudiate what he said in the message.
Now suppose that Bob wants to send a secret message to Alice, and he does not want to use symmetric-key technology because he is uncomfortable about sending the key over the Internet. As we mentioned earlier, Bob could solve this problem by using public-key technology. However, as also stated earlier, public-key encryption applied to a long message is computationally expensive.
Session keys can solve this problem. Specifically, Bob locally generates a symmetric key (to be used with a symmetric-key algorithm such as DES). Bob then encrypts the symmetric key with Alice's public key (using, for example, the RSA algorithm). Bob then transmits the encrypted key over the Internet. Alice decrypts the key with her private key. Now both Bob and Alice have a copy of the symmetric key, and they can be certain that no one has intercepted it. In the current context, the symmetric key is called a session key. Once Alice has received the session key, Bob can encrypt the original message with the session key and Alice can decrypt the message with the same key. It is computationally inexpensive to encrypt the message with (symmetric) session keys:
Once Alice receives the message, both Bob and Alice can destroy the session key. If they wish to communicate again at a later date, Bob can generate a new session key for the new session.
Suppose that Bob contacts Alice (in plaintext) stating that he would like to place an order for a good that Alice is selling. Bob also sends (in plaintext) his public key. Bob then sends a package consisting of a plaintext order and an encrypted message digest. As discussed earlier, Alice can then use Bob's public key to authenticate the order.
This all sounds fine until clever Trudy comes along. Suppose that Alice is in the pizza delivery business and Trudy wants to play a prank. In particular, Trudy contacts Alice, says she is Bob, gives Bob's address for delivery, and sends a public key. She then places an order, encrypting the message digest with the corresponding private key. Alice will think the message came from Bob and will process the order.
As another example, suppose that Trudy builds a fake Web site for a major department store. Trudy authenticates the fake department store by signing messages with a private key and sending her customers the corresponding public key. All messages show the stores well-known logo. When customers order merchandise from this site, Trudy takes the money but never delivers the goods.
Security technology often uses certification to combat this type of fraud. Bob (or more typically, a company) asks for a certificate from a certification authority. This certificate includes Bob's public key along with identifying information about Bob (his name, address, etc.) The certificate is encrypted with the authority's private key. Bob pays the certifying authority a fee and obtains the encrypted certificate.
When Bob places an order to Alice, he sends the certificate along with the order. Alice decrypts the certificate with the authority's public key and obtains Bob's public key. Here is an example of a certificate:
In addition to the links provided in the text, below we offer some links that we recommend visiting: