looking at the linux kernel provided cipher and block cipher modes cat /proc/crypto my prefered mode CTR (counter/integer) is not provided.

However the "crazy unsafe" ECB mode - in which "all equal plaintext blocks result in equal ciphertext" - exists almost everywhere.

My question is: Can I emultate CTR mode by ECB-mode block cipher encrypting blocks via this scheme

Plaintext Block 1: random initial value  
Plaintext Block 2: Plaintext Block 1 incremented by 1
Plaintext Block 2: Plaintext Block 2 incremented by 1
Plaintext Block n: Plaintext Block n-1 incremented by 1

and XOR the resulting ciphertext of the ECB counter function against my actual plaintext, as a way to achieve CTR mode?

  • $\begingroup$ Let's remember one important issue; ECB is called a mode of operation due to historical reasons. In modern cryptography, calling it a mode of operation is not correct. It uses the block cipher as it is. The real mode of operations, on the other hand, uses the block cipher as a block box. $\endgroup$
    – kelalaka
    Feb 1 at 15:01
  • $\begingroup$ So, CTR mode uses the block cipher by controlling the input, key, and output like other modes of operations. You just implemented CTR mode with random IV/counter. Why do you choose, a random initial value? $\endgroup$
    – kelalaka
    Feb 1 at 15:01
  • $\begingroup$ In my Ubunut 22.04.1, CTR mode exist. Why do you consider that it doesn't exist? $\endgroup$
    – kelalaka
    Feb 1 at 15:41
  • $\begingroup$ @kelalaka Where are you looking, are you looking in the low level kernel calls? $\endgroup$
    – Maarten Bodewes
    Feb 2 at 1:55
  • $\begingroup$ @MaartenBodewes as OP did, cat /proc/crypto | grep ctr $\endgroup$
    – kelalaka
    Feb 2 at 9:17

1 Answer 1


Yes, that's usually also the reason why ECB is supplied, to have it implement other cryptographic primitives. The good thing about CTR is that you can create the resulting key stream in advance, in parallel and/or use a lower level function over many blocks, removing some overhead of calling a function for each block. Finally, it is also possible to skip counter values and decrypt only part of the ciphertext without having to calculate the rest of the key stream.

Beware though that leaking the key stream is not a good idea, assuming that those bits / bytes are used. The key itself is still protected by the block cipher, as with all secure modes of encryption.

Personally I prefer to implement the increment byte by byte (if result is zero then increase more significant byte etc.). This allows me to control the counter size for instance (and throwing an exception or similar if the counter overflows). Copy-then-increase seems the most reasonable method here.

Personally I like starting with an all zero counter, which makes it easier to know how many blocks are available for a given nonce, and it allows easy detection of overflow as well (assuming that the counter block consists of a nonce followed by a counter).

Cryptographic API's usually just start with a 16 byte "IV" and then use increments mod $2^n$ where $n$ is the block size, without any overflow detection. The counter is commonly assumed to be big endian and at the right hand side of the byte array (least significant bits). I've only seen one exception to this rule-of-thumb so far.

Similarly, most if not all cryptographic API's don't consider ECB to mean a single block encrypt; it is a mode of operation where each plaintext block is encrypted separately. Low level API's generally do not perform padding of the plaintext to encrypt the last block. Higher end API's will either allow configuration or default to a padding mode, usually PKCS#7 but zero-padding is also (surprisingly) common.

  • $\begingroup$ is ECB supplied or the block cipher enc/dec operations? ECB is more than the block cipher itself. $\endgroup$
    – kelalaka
    Feb 2 at 9:22
  • 1
    $\begingroup$ @kelalaka as you mention, ECB block cipher operations mode would imho imply to be more than the enc/dec of a single block only (i.e. the block cipher operation). $\endgroup$ Feb 2 at 9:50
  • 1
    $\begingroup$ I've added some information on how ECB is handled by API's at the end, mainly to indicate the different padding options that could be present as that seems important if you're going to implement e.g. CTR. $\endgroup$
    – Maarten Bodewes
    Feb 2 at 20:22
  • $\begingroup$ thanks @MaartenBodewes I look forward to implement padding. happy to not have to use this ciphertext stealing thing.... $\endgroup$ Feb 3 at 10:33
  • $\begingroup$ No, for CTR padding is not required. If it is implemented for ECB it is a nuisance if you wan to use ECB for other modes. Most modes actually don't require padding, it's just ECB, CBC and the uncommon PCBC. $\endgroup$
    – Maarten Bodewes
    Feb 3 at 13:55

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.