Is this how to implement CTR around a system that only implements CBC, CFB, CTS, ECB and OFB?

Question

The encryption library in my programming language does not support CTR, though it supports CBC, CFB, CTS, ECB and OFB. I'm assuming it is theoretically possible to securely implement CTR around one of these other modes.

So I'm wondering, are these quotes describing correct implementation of CTR from a security perspective? As far as I've read I think they are, but I just want to make sure I'm not missing something.

I studied a bit more and found out that the block transform for CTR mode is really just the result of XOR'ing the plaintext with an AES ECB transform of a monotinically-increasing counter. With that understanding, I was able to implement a AES CTR mode pretty easily on top of the AES ECB mode that is built into the .NET BCL.

And,

It is possible to implement AES crypto in CTR mode using the AesManaged class, though it requires some extra work. To implement CTR mode with the .NET AesManaged class, here's what I did: Use CipherMode.ECB, PaddingMode.None. [No padding is necessary in CTR mode because we are always encrypting a 16-byte counter.] When encrypting, call CreateEncryptor(). Using the resulting ICryptoTransform, for each block, transform a nonce of 16-bytes (Same as the AES block size), and then XOR the result of that transform with the plaintext to get the ciphertext. Increment the nonce after each block. Continue until there are no more blocks - don't forget the final block transform, for the last block of 16 or fewer bytes.

For one thing, when the quote says 'increment,' what kind of increment should it be? Surely not linear?

Answer 1

The texts you quote are correct: CTR mode is indeed about encrypting the successive values of a counter, and XORing the resulting stream of bytes with the data to encrypt.

CTR mode is an "approved" mode of operation, as the NIST states. For the "increment", it can be about any way of going through 128-bit values as you want (I am assuming a block cipher with 128-bit blocks, such as AES), but if you seek interoperability, then "the" standard CTR mode is the following:

• The counter is a 128-bit unsigned integer, i.e. a value between 0 and 2¹²⁸-1.
• The counter is encoded as a sequence of 16 bytes using big-endian convention (first byte is most significant).
• The Initial Value (IV) is the big-endian encoding of the first counter value; in other words, with AES/CTR, the first 16 bytes of the ciphertext are the result of the XOR of the first 16 bytes of the plaintext with the encryption of the IV (as a 16-byte block).

Since most programming languages do not have 128-bit integer values, the counter increment is usually done byte by byte (begin with byte 15, increment it; if the result is 0, there is a carry and you continue with byte 14, and so on; otherwise, just stop there).

CTR mode security relies on never having the same counter value be used twice for a given key. 128-bit blocks are a large space; choosing the IV randomly and uniformly is sufficient to ensure this no-reuse policy. Using CTR mode with a block cipher which has smaller blocks (e.g. 3DES and its 64-bit blocks) could be dangerous, because a 2⁶⁴ space is not that large.

One way of viewing CTR mode is that it turns a block cipher into a generator for a long stream of pseudo-random bytes; XORing this stream with the data to encrypt makes it a stream cipher.