This is the sequel to my previous question about AES block cipher modes of operation.
(See: AES block cipher modes of operation)

Now, here is my real problem. I have to use a block cipher with 8 bit input block size. As you say, I think that every clock cycle I receive 128 bits of information. With the 8 bit component, I have to make a structure of 16 of these components to encrypt the 128 bit information. How many round cycles does a structure like this need to encrypt the whole 128 bits. I assume the answer is 16*10, when I choose a mode which can't be parallelized (like OFB or CFB), and just 10, when I use parallelized modes (CTR). But, in the next clock cycle, I'll receive another 128 bit of information (a new message?).

  1. The structure which encrypts the first 128 bits, after how many round cycles can it start to encrypt a new message?
  2. If I want to encrypt continuous information, to encrypt every 128 bit of information I receive per cycle, do I have to make as many structures, like this one described above, as round cycles of the first structure?
  3. If I use for example CFB or OFB mode, which need an IV, I have to generate a new IV every new message (every 128 bits). Am I right?
  • $\begingroup$ I don't get your question. You say that you have 8 bit block size, but you also mention AES. That makes no sense. Do you mean that you need to encrypt messages which aren't a multiple of 128 bits without length increase? $\endgroup$ Oct 8, 2013 at 10:55
  • $\begingroup$ i think that i have a component (i don't care how it is made) which "apply" (i don't know if it's correct to say this) the AES algorithm in 8 bit. $\endgroup$ Oct 8, 2013 at 11:07
  • $\begingroup$ BTW, I think you're probably confused on a fairly fundamental level about how block ciphers work. I'd suggest reading the Wikipedia articles on block ciphers and block cipher modes of operation before even looking at my answer below. $\endgroup$ Oct 8, 2013 at 12:34

1 Answer 1


Your question is pretty confusingly written, but let me try to make some sense of it.

You say you receive 8 bits of input every cycle. You want to encrypt the input using AES, which operates on 128 bits at a time. This means that you need to buffer the input somehow (a shift register might be handy here) for 128 / 8 = 16 clock cycles, until you've accumulated a full buffer to encrypt.

Conveniently, while you're accumulating the next input block, you can encrypt the previous block at the same time. If you can do one full AES round per cycle (which apparently is indeed possible, if you can afford the gates), then you should have plenty of time to finish the encryption before the next block comes in.

Presumably, you also need to buffer the output in another shift register, and shift it out 8 bits at a time, but you can also do that in parallel with the input buffering and the encryption. So, at any given moment, your circuit will be doing three things: reading in the next 128-bit block, encrypting the current block and writing out the previously encrypted block.

All that's assuming that you want to implement the raw block cipher, i.e. "ECB mode". (The "scare quotes" are there because ECB isn't really a proper mode of operation suitable for securely encrypting long messages. It's really only good as a building block for implementing other modes, but it's pretty useful for that.) Once you have an ECB implementation, you can easily use it to implement any other mode.

Note that, for efficiently implementing the "feedback" modes (i.e. CBC, CFB and/or OFB), which require you to feed the previous encrypted (possibly modified by XORing it with the plaintext) block back into the cipher to encrypt the next block, you have two choices: you can either build the circuitry to do that into your AES module, or you can leave it as the responsibility of the user of your module to do that.

The first option is technically pretty simple (you need to be able to feed the block back through the round function several times anyway) and efficient, but it does make your circuit mode-specific, and requires you to implement some way to select the mode of operation, if you want to support more than one. For most modes, you also need to handle the encryption and decryption operations differently.

