Message lengths with AES CTR mode?

Question

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);
        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.

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?