Which Encryption Process Encrypts on Either Side?

Making stream ciphers from AES: CFB Mode

Which Encryption Process Encrypts on Either Side?

Making stream ciphers from AES: CFB Mode

Introduction

Okay… the cryptographers have been keeping a secret. You think that your encrypted content is perfectly safe, but it often suffers from many problems:

  • Encryption works great, until it doesn’t.
  • Encryption works great, as long as no one makes a mistake.
  • Encryption works great, unless something goes wrong.
  • Encryption works great, as long as everything works right.

Apart from using a password to generate an encryption key, which completely decimates the key space, we have the problem of the algorithm used to process the plain text. If this is ECB (Electronic Code Book) we have repeating cipher blocks for the same plain text.

If I take “eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee” and encrypt with 3-DES and a key of “bill12345” we get:

1122900B30BF1183 1122900B30BF1183 1122900B30BF11831 
122900B30BF1183 1122900B30BF1183 1122900B30BF1183 
7591F6A1D8B4FC8A

where we can see that the “e..e” values are always coded with the same cipher text. As 3-DES has message blocks of 64-bits, then 8 ‘e’ values will fill each block.

[eeeeeeee] [eeeeeeee] [eeeeeeeee] 
[eeeeeeee] [eeeeeeee] [eeeeeeee] 
[eeeeee <PADDING>]

Thus we can say that “eeeeeeee” maps to the cipher text of 1122900B30BF1183.

Try example here.

More details on ECB here.

Cipher Feedback (CFB)

Normally we think of the encryption process as taking plain text and using an encryption key to create the cipher text, and then applying the same key with a decryption process. The problem with this type of process is that an error in the cipher text will cause problems in decrypting.

So we apply Cipher Feedback (CFB), which basically converts our cipher block into a bit stream, and we can this encrypt and decrypt each bit at a time. This method is defined as self-synchronising. For this we do not encrypt and decrypt, but we encrypt the IV (Initialisation Vector) or a previous cipher block with the key, and EX-OR that with the data (on the sending side) or with the cipher stream. After the first block of data, we use encrypt the previous cipher block (Figure 2), and on the receiver we do the same. So the process on either side is almost identical, apart from the data which is used, where the sender uses data blocks (such as 128-bit blocks) and the receiver uses the cipher stream to build the data blocks.

If you are interested, here is the process for CFB (where P are the data blocks and C are the re-built cipher blocks):

With ECB we do not get variation in the cipher blocks, so in CFB we use the IV, so, along with the shared key, we must pass the IV value in order to decipher the cipher stream.

Figure 1: Cipher feedback (CFB)

Figure 2: CFB process

To see the full range of methods used … try here. The one thing that we normally need is a block cipher is padding, such as with CMS. But in CFB, there is no need for it:

Conclusions

Embedded into encryption are two key operators: rotate bits and X-OR. Both are extremely simple, but they never lose anything. ECB is extremely weak, and it’s not too difficult for an intruder to probe with well-known data, and watch the cipher streams, and then basically play that back.

An error in encrypted data too can cause a whole lot of problems, so OFB provides a method to take each bit one at a time, and get some errors, but, eventually recover from them. So if you encrypt your laptop, and you have one bit in error, the last thing you want is for the whole drive to be corrupt. Normally, though, our stream ciphers are used to transmit data in real-time, and where we want to decrypt in real-time.

So I’ve shown you a process which uses encryption on both sides, and it works! There’s no decryption involved .. magic!

Further details

If you want more details on ECB and CBC click here and on OFB here.