2
$\begingroup$

Reading https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Counter_(CTR) it looks like CTR (and some other modes) encrypt the nonce (plus count, for CTR) rather than the plaintext.

The plaintext is then XOR'd with the encrypted nonce to produce the ciphertext.

Have I understood this correctly?

Why is it done this way round?

Improve this question
$\endgroup$
1
  • 1
    $\begingroup$ A further read on CTR mode where you can find the original; definition of the CTR mode on the history part, too. $\endgroup$
    – kelalaka
    Jun 2, 2021 at 19:29

1 Answer 1

Reset to default
4
$\begingroup$

Yes, CTR (resp. OFB) mode first "encrypt the nonce" then increment it (resp. replace it by the result of the block encryption), and repeat, producing a keystream; the plaintext is just XORed with the keystream, forming the ciphertext. In effect, CTR and OFB are stream ciphers made from a block cipher.

Among advantages:

  • Decryption and encryption are the same.
  • For AES, which block decryption in software is inherently more compute-intensive than block encryption, that reduces the cost of decryption.
  • There is no need to pad the plaintext to block boundaries; it's enough to truncate the keystream.
  • It's possible to produce the keystream before the data is available, allowing a reduction in encryption/decryption latency.
  • For CTR, preparing the keystream is parallelizable. Contrast with CBC, where encryption must be sequential (beside requiring availability of the data).

The only drawback is the malleability of ciphertext (meaning toggling a bit of ciphertext toggles only the corresponding bit in the deciphered plaintext), inherent to stream ciphers. But malleability is a non-issue with authenticated encryption modes like AES-GCM (which uses CTR mode for encryption), since relying on the feeble integrity properties of CBC mode is a recipe for disaster anyway.

Improve this answer
$\endgroup$
2
  • 1
    $\begingroup$ which block decryption in software – Same with hardware. When using AES-NI acceleration, decryption is still slower than encryption and you need to use some additional instructions (AESIMC). $\endgroup$
    – forest ♦
    Jun 4, 2021 at 23:08
  • $\begingroup$ @forest: yes AES block decryption is inherently more costly including in hardware. However I imagine that the AESIMC operation can be amortized over multiple blocks, and that since AESDEC has the same timing as AESENC, the net difference becomes much less than in software (unless there's a software trick to speed-up software decryption that I missed, or my mental picture of the AESIMC / AESDEC combo is wrong). $\endgroup$
    – fgrieu ♦
    Jun 5, 2021 at 5:44

Your Answer

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

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