## Bulk encryption ciphers

While neither of the previous two categories are included in

TLS 1.3 cipher suites, these next two – bulk ciphers and hashing algorithms – are

included.

## Ciphers

In cryptography, a cipher (or cypher) is an algorithm for performing encryption and decryption—a series of well-defined steps that can be followed as a procedure. An alternative term is encipherment.

In non-technical usage, a “cipher” is the same thing as a “code;” however, the concepts are distinct in cryptography. In classical cryptography, ciphers were distinguished from codes. Codes operated by substituting according to a large codebook which linked a random string of characters or numbers to a word or phrase. For example, “UQJHSE” could be the code for “Proceed to the following coordinates.”

The original information is known as plaintext, and the encrypted form as ciphertext. The ciphertext message contains all the information of the plaintext message, but is not in a format readable by a human or computer without the proper mechanism to decrypt it; it should resemble random gibberish to those not intended to read it.

**The operation of a cipher usually depends on a piece of auxiliary information, called a key or, in traditional NSA parlance, a cryptovariable. The encrypting procedure is varied depending on the key, which changes the detailed operation of the algorithm.**

Most modern ciphers can be categorized in several ways:

## Crypto api cipher references and priority¶

A cipher is referenced by the caller with a string. That string has the

following semantics:

## Data integrity/authentication

**Not to be confused with server/client authentication, the hashing algorithm that has traditionally been associated with SSL/TLS has historically handled message authentication and pseudo-random functions. As we’ll discuss in just a moment, that’s been rethought for TLS 1.3, with HKMF or HMAC-based key derivation function.**

Let’s start with TLS 1.2 and the Hash-Based Message Authentication Code which has traditionally appeared as the fourth algorithm in the cipher suite.

## Deprecation of old ciphers/functionality

But the changes go well beyond just the length of the cipher

suites and the reduced number of negotiations during the handshake. Things have

also been made much more secure.

TLS 1.3 has eliminated:

**It’s also dropped support for older, vulnerable SSL ciphers like: **

- RC4
- DSA
- MD5
- SHA1
- Weak Elliptic Curves
- RSA Key Exchange
- Static Diffie-Hellman (DH, ECDH)

Because the structure of 1.3 cipher suites is different from

its predecessors’, TLS 1.3 cipher suites will not be interchangeable with older

TLS versions. That essentially means you’re going to need to have two different

implementations if you plan on continuing to support TLS 1.2. And there’s nothing

wrong with continuing to support TLS 1.2, either.

Until more companies in the hosting community make it a

point to transition to TLS 1.3, shutting off TLS 1.2 would be foolish.

**You should have already disabled TLS 1.1, TLS 1.0, SSL 3.0 and SSL 2.0 though. The PCI DSS deadline for deprecating SSL 3.0 was last Summer. The deadline for TLS 1.0 and TLS 1.1 is January 2020. **

## Diffie-hellman & elliptic curve diffie-hellman

Named after Whitfield Diffie and Martin Hellman, this is a

key exchange protocol, it’s NOT an asymmetric encryption protocol in the same

vein as RSA though. The problem that Diffie and Hellman (using work inspired by

Ralph Merkle) set out to solve was how to exchange a secure key over an

unsecure network with an attacker watching.

What they came up with was Diffie-Hellman key exchange,

which was eventually succeeded by RSA, but has now re-taken the advantage.

**Diffie-Hellman key exchange works like this: **

## Digital signature/authentication

Here’s where things start to get confusing – and you can

also begin to see how these cipher suites have multiple permutations. For

example, there are four common iterations of Diffie-Hellman:

- Diffie-Hellman (DH) *deprecated in TLS 1.3
- Diffie-Hellman Ephemeral (DHE)
- Elliptic Curve Diffie-Hellman (ECDH) *deprecated in TLS 1.3
- Elliptic Curve Diffie-Hellman Ephemeral (ECDHE)

But none of those can handle authentication, so they have to

be paired with an authentication scheme – historically, that’s been either DSA,

RSA or ECDSA.

## Elliptic curve digital signature algorithm

As we mentioned earlier, Diffie-Hellman key exchange has no

authentication mechanism in ephemeral mode. That means it needs to be paired

with an authentication mechanism. As we just covered, RSA is an option, the

other popular method is called the Elliptic Curve Digital Signature Algorithm,

which has now replaced DSA. The way ECDSA works is very similar to RSA at the

outset, but with one major difference.

## Etymology of “cipher”

“Cipher” is alternatively spelled “cypher.” This variant, however, is now uncommon and often incorrectly considered an error by native speakers. Likewise, “ciphertext” was spelled as “cyphertext,” and so forth. It also got into Middle French as cifre and Medieval Latin as cifra, from the Arabic sifr (zero).

