Im working on my own AES implementation as a personal educational exercise (not for production use), and a book im using as a resource states:

In the case of CTR, we are merely XORing the output of the cipher against the plaintext. This means there is no inherit reason why the plaintext has to be a multiple of the cipher block size. CTR mode is just as good for one-bit messages as it is terabit messages.

I dont understand the author's statement. In my implementation im planning on having a 16 byte IV/counter, with 12 bytes being the random IV, and 4 bytes for the counter. In pseudocode, something like this:

byte [] CTR_encrypt(byte [] key, byte [] plainText){
    byte [16] IVAndCounter;
    nPlainTextBytes = plainText.getLength();
    int blockCount = ceiling(nPlainTextBytes / 16)
    for(int i = 0 ; i < blockCount ; i++){
        byte [???] cipheredIVAndCounter = AES(key, IVAndCounter);
        byte [???] cipherText = cipheredIVAndCounter XOR plainText;
        byte [???] cipherTextComplete = cipherTextComplete + cipherText;
     return cipherTextComplete;

I understand why why you wouldn't have to pad say the last block of plaintext, that might not be 128 bits long, but you still have to divide the plaintext into 128 bit blocks in order to XOR it with the 128 bit ciphered IV/counter don't you? You cant just XOR the 128 bit ciphered IV/counter with the whole plaintext, as that would leave much data unencrypted? That is, the plaintext, must be 128 bits or less for CTR mode?

Maybe im missing something. I looked at this question: Why doesn't CTR mode require blocking? , but still dont get it, and feel if anything more confused after reading it.

  • $\begingroup$ I understand what Poncho said. But i think there will be Padding after the 14 bits in the second block! $\endgroup$ Dec 4, 2017 at 4:09
  • $\begingroup$ CTR mode does not use padding $\endgroup$ Dec 4, 2017 at 4:58

1 Answer 1


Well, lets try to take a concrete example:

Suppose that you have a 142 bit message that you need to encrypt with CTR mode. What do you do?

Well, you generate the first 128 bit block with AES; you take the first 128 bits of the message, exclusive-or the two, and that's the first 128 bits of the ciphertext.

Then what? Well, you have 142-128=14 bits of plaintext left. So, what you do is generate the second 128 bit block with AES; you then take the first 14 bits of that, exclusive-or that with the 14 bits of plaintext, and that gives you the last 14 bits of the ciphertext. And, what do you do with the remaining 128-14=114 bits of AES output? Well, you discard it -- you don't need it.

If the decryptor does precisely the same logic, he will transform the 142 bit ciphertext into the original 142 bit plaintext.

Does this make things clearer?

  • $\begingroup$ I think so, so its like ya the plaintext doesn't have to be a multiple of the cipher block size, but you still have to encrypt/decrypt it, process it if you will, in 128 bit blocks? Say the number of bits in the plaintext being $128n+i:0\le i \le 127$ , you do $n$ full size blocks, and then a single block of size $i$ using the method you outlined? $\endgroup$ May 22, 2014 at 0:56
  • 1
    $\begingroup$ @guydudebro: yes; you'd do exactly that. $\endgroup$
    – poncho
    May 22, 2014 at 3:01

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.