(3 votes, average: 4.67 out of 5)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

January 14, 2021 7

Block Cipher vs Stream Cipher: What They Are & How They Work

in Everything Encryption

Symmetric encryption ciphers consist of two main categories: block ciphers and stream ciphers. We’ll define and break down the processes of each, and provide block and stream cipher examples to give you a closer look at the technologies that keep your data safe

Understanding the difference between a block cipher vs stream cipher is kind of like the difference between watching a movie on DVD or via a streaming service. Sure, both will give you the entertainment you seek, but they each work differently in terms of mechanics and speed.

Today, we’re going to cover these two both groups of symmetric key ciphers. But what is the difference between a stream cipher vs block cipher? What types of ciphers fall under each umbrella? Which ones are used in SSL/TLS encrypted connections? And how do block and stream ciphers work to secure your data and when do you use each?

Let’s hash it out.

Editor’s Note: This article is the first in a series of articles on symmetric encryption. Be sure to check out the related articles below:

• Symmetric Encryption 101: Definition, How It Works & When It’s Used
• Symmetric Encryption Algorithms: Live Long & Encrypt
• Asymmetric vs Symmetric Encryption: Definitions & Differences

Block Cipher vs Stream Cipher

Block and stream ciphers are two ways that you can encrypt data. Also known as bulk ciphers, they’re two categories of symmetric encryption algorithms. (Reminder: with symmetric encryption, you use the same key to encrypt and decrypt data.) Block and stream ciphers are two separate routes to the same end goal of securing your data. The big difference between the two is how the data gets encrypted — and there are advantages and disadvantages to each method — and the types of environments they operate in.

For now, let’s break down what these ciphers are in general and how they work.

Block ciphers and stream ciphers are two separate methods of encrypting data with symmetric encryption algorithms:

• Encrypting information in chunks. A block cipher breaks down plaintext messages into fixed-size blocks before converting them into ciphertext using a key.
• Encrypting information bit-by-bit. A stream cipher, on the other hand, breaks a plaintext message down into single bits, which then are converted individually into ciphertext using key bits.

(Note: some people say stream ciphers encrypt data by individual bits, others say by bytes [8 bits]. So, I’ll just stick with saying individual bits for the sake of ease in this article.)

If you want a simple analogy to better understand a block cipher vs stream cipher, imagine you’re encrypting a book. You could encrypt the content one page at a time (block cipher) or one letter at a time (stream cipher).

Of course, both processes are more complicated than that, but that gives you a basic idea of what they are and what they do. According to Jean-Philippe Aumasson in his book “Serious Cryptography: A Practical Introduction to Modern Encryption”:

“[…] block ciphers mix chunks of plaintext bits together with key bits to produce chunks of ciphertext of the same size, usually 64 or 128 bits. Stream ciphers, on the other hand, don’t mix plaintext and key bits; instead, they generate pseudorandom bits from the key and encrypt the plaintext by XORing it with the pseudorandom bits[.]”

If that was clear as mud, no worries. We’ll dive more into the nitty-gritty technical side of things shortly. But first, where would you find these types of ciphers in use? Look no further than the technologies around you.

Block ciphers are the algorithms that form the backbone of many of the cryptographic technologies and processes that are in use today in computer communications. Basically, you can find block ciphers just about anywhere in cyber security.

Where stream ciphers are concerned, they’re not as well studied. However, you’ll find stream ciphers in use in:

• SSL/TLS connections
• Bluetooth connections
• Cellular and 4G connections

XOR Operations in Cryptography

This is an important concept to cover when talking about block and stream ciphers, but there’s no great place to slip this into the article, so we’re going to do it here. Okay, you’ve probably seen this weird looking little symbol when reading about cryptography: ⊕. This is known as an XOR, or what stands for the “exclusive-or” logical operation.

Stream ciphers use bitwise XOR operators on binary data as part of their encryption and decryption processes. You remember the pseudorandom bits Aumasson mentioned? Basically, that’s known as a keystream when you’re talking about stream ciphers. And a keystream has to be unpredictable to be secure.

