Ciphers Used with SSL in Different Cryptographic Algorithms for Internet Security

February 12, 2019

The SSL protocol supports the use of a variety of different cryptographic algorithms, or ciphers, for use in operations such as authenticating the server and client to each other, transmitting certificates, and establishing session keys.

Clients and servers may support different cipher suites, or sets of ciphers, depending on factors such as the version of SSL they support, company policies regarding acceptable encryption strength, and government restrictions on export of SSL-enabled software.

Among its other functions, the SSL handshake protocol determines how the server and client negotiate which cipher suites they will use to authenticate each other, to transmit certificates, and to establish session keys.

The cipher suite descriptions that follow refer to these algorithms:

  • DES. Data Encryption Standard, an encryption algorithm used by the U.S. Government.
  • DSA. Digital Signature Algorithm, part of the digital authentication standard used by the U.S. Government.
  • KEA. Key Exchange Algorithm, an algorithm used for key exchange by the U.S. Government.
  • MD5. Message Digest algorithm developed by Rivest.
  • RC2 and RC4. Rivest encryption ciphers developed for RSA Data Security.
  • RSA. A public-key algorithm for both encryption and authentication. Developed by Rivest, Shamir, and Adleman.
  • RSA key exchange. A key-exchange algorithm for SSL based on the RSA algorithm.
  • SHA-1. Secure Hash Algorithm, a hash function used by the U.S. Government.
  • SKIPJACK. A classified symmetric-key algorithm implemented in FORTEZZA-compliant hardware used by the U.S. Government. (For more information, see FORTEZZA Cipher Suites.)
  • Triple-DES. DES applied three times.

Key-exchange algorithms like KEA and RSA key exchange govern the way in which the server and client determine the symmetric keys they will both use during an SSL session.

The most commonly used SSL cipher suites use RSA key exchange. The SSL 2.0 and SSL 3.0 protocols support overlapping sets of cipher suites. Administrators can enable or disable any of the supported cipher suites for both clients and servers.

When a particular client and server exchange information during the SSL handshake, they identify the strongest enabled cipher suites they have in common and use those for the SSL session. Decisions about which cipher suites a particular organization decides to enable depend on trade-offs among the sensitivity of the data involved, the speed of the cipher, and the applicability of export rules.

Some organizations may want to disable the weaker ciphers to prevent SSL connections with weaker encryption.

However,

due to U.S. government restrictions on products that support anything stronger than 40-bit encryption, disabling support for all 40-bit ciphers effectively restricts access to network browsers that are available only in the United States (unless the server involved has a special Global Server ID that permits the international client to “step up” to stronger encryption).

For more information about U.S. export restrictions,

see Export Restrictions on International Sales. To serve the largest possible range of users, it’s administrators may wish to enable as broad a range of SSL cipher suites as possible. That way, when a domestic client or server is dealing with another domestic server or client, respectively, it will negotiate the use of the strongest ciphers available.

And when an domestic client or server is dealing with an international server or client, it will negotiate the use of those ciphers that are permitted under U.S. export regulations. However, since 40-bit ciphers can be broken relatively quickly, administrators who are concerned about eavesdropping and whose user communities can legally use stronger ciphers should disable the 40-bit ciphers.

Cipher Suites with RSA Key Exchange

Table 1 lists the cipher suites supported by SSL that use the RSA key-exchange algorithm. Unless otherwise indicated, all ciphers listed in the table are supported by both SSL 2.0 and SSL 3.0. Cipher suites are listed from strongest to weakest; for more information about the way encryption strength is measured, see Key Length and Encryption Strength.

Table 1 Cipher suites supported by the SSL protocol that use the RSA key-exchange algorithm

Strength category and recommended use

Cipher suites

Strongest cipher suite. Permitted for deployments within the United States only. This cipher suite is appropriate for banks and other institutions that handle highly sensitive data. Triple DES, which supports 168-bit encryption, with SHA-1 message authentication. Triple DES is the strongest cipher supported by SSL, but it is not as fast as RC4. The Triple DES uses a key three times as long as the key for standard DES. Because the key size is so large, there are more possible keys than for any other cipher–approximately 3.7 * 1050.

Both SSL 2.0 and SSL 3.0 support this cipher suite.

Strong cipher suites. Permitted for deployments within the United States only. These cipher suites support encryption that is strong enough for most business or government needs.

RC4 with 128-bit encryption and MD5 message authentication.