**The word “cipher” in former times meant “zero” and had the same origin, and later was used for any decimal digit, even any number. There are several theories about how the word “cipher” may have come to mean encoding. Some of them are: **

Dr. Al-Kadi (ref-3) concluded that the Arabic word sifr, for the digit zero, developed into the European technical term for encryption.

## Internal structure of kernel crypto api¶

The kernel crypto API has an internal structure where a cipher

implementation may use many layers and indirections. This section shall

help to clarify how the kernel crypto API uses various components to

implement the complete cipher.

**The following subsections explain the internal structure based on existing cipher implementations. The first section addresses the most complex scenario where all other scenarios form a logical subset. **

### Generic AEAD Cipher Structure¶

The following ASCII art decomposes the kernel crypto API layers when

using the AEAD cipher with the automated IV generation. The shown

example is used by the IPSEC layer.

For other use cases of AEAD ciphers, the ASCII art applies as well, but

the caller may not use the AEAD cipher with a separate IV generator. In

this case, the caller must generate the IV.

The depicted example decomposes the AEAD cipher of GCM(AES) based on the

generic C implementations (gcm.c, aes-generic.c, ctr.c, ghash-generic.c,

seqiv.c). The generic implementation serves as an example showing the

complete logic of the kernel crypto API.

It is possible that some streamlined cipher implementations (like

AES-NI) provide implementations merging aspects which in the view of the

kernel crypto API cannot be decomposed into layers any more. In case of

the AES-NI implementation, the CTR mode, the GHASH implementation and

the AES cipher are all merged into one cipher implementation registered

with the kernel crypto API. In this case, the concept described by the

following ASCII art applies too. However, the decomposition of GCM into

the individual sub-components by the kernel crypto API is not done any

more.

Each block in the following ASCII art is an independent cipher instance

obtained from the kernel crypto API. Each block is accessed by the

caller or by other blocks using the API functions defined by the kernel

crypto API for the cipher implementation type.

The blocks below indicate the cipher type as well as the specific logic

implemented in the cipher.

The ASCII art picture also indicates the call structure, i.e. who calls

which component. The arrows point to the invoked block where the caller

uses the API applicable to the cipher type specified for the block.

The following call sequence is applicable when the IPSEC layer triggers

an encryption operation with the esp_output function. During

configuration, the administrator set up the use of seqiv(rfc4106(gcm(aes)))

as the cipher for ESP. The following call sequence is now depicted in

the ASCII art above:

esp_output() invokes

`crypto_aead_encrypt()`

to trigger an

encryption operation of the AEAD cipher with IV generator.The SEQIV generates the IV.

Now, SEQIV uses the AEAD API function calls to invoke the associated

AEAD cipher. In our case, during the instantiation of SEQIV, the

cipher handle for GCM is provided to SEQIV. This means that SEQIV

invokes AEAD cipher operations with the GCM cipher handle.During instantiation of the GCM handle, the CTR(AES) and GHASH

ciphers are instantiated. The cipher handles for CTR(AES) and GHASH

are retained for later use.The GCM implementation is responsible to invoke the CTR mode AES and

the GHASH cipher in the right manner to implement the GCM

specification.The GCM AEAD cipher type implementation now invokes the SKCIPHER API

with the instantiated CTR(AES) cipher handle.During instantiation of the CTR(AES) cipher, the CIPHER type

implementation of AES is instantiated. The cipher handle for AES is

retained.That means that the SKCIPHER implementation of CTR(AES) only

implements the CTR block chaining mode. After performing the block

chaining operation, the CIPHER implementation of AES is invoked.The SKCIPHER of CTR(AES) now invokes the CIPHER API with the AES

cipher handle to encrypt one block.The GCM AEAD implementation also invokes the GHASH cipher

implementation via the AHASH API.

When the IPSEC layer triggers the esp_input() function, the same call

sequence is followed with the only difference that the operation starts

with step (2).

## Key size and vulnerability

In a pure mathematical attack (i.e., lacking any other information to help break a cypher), three factors above all, count:

## Other bulk ciphers

Here are some ill-advised SSL ciphers from handshakes past.

## Referencesisbn links support nwe through referral fees