The second option is even simpler (at least from your viewpoint; it might not be simpler for the user of your circuit), but having to feed the output back in through the 8-bit I/O bus could reduce encryption speed considerably (at least by a factor of 2 if the input and output timings are staggered appropriately, by a factor of 3, or more, if they're not).

You don't need to generate a new IV for every input block — indeed, that couldn't possibly work, since the IV is a full input block. Typically, the IV is supplied as the first block of each multi-block message. If you do decide to implement the feedback internally, you do generally need to treat this first block somewhat differently from the later ones. (That's not always the case, though: for example, for CBC and CFB mode decryption, the IV can be treated just like any other ciphertext block, with the user being responsible for throwing the first plaintext output block away.)

There's also a very handy variation on CBC mode encryption where the initial "IV" is simply set to all zeros, and the actual IV is obtained by encrypting the first plaintext block, which should consist of a nonce. Decryption still works exactly same as usual. You might want to support this scheme explicitly (avoiding the need to actually feed in the dummy null IV), since it's more resistant to certain attacks involving poor IV generation than standard CBC mode encryption.

In fact, there's a another, more general case where using a fixed (say, all-zeros) IV is OK: whenever each message is encrypted with a different key. For some applications, this might be a common scenario, in which case you may want to provide it as a general option for any mode.

One final feature you're typically going to need is some way to change the key. There are applications for which having a single, fixed key permanently embedded in the encryption circuit may be sufficient, and it does simplify the circuit considerably, but for most purposes you do need to support changeable keys (which implies that you need to implement key expansion).

Another simplification you may be able to make, in some applications, is that many modes of operation (such as CTR, CFB and OFB, as well as many AE modes like EAX or SIV) only use the underlying block cipher to encrypt blocks, never to decrypt them. Although you can generally reuse much of the encryption circuitry for decryption, omitting the decryption parts still makes things a lot simpler. You do, however, need the decryption circuitry if you want to implement CBC or OCB mode (or, obviously, ECB mode) decryption.

  • $\begingroup$ Thank you my friend. It's reality that i didn't put my question forward. But it helped me understand the topic better. It'd be nice if you could explain in more detail the second part of your answer. Also, I have two more questions: 1)According to NIST's publication, there are some block cipher modes. Can I modify someway these modes to work in parallel. (just a yes/no, if there is a solution, i'd like to think on my own) $\endgroup$ Oct 11, 2013 at 12:58
  • $\begingroup$ 2)I encrypt a plaintext with a mode using an IV and send the ciphertext to you. How will you decrypt the message? With a new IV which generated on your decoder, or I have to sent you the IV too? Respectively, in CTR mode, what happend with the counters? Both in encryptor and decryptor, counters must begin counting from the same initial value? $\endgroup$ Oct 11, 2013 at 13:02
  • $\begingroup$ Yes, you need to send the IV / nonce to the recipient. The usual way is to just prepend it to the ciphertext. Also, yes, the CTR, ECB and OCB modes are easy to parallelize. AE modes using CTR as a component (EAX, GCM, SIV, etc.) can do the CTR mode en/decryption in parallel, but the authentication is typically less parallelizable. CBC and CFB mode encryption is inherently serial, but decryption can be parallelized. OFB mode is inherently serial in both directions, although it's possible to precalculate the keystream. $\endgroup$ Oct 12, 2013 at 15:09
  • $\begingroup$ I have another question. Let's assume that i have one block cipher which receives 8bit every clk cyc. It needs 16 clk cyc to get a full input block. Encryption is running for 250 clk cyc and after that it needs 16 clk cyc to write out the encrypted block. So the total processing, from receiving the plaintext to write out the ciphertext,lasts 282 clk cyc. In which clk cyc can the same block starts receiving a new plaintext? In my opinion (but i don't know if i am right), this will happend at the 266th clk cyc. What do you say? $\endgroup$ Oct 16, 2013 at 14:41
  • $\begingroup$ You could start reading the input a bit earlier, at the 250th cycle (or even earlier, but that wouldn't help with throughput). That way, when the encryption was finished on the 266th cycle, you'd already have the next input block buffered and ready for encryption. Of course, that would require an input buffer separate from the AES encryption registers. $\endgroup$ Oct 16, 2013 at 15:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.