So, what XOR does is compare two input bits and generate a single output bit. It’s a way to check for error among other things. If both bits match, it returns a 0 (false); if they don’t match, it returns a 1 (true).

Here’s a quick table for reference (this is known as an XOR Table):

Input Bit1	Input Bit2	Output
0	0	0
0	1	1
1	0	1
1	1	0

Basically, Bit1 ⊕ Bit2 = Output.

So, let’s say Bit1 is 101000101 and Bit2 is 100101110. Here’s what it looks like when you XOR the two sets of binary bits:

101000101 ⊕ 100101110 = 001101011

This means that your output would be 001101011. Pretty cool, huh?

Okay, that actually wasn’t so bad, was it? Now that we’ve got that out of the way… Let’s get down to brass tacks on what stream ciphers vs block ciphers are. To do this, we’ll define and break each down so you can better understand what they are and see how they’re different.

What Is a Block Cipher?

As the name would imply, a block cipher is one that allows you to use a key to encrypt data in big ol’ groups (blocks) of a pre-determined size (such as 128 bits, 256 bits, etc.). So, what this does is allow you to encrypt all the data in a block as a single unit. For example, let’s say you have the message: “For the Alliance.” (Don’t hate, Horde fans. Your time will come.)

If you want to encrypt that using a block cipher, the plaintext message would be broken down into smaller blocks of binary. So, “For the Alliance” would look something like this:

0100011001101111011100100010000001110100011010000110010100100000010000010110110001101100011010010110000101101110011000110110010100101110

Now, if we break these 136 binary digits into blocks of, say, 4 digits, it divides nicely because 4 goes into 136 a total of 32 times. The blocks would look something like this:

But what do you do if the there isn’t enough data to form a complete block? Like, say, if you had 138 binary digits instead of 136 (meaning you’d have an incomplete last data block)? Then what you can do is add padding (this could be a set number of 0s) to the end of the block to ensure the block is that fixed size.

Block cipher example: This simplified version of a block cipher illustrates how block ciphers work overall. It’s similar in design to how the ECB mode of operation works, which you’ll learn more about a little later in this article.

Depending on the mode of operation you use (we’ll explain that more shortly), the blocks are then “chained” together, which enables the blocks to be connected sequentially. In some cases, block ciphers can operate as stream ciphers based on their modes of operation. This is because they take on certain properties due to those modes, which we’ll discuss later in the article.  

A basic block cipher that uses a chaining operation (illustrated with the orange connecting arrows). In this case, this is akin to a simplified example of a CBC block cipher mode of operation. Yes, I know, this illustration is lacking the initialization vector and XORing. But, again, this is supposed to be a simplified version that just intends to showcase the chaining of one data block to the next.

But what are the advantages of using block encryption algorithms?

• Block ciphers are difficult to mess with in terms of inserting symbols.
• They’re highly analyzed and studied by cryptographers, which means that people smarter than you and me have attempted to break them.

So, what are some examples of some common block ciphers?

Examples of Block Ciphers

• Data Encryption Standard (DES),
• Triple DES (3DES or TDEA),
• Advanced Encryption Standard (AES),
• International Data Encryption Algorithm (IDEA),
• Blowfish,
• Twofish, and
• RC5

If AES sounds familiar, there’s a good reason. It’s actually the most commonly used type of block cipher. You’ll find AES encryption used in everything from securing SSL/TLS internet connections to government data. For example, the National Security Agency (NSA) relies on AES encryption to secure its data that’s categorized as up to top secret.  

Because block ciphers are the most commonly used and studied ciphers, they’re our main focus for this article. But let’s take some time to explore stream ciphers as well to help you familiarize yourself with what they are, how they work, and how they differ from block ciphers.

What Is a Stream Cipher?

