Proposals for email encryption arose in the 1980s, often taking advantage of innovations in public-key cryptography. The prototype for end-to-end email encryption was the Privacy-Enhanced Mail (PEM) protocol. Although PEM supported mail encryption with shared secret keys, its important contribution was to use RSA public keys to wrap the secret key that encrypts a message (FIGURE 13.16).

Although PEM served as the model for internet email encryption, it was never widely used itself. The design posed challenges that discouraged its deployment. One problem was that PEM was designed around a single, centralized certification hierarchy. Every PEM email user had to have a public-key certificate issued by a PEM-approved certificate authority. Moreover, there were expenses both in issuing certificates and in licensing of RSA patent rights. RSA Data Security, the company holding the patent rights, offered to issue a certificate and license the patent to any PEM user in exchange for a $25 fee. This went counter to the prevailing customs of the internet community, at a time where most internet software was free.

PGP became a de facto standard for email encryption and, in fact, for desktop encryption in general. The original software was distributed free, including its source code. Instead of relying on a hierarchical certification authority, it used the “web of trust” to provide confidence in certificate authenticity. Both the web of trust and certification hierarchies were introduced in Section 8.6.2.

Aside from PGP, there are several commercial email products that also provide encryption. Lotus Notes, the desktop email and information management product, provides email encryption and integrity protection based on RSA. Notes was, in fact, the first product to license the RSA algorithm in the 1980s. Microsoft’s Outlook Exchange email also can encrypt and sign messages.

Secure Multipurpose Internet Message Extensions (S/MIME) is an extension to existing internet email protocols that adds cryptographic protection. Both PGP and S/MIME provide open standards for email security. In addition to free and licensed products from the PGP Corporation, there are other products that implement PGP-style email, notably the Gnu Privacy Guard (GPG). S/MIME is supported by many mailers, including Mozilla’s Thunderbird.

Today, the most widely used end-to-end encryption systems reside on smartphones. Apple provides end-to-end encryption on all video calls and text messages between its iOS devices. Google and Facebook also provide end-to-end encrypted messaging services. There are also messaging apps that provide end-to-end encryption, notably WhatsApp and Signal. Smartphone encryption relies on built-in smartphone security features to safely automate the key-management process.

Despite the widespread availability of email encryption software—both for free and from vendors—the overwhelming majority of email users can’t read encrypted email or verify signatures on messages they receive. Many people are resigned to the fact that they can’t transmit critical messages via email. Aside from technical experts, few people take the trouble to install secure email software and assign themselves a public-key pair.

Organizations that transmit a number of sensitive messages (like health institutions subject to HIPAA regulations) use email applications with built-in cryptographic services. The enterprise’s IT department handles software distribution and key management.

When we limit ourselves to secret-key cryptography, our secure network communications must rely on preshared secrets. We clearly need secure communications if we are to transact business over the internet. The notorious internet security incidents of the late 1980s highlighted the risks to internet traffic. Because the CERT started to track security incidents at that time, subsequent incidents just underscored internet risks. In 1994, a CERT advisory on password sniffing led the national television news programs to warn “everyone” to change their internet passwords. Attackers had installed password sniffing software in major internet service providers.

Netscape Software

In 1994, Mosaic’s developers joined a private company named Netscape Communications to develop a secure browser and web server. The Netscape Commerce Server provided companies with a way to sell products on the internet and safely collect credit card numbers. The browser, called Netscape Navigator (FIGURE 13.17), used SSL to establish a secure connection across the internet.

Netscape provided the RSA patent holders with 1 percent of the company in exchange for the rights to use RSA in the browser. In 1995, Netscape first offered its stock for sale, and the small company’s value quickly rose to more than $200 million. Netscape set the stage for overnight stock market success by many internet companies over the next several years.

The SSL handshake protocol uses public keys to establish a shared secret. First, the client and the server exchange randomly generated nonces. Next, they exchange temporary Diffie–Hellman public keys. They use the keys to generate a common “pre-master secret” and combine it with the nonces to produce the shared master secret. Alice uses the bank’s public-key certificate to authenticate the bank’s server and the messages it sends.