- Al-Kadi, Ibrahim A. April 1992. The Origins of Cryptology: The Arab Contributions. Cryptologia 16(2): 97–126.
- Al-Kadi, Ibrahim A. Nov. 24-27, 1991. Cryptography and Data Security: Cryptographic Properties of Arabic. Proceedings of the Third Saudi Engineering Conference, Riyadh, Saudi Arabia. 2:910-921.
- Curtin, Matt. 2005. Brute Force: Cracking the Data Encryption Standard. New York: Copernicus Books. ISBN 0387202292
- Diffie, Whitfield and Susan Landau. 2007. Privacy on the Line: The Politics of Wiretapping and Encryption. Cambridge, MA: MIT Press. ISBN 0262042401
- Gaines, Helen Fouché. 1956. Cryptanalysis: A Study of Ciphers and Their Solution. New York: Dover Publications. ISBN 0-486-20097-3
- Hershey, John. 2002. Cryptography Demystified. New York: McGraw-Hill. ISBN 0071406387
- Kahn, David. 1996. The Codebreakers: The Story of Secret Writing. New York: Scribner. ISBN 0-684-83130-9
- Sinkov, Abraham. 1998. Elementary Cryptanalysis: A Mathematical Approach. Cambridge: Cambridge University Press. ISBN 0-88385-622-0

## Tls 1.2 cipher suite list

**Here’s a list of the current RECOMMENDED cipher suites for use with TLS 1.2. We’re not going to publish all 37 of the ciphers that are available. These are the ones that are advisable: **

- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_DHE_RSA_WITH_AES_128_CBC_SHA
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA
- TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
- TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
- TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
- TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
- TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305

Again, you should be using Ephemeral Diffie-Hellman. Not

only is it mandatory in TLS 1.3, it also facilitates Perfect Forward Secrecy,

which guards against the decryption of individual sessions in the even the

server’s private key is ever compromised.

## Tls 1.3 cipher suite list

Here are the five TLS 1.3 cipher suites that are supported

by OpenSSL right now.

- TLS_AES_256_GCM_SHA384
- TLS_CHACHA20_POLY1305_SHA256
- TLS_AES_128_GCM_SHA256
- TLS_AES_128_CCM_8_SHA256
- TLS_AES_128_CCM_SHA256

There may be more cipher suites incoming as TLS 1.3

continues to gain its footing, but reducing the number of possible options was

also one of the biggest considerations when the IETF was finalizing TLS 1.3, so

if there are additional cipher suites added don’t expect the explosion of

combinations we saw with the TLS 1.2.

## Two kinds of encryption

**One of the biggest points of confusion when it comes to SSL/TLS centers around the types of encryption that are used. That has to do with how SSL certificates are advertised. And this really shouldn’t come as too much of a surprise given the fact the industry has never taken the time to correct everyone on the fact that we’re now using TLS certificates.**

## Types of cipher

There are a variety of different types of encryption. Algorithms used earlier in the history of cryptography are substantially different from modern methods, and modern ciphers can be classified according to how they operate and whether they use one or two keys.

Historical pen and paper ciphers used in the past are sometimes known as classical ciphers. They include simple substitution ciphers and transposition ciphers. For example “GOOD DOG” can be encrypted as “PLLX XLP” where “L” substitutes for “O,” “P” for “G,” and “X” for “D” in the message.

**Simple ciphers were replaced by polyalphabetic substitution ciphers which changed the substitution alphabet for every letter. For example “GOOD DOG” can be encrypted as “PLSX TWF” where “L,” “S,” and “W” substitute for “O.” With even a small amount of known or estimated plaintext, simple polyalphabetic substitution ciphers and letter transposition ciphers designed for pen and paper encryption are easy to crack.**

During the early twentieth century, electro-mechanical machines were invented to do encryption and decryption using transposition, polyalphabetic substitution, and a kind of “additive” substitution. In rotor machines, several rotor disks provided polyalphabetic substitution, while plug boards provided another substitution.

Keys were easily changed by changing the rotor disks and the plugboard wires. Although these encryption methods were more complex than previous schemes and required machines to encrypt and decrypt, other machines such as the British Bombe were invented to crack these encryption methods.

Modern encryption methods can be divided into symmetric key algorithms (Private-key cryptography) and asymmetric key algorithms (Public-key cryptography). In a symmetric key algorithm (e.g., DES and AES), the sender and receiver must have a shared key set up in advance and kept secret from all other parties; the sender uses this key for encryption, and the receiver uses the same key for decryption.

**In an asymmetric key algorithm (e.g., RSA), there are two separate keys: A public key is published and enables any sender to perform encryption, while a private key is kept secret by the receiver and enables only him to perform correct decryption.**

## What about dsa?

The Digital Signature Algorithm, which was already on its

way out, has been entirely removed from TLS 1.3. While there is some debate

over how secure DSA still is, what really hamstrung it was key size. DSA uses

keys that are comparable in size to RSA:

## What we hashed out (for the skimmers)

For those that like to skim, here are the key takeaways from

today’s conversation:

**As always, leave any comments or questions below… **

## What’s different in tls 1.3?

We’ve tried to point out when things have changed during

each section, but we’ll go ahead an give a more comprehensive list here. Let’s

start with the makeup of the cipher suite itself, then we’ll go back over the

ways that the algorithms themselves have been updated for TLS 1.3 cipher

suites.