A stream cipher is a cipher that encrypts (and decrypts) with the flow — the data flow, that is. Unlike block ciphers, which require the formation of blocks prior to encryption, stream ciphers encrypt data in long, pseudorandom streams. Basically, this means you can process one bit of data at a time instead of waiting for a data block to form.

In their book “Domain Specific High-Level Synthesis for Cryptographic Workloads,” Ayesha Khalid, Goutam Paul and Anupam Chattopadhyay describe stream ciphers as finite state machines, or FSMs, and stateful ciphers. The reason for the first description (FSM) is because these ciphers take in plaintext bits of data one by one and spit out ciphertext symbols in the same way. The reason they’re also called stateful ciphers is because they rely on their internal state for their keystream functions.

But did you know there are actually two types of stream ciphers?

1. Synchronous stream ciphers (aka key auto-key, or KAK) — These types of ciphers generate keystreams independently of any previous plaintext or ciphertexts.
2. Self-synchronizing stream ciphers (aka asynchronous stream ciphers, ciphertext autokey or CTAK) — These ciphers, on the other hand, rely on previous ciphertext bits to generate keystreams.

How Stream Ciphers Work

So, how does a stream cipher actually work in a more technical sense? As mentioned earlier, a stream cipher encrypts data one bit at a time instead of in blocks. But a key part of this process is generating a stream of pseudorandom bits based on an encryption key and a seed, aka a nonce (a unique randomly generated number — “nonce” = number-only-used-once). Together, they create a keystream (that stream of pseudorandom bits we just mentioned) that gets XORed with your plaintext input, which encrypts it and results in your ciphertext output.

This rinse-and-repeat process happens over and over again with each bit of plaintext data. However, it’s important to not use the same exact key-nonce combination again because it can result in a duplicate keystream.

Feeling a bit confused? Here’s a visual of the process to provide a little clarity:

To better understand this, let’s walk through an example. Let’s consider an alternative phrase to the example we used earlier: “For the Horde!” (See? I haven’t forgotten you guys.) The binary version of this plaintext message would look like this:

0100011001101111011100100010000001110100011010000110010100100000010010000110111101110010011001000110010100100001

So, if we use a stream cipher to encrypt the message, we’ll do so one bit at a time. So, the plaintext data would be broken down into individual bits, which would look something like this:

Yeah, take a moment to let your eyes adjust after reading that, uh, colorful graphic.

So, the next step here would be to generate the sequence of pseudorandom bits (i.e., the keystream). This is typically based on an internal state.

Once you have your keystream, you XOR the pseudorandom bits with the binary of your plaintext message. Thinking back to the XOR table from earlier, this means that if the first bit of the plaintext message was 1 and the first bit for the keystream was a 0, then the output would be a 1. If the second bit of the plaintext message was another 1 and the first bit of the keystream was also a 1, then the output would also be a 0. Get it? Yeah, that’s basically how a stream cipher works.   

Stream algorithms are faster and more efficient than block ciphers because they’re encrypting only one bit of data at a time into individual symbols rather than entire blocks. So, they’re better suited for devices that have fewer resources. Also, as a result of this single-bit-of-data approach, it means that if there’s an error in one symbol, it’ll be less likely to affect the next. However, some stream ciphers are vulnerable to bit-flipping attacks and key reuse attacks.

A very basic example of a stream cipher is the Caesar cipher, which is a cipher that that substitutes one character with another individually. But that’s a really archaic and outdated example of a cipher. So, what sorts of stream ciphers can we find in use today?

Examples of Stream Ciphers

• Salsa20 (software and hardware implementations),
• ChaCha20 (the modified version of Salsa20; ChaCha20 is supported in TLS 1.3),
• RC4 (for wireless networks), and
• A5 (for GSM cellular networks).

Keep in mind, however, that this list of stream ciphers is, in no way, comprehensive. But it at least provides you with several examples of symmetric encryption algorithms that you can associate with each.

Is a Block or Stream Cipher More Secure?