In FIGURE 13.18, Alice contacts “the Bank” to transfer some funds. To establish their SSL session, both Alice’s client and the Bank’s server generate and exchange nonces and Diffie–Hellman keys. Then they generate a shared master secret and use it to create working keys to protect their connection.

Originally, the SSL handshake relied entirely on RSA encryption, and this approach is still widely used. The bank’s server omits the “Key from Server” message entirely. The client generates the pre-master secret and wraps it with the bank’s public key. The “Key from Client” message transmits the wrapped pre-master secret to the server. The RSA approach requires less computation, but it sacrifices perfect forward secrecy. (See Section 8.3.1.)

The client and server also use the handshake to select the cryptographic algorithms. The server provides a list of the algorithms it supports for establishing the crypto keys (typically RSA, Diffie–Hellman, or elliptic curve Diffie–Hellman), the encryption algorithms (typically AES), and the integrity mechanisms, which may be integrated into block cipher modes.

Once both hosts have retrieved both nonces and the pre-master secret, they each hash the data to construct secret keys to use. The actual process uses a string of predefined data that is combined with the exchanged variables (FIGURE 13.19). The hash is repeated several times to produce a large key block of random data. SSL subdivides the block into separate pieces of random data for every purpose the crypto functions require.

These may include keys and data for the following six purposes:

1. Encrypt output from the client

2. Encrypt output from the server

3. Keyed hash of output from the client

4. Keyed hash of output from the server

5. IV (initialization vector) for output from the client, if the mode requires it

6. IV for output from the server, if the mode requires it

When SSL was developed originally, the designers didn’t appreciate the risk of reusing a cipher’s key stream. They used the shared secret itself as the encryption key for traffic in both directions. When the developers realized the mistake, they decided it wasn’t significantly more difficult to construct separate keys for encryption and integrity protection in each direction. Although it’s not essential to use separate keys for protecting the integrity of a keyed hash, it is often the safest course to take.

All SSL packets follow a standard format, shown in FIGURE 13.20. The layout in the figure shows the arrangement for sending encrypted data protected by a block cipher. The first three fields appear in all SSL packets; the “content type” field indicates whether the packet carries data, an alert message, or is negotiating the encryption key.

The crypto-specific fields provide the information needed to decrypt and verify the packet’s data. The first crypto parameter, the IV, is of course used with a block cipher mode. The last parameters, “padding” and “PL,” provide padding so that the encrypted data matches the block length. The PL field indicates the padding length.

SSL rarely achieves true application transparency because it is usually bundled with the client or server software. However, because the protocol fits almost exactly at the network API, it isn’t hard to keep the protocol separated from the application. Some vendors even provide external hardware to perform much of the SSL processing before it arrives at the server.

However, SSL illustrates a problem with application transparency: The end user doesn’t always know whether or not the traffic is really protected. With email, we can’t read encrypted mail unless we take steps to decrypt it; some software won’t display a signed email message unless the signature is verified.

There is a sharper separation between SSL cryptography and the applications that use it. Web browsers provide indicators, like a visible padlock or key, to show when cryptography protects a page. However, this proved tricky. The browser may need to open several connections to fill a single page, and some of the connections might not be encrypted. If that happens, should it display the padlock or not?

Modern browsers often display a warning when that happens (FIGURE 13.21). The figure shows a warning from the Firefox 3 browser. The warning indicates that although some of the page contents are cryptographically protected, other contents are not protected. Also note the lower right-hand corner of the browser window: There is a very tiny padlock superimposed with an exclamation mark (!). The padlock indicates that SSL is being used, and the exclamation mark indicates that not all of the page’s contents are cryptographically protected.

Although email encryption applications may provide end-to-end crypto to users, SSL does not. In SSL, the cryptographic relationship is between a client and server application, not between end users. SSL encryption takes place automatically. Email encryption relies on the end user to apply cryptography to a message and to validate it upon receipt.