Because the RC4 and RC2 ciphers have 128-bit encryption, they are the second strongest next to Triple DES (Data Encryption Standard), with 168-bit encryption. RC4 and RC2 128-bit encryption permits approximately 3.4 * 1038 possible keys, making them very difficult to crack. RC4 ciphers are the fastest of the supported ciphers.

Both SSL 2.0 and SSL 3.0 support this cipher suite.

RC2 with 128-bit encryption and MD5 message authentication. Because the RC4 and RC2 ciphers have 128-bit encryption, they are the second strongest next to Triple DES (Data Encryption Standard), with 168-bit encryption. RC4 and RC2 128-bit encryption permits approximately 3.4 * 1038 possible keys, making them very difficult to crack. RC2 ciphers are slower than RC4 ciphers.

This cipher suite is supported by SSL 2.0 but not by SSL 3.0.

DES, which supports 56-bit encryption, with SHA-1 message authentication.

DES is stronger than 40-bit encryption, but not as strong as 128-bit encryption. The DES 56-bit encryption permits approximately 7.2 * 1016 possible keys.

Both SSL 2.0 and SSL 3.0 support this cipher suite, except that SSL 2.0 uses MD5 rather than SHA-1 for message authentication.

Exportable cipher suites. These cipher suites are not as strong as those listed above, but may be exported to most countries (note that France permits them for SSL but not for S/MIME). They provide the strongest encryption available for exportable products.1

RC4 with 40-bit encryption and MD5 message authentication. RC4 40-bit encryption permits approximately 1.1 * 1012 (a trillion) possible keys. The RC4 ciphers are the fastest of the supported ciphers.

Both SSL 2.0 and SSL 3.0 support this cipher.

RC2 with 40-bit encryption and MD5 message authentication.

RC2 40-bit encryption permits approximately 1.1 * 1012 (a trillion) possible keys. The RC2 ciphers are slower than the RC4 ciphers.

Both SSL 2.0 and SSL 3.0 support this cipher.

Weakest cipher suite. This cipher suite provides authentication and tamper detection but no encryption. Server administrators must be careful about enabling it, however, because data sent using this cipher suite is not encrypted and may be accessed by eavesdroppers. No encryption, MD5 message authentication only. This cipher suite uses MD5 message authentication to detect tampering. It is typically supported in case a client and server have none of the other ciphers in common.

This cipher suite is supported by SSL 3.0 but not by SSL 2.0.

1 Note that for RC4 and RC2 ciphers, the phrase “40-bit encryption” means the keys are still 128 bits long, but only 40 bits have cryptographic significance.

FORTEZZA Cipher Suites

Table 2 lists additional cipher suites supported by Netscape products with FORTEZZA for SSL 3.0. FORTEZZA is an encryption system use by U.S. government agencies to manage sensitive but unclassified information. It provides a hardware implementation of two classified ciphers developed by the federal government: FORTEZZA KEA and SKIPJACK. FORTEZZA ciphers for SSL use the Key Exchange Algorithm (KEA) instead of the RSA key-exchange algorithm mentioned in the preceding section, and use FORTEZZA cards and DSA for client authentication.

Table 2 FORTEZZA cipher suites supported by Netscape products with FORTEZZA for SSL 3.0

Strength category and recommended use Cipher suites

Strong FORTEZZA cipher suites.

Permitted for deployments within the United States only. These cipher suites support encryption that is strong enough for most business or government needs.

RC4 with 128-bit encryption and SHA-1 message authentication.

Like RC4 with 128-bit encryption and MD5 message authentication, this cipher is one of the second strongest ciphers after Triple DES. It permits approximately 3.4 * 1038 possible keys, making it very difficult to crack.

This cipher suite is supported by SSL 3.0 but not by SSL 2.0.

RC4 with SKIPJACK 80-bit encryption and SHA-1 message authentication. The SKIPJACK cipher is a classify symmetric-key cryptographic algorithm implement in FORTEZZA-compliant hardware. Some SKIPJACK implementations support key escrow using the Law Enforcement Access Field (LEAF). The most recent implementations do not.

This cipher suite is supported by SSL 3.0 but not by SSL 2.0.

Weakest FORTEZZA cipher suite.

This cipher suite provides authentication and tamper detection but no encryption. Server administrators must be careful about enabling it, however, because data sending using this cipher suite is not encrypting and may be accessed by eavesdroppers.

No encryption, SHA-1 message authentication only.

This cipher uses SHA-1 message authentication to detect tampering.

This cipher suite  supports by SSL 3.0 but not by SSL 2.0.