The answer to this question isn’t really as simple as stating “a block cipher is more secure than a stream cipher” or vice versa. What I mean by that is that it’s really the strength of the key that determines how secure a block or a stream cipher is. But what if you just keep the internal workings of your cipher secret — that’ll make it more secure, right? Eh, not so much.

Bruce Schneier states it well:

“Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can’t break. It’s not even hard. What is hard is creating an algorithm that no one else can break, even after years of analysis. And the only way to prove that is to subject the algorithm to years of analysis by the best cryptographers around.”

This is why the most trusted ciphers are those whose algorithms are published, analyzed, and tested by cryptographers the world over. Think AES, or what was originally known as Rijndael (named after its creators, Joan Daemen and Vincent Rijmen).

Block Cipher Modes of Operation

Remember how we mentioned that some block ciphers can operate as stream ciphers? This is possible through specific modes of operation, which include CFB, OFB, and CTR — all of which we’re going to talk about shortly. However, it’s important to note that stream ciphers can’t convert into or operate as block ciphers. It’s kind of like how caterpillars transform into butterflies but not vice versa. 

For the purpose of this article, we’re going to focus on confidentiality modes of operation. Did you know that there are five confidentiality modes in which block ciphers can operate that NIST recommends? You can find them in NIST SP 800-38A: Recommendation for Block Cipher Modes of Operation.

Let’s briefly go over each of the five modes to better understand what each one is and how it works:

1. Electronic Codebook (ECB) Mode

This is the most simplistic (and weakest) operational mode that encrypts blocks separately. It’s not designed for new blocks to be dependent upon the output of previous blocks. This means that you can encrypt or decrypt data blocks independently.

It’s also the easiest for bad guys to pick apart because all data blocks are encrypted the same way, which makes it easy to detect patterns. So, if you end up sending different messages but some of the messages are the same, then you’re going to end up with some identical instances of ciphertext. Think of the famous ECB mode Linux penguin example. The idea here is that even if you can’t decrypt certain bits (such as pixels of the Linux penguin logo), you can still tell enough from the patterns you can decrypt to still understand the overall message.

Basically, ECB tends to give away a bit too much information about the message you’re trying to encrypt. So, the big takeaway here is don’t rely on ECB for secure encryption.

2. Cipher Block Chaining (CBC) Mode

The gist of this operational mode is that it’s a sequential process that builds upon previous data blocks (this is the explicit chaining we mentioned earlier). So, plaintext blocks of input data get “chained” to previous output blocks of ciphertext with the use of an initialization vector (IV). And to make the IV more random, it’s XORed prior to the encryption of each input.

After the data runs through the cipher, the output is then chained to the subsequent block of data that follows. This data-linking process, known as explicit chaining, aids in helping to further mask your message. It does this by adding in the data from the previous block. So, even if you send or receive two of the exact same plaintext messages, the ciphertext for each will be different because of the chained data.

So, basically, CBC mode takes ECB mode and kicks it up a notch in terms of complexity and confidentiality by adding data from previous bocks. However, it’s not used all that often anymore. Why? A couple of important reasons:

1. This operation mode is slow. You can’t encrypt or decrypt two or more messages simultaneously because each message includes data from the previous block. While this may not be an issue for small files, it can prove a big challenge for encryption or decryption at scale.
2. This mode of operation is susceptible to padding attacks and manipulation. If an attacker manages to alter the ciphertext of one block, the next block would be affected because of the data chaining.

Explicit chaining is involved in both CFB and OFB modes. And the use of IVs, which are part of the encryption and decryption steps for CBC, CFB, and OFB modes, is integral to the security of these three modes.

Note: NIST did release an addendum regarding CBC mode (NIST SP 800-38A-Addendum). This document specifies three variants of CBC mode that avoid ciphertext expansion.

3. Cipher Feedback (CFB) Mode

This operational mode generates pseudorandom bits. It uses the ciphertext from the previous block in the chain (this is known as feedback, hence the fitting name) and a cryptographic key to do this.

An important point to note is that an encryption cipher function is used in both the encryption and decryption processes, rather than using an encryption function for the first and decryption function for the latter. Also, error propagation is an issue with CFB mode because an error in one block can carry over into the next (although it wouldn’t affect the block beyond that). However, this isn’t an issue for OFB or CTR modes, which we’ll get to next.

4. Output Feedback (OFB) Mode

The idea with this mode is that it’s similar to CFB, however, the random number generation relies on the cipher function output from previous block as the feedback. OFB encryption and decryption both also use the encryption function. However, what OFB doesn’t do is use the plaintext or ciphertext as part of the cipher function processing.

NIST breaks down the process of going from one block to the next as such:

“In OFB encryption, the IV is transformed by the forward cipher function to produce the first output block. The first output block is exclusive-ORed with the first plaintext block to produce the first ciphertext block. The forward cipher function is then invoked on the first output block to produce the second output block. The second output block is exclusive-ORed with the second plaintext block to produce the second ciphertext block, and the forward cipher function is invoked on the second output block to produce the third output block.”

… So on and so forth. Basically, each block’s output is produced through the application of the cipher to the previous block’s output. By XORing the outputs with the plaintext, you then get the next block of ciphertext.

The process looks like this:

But what happens when you reach the last block output? Some are used in the final XOR operation; others are discarded.

5. Counter (CTR) Mode

Alright, y’all, hold on just a little longer. We’re on the last one! This operational mode, the newest one recommended by NIST, is designed to serve as a counter for pseudorandom generation (hence the name). This is one of the most commonly used modes of operation.

CTR mode has similarities to OFB mode but is still different. For example, unlike the previous operational modes, CTR doesn’t require explicit chaining and is parallelizable. This means that you can process and encrypt separate messages in parallel (like stream ciphers). So, this means that because it doesn’t depend on the output from a previous block, you can decrypt two blocks independently. 

The security of this mode depends on the protection of the counter values (CVs), so you should never recycle your CVs.

Yeah, I know, all of the above modes looks like a bowl of alphabet soup with all of the acronyms — ECB, CFB, OFB, etc. But what these modes do (when paired with FIPS-approved block cipher algorithms) is important because a block cipher doesn’t run without one of them. These operational modes aid in securing sensitive, non-classified computer data.

If modes of operation excite you, or if you’re that much of a glutton for punishment, be sure to check out NIST’s publication (SP 800-38A) for a more in-depth understanding of each of the five operational modes we highlighted above. (It dives into all of the mathematical specifications that make the rest of us feel a bit cross-eyed.)

There are also other modes of operation that you can familiarize yourself with as well, such as Galois Counter Mode (GCM)and XEX Tweakable Block Cipher with Ciphertext Stealing (XTS) mode (including XTS for AES mode). But we’re not going to get into all of those here.

To see how these modes of operation come together with bulk ciphers in a cipher suite, be sure to check out our article that breaks down cipher suites.

TL;DR: Block Cipher vs Stream Cipher

Yeah, that was a lot of information to slog through. However, it’s our hope is that this article has provided you with greater clarity about stream ciphers and block ciphers, what they do, and how they work.

Don’t have time to read through all of this technical content to differentiate a block vs stream cipher? No worries, we’ve got you covered with a quick overview of block ciphers and stream ciphers:

Block Ciphers	Stream Ciphers
Symmetric key ciphers that encrypt and decrypt data in fixed-size blocks.	Symmetric key ciphers are stateful ciphers that encrypt and decrypt data bit-by-bit.
Slower processing.	Faster processing.
Require more resources.	Require fewer resources.
Can take on stream cipher properties through certain modes of operation.	Cannot take on block cipher properties.
Rely on stateless and stateful modes of operation, which include ECB, CBC, CFB, OFB, CTR, GCM, and XTS.	Can be synchronous or asynchronous.
Used nearly everywhere.	Used for some data in-transit encryption, including in some SSL/TLS cipher suites.

• #Block Cipher
• #Stream Cipher