8
$\begingroup$

Let's consider the CTR mode. For a faster encryption/decryption, is it preferable to use the decryption operation of AES, or its encryption ?

Improve this question
$\endgroup$
1
  • $\begingroup$ There shouldn't be any noticeable difference, as both functions consist of essentially the same set of steps (modulo order and operations' inverses). $\endgroup$
    – yyyyyyy
    Commented Sep 2, 2015 at 9:25

5 Answers 5

Reset to default
8
$\begingroup$

Given the choice, it is preferable to use the block encryption operation of AES, since it often faster than block decryption (never slower AFAIK). For this reason, AES-CTR is defined to use the block encryption operation of AES exclusively; that's both for AES-CTR encryption and AES-CTR decryption, which are the same operation except for IV generation/input.

AES block encryption is faster than AES block decryption because:

  • MixColumns uses a matrix with smaller coefficients than InvMixColumns, thus is simpler to compute (that's particularly true for purely software implementations; hardware implementations sometime use the same number of cycles, including I believe Intel's AES-NI instructions).
  • during encryption, subkeys are needed in the order they are produced from the key, but during decryption that order is reversed, therefore on implementations (including hardware) that start decryption with the pristine key as input, some preliminary work is necessary before decryption can start (there's no known shortcut).

Here is for example a crypto library performance report (single-thread, software AES) showing speed differences.

Improve this answer
$\endgroup$
0
1
$\begingroup$

It is usually seen that decryption operations are slightly faster than encryption. But considering the working mode of AES, CTR uses same steps in both encryption and decryption. So It does not matter which one you use in CTR, both should give essentially same performance.

Improve this answer
$\endgroup$
3
  • $\begingroup$ Thanks "So It does not matter which one you use in CTR, both should give essentially same performance." If AES-decrypt is faster than AES-encrypt then CTR will be faster when used with AES-decrypt ,won't it ? $\endgroup$
    – Dingo13
    Commented Sep 2, 2015 at 9:54
  • $\begingroup$ AES has same performance for both encryption and decryption, the mode which you are using may make it slower. E.g. CTR is parallelizable mode and can make enc and dec operations in same time. But take CBC, its serial in encryption and parallel in decryption. So in CBC mode decryption is faster. But this is not the case with CTR. Both enc and dec should give same performance. $\endgroup$
    – rijndael
    Commented Sep 2, 2015 at 9:57
  • 1
    $\begingroup$ "It is usually seen that decryption operations are slightly faster than encryption" is correct if you consider wall clock time and some modes (because e.g. CBC decryption can be parallelized, when CBC encryption can't). But when you consider CPU load for said modes, or other modes (ECB..) that effect tends to invert, for reasons outlined in my answer. ECB parallelize for both encryption and decryption, and in software encryption is faster. $\endgroup$
    – fgrieu ♦
    Commented Sep 2, 2015 at 13:41
1
$\begingroup$

The one you have in hardware.

Sometimes the hardware only supports block encryption (because it is sufficient for e.g. CTR), in which case that will be faster. If the hardware supports both, there is probably no difference. I doubt many implementations only support decryption, but if you have one that does, that would be faster.

The speed of raw encryption/decryption should not differ much if you have similar implementations of both. Every step of AES encryption has a counterpart in decryption that works the same, only with different numbers. (The same is not necessarily true for all ciphers.)

Any practical difference in encryption vs. decryption speed with AES is usually due to the mode of encryption used. For example, random IVs take time to generate during encryption but not decryption, while CBC and CFB modes are parallelizable during decryption but not encryption. None of that matters for which direction you should use in CTR mode.

Improve this answer
$\endgroup$
1
$\begingroup$

You should use the encryption mode for AES in CTR mode simply because everybody else does. Switching to another CTR implementation will be hell if you don't.

Improve this answer
$\endgroup$
0
$\begingroup$

For CTR mode there shouldn't be any significant difference. However if you are looking at doing a performance test, it would be a good idea to consider the effect of system cache while measuring the encryption/decryption time. If your tests involved encrypting data in file, encryption requires disk reads. When you are performing the decryption operation there is a higher probability for the data to be still in cache memory and which would reduce the time to decrypt.

Here is a related answer to a similar question link

Improve this answer
$\endgroup$
2
  • $\begingroup$ This does not generally hold if you consider for example encryption of network traffic. Hence, a performance comparison should load the used data the same way for de- and encryption. $\endgroup$
    – mephisto
    Commented Sep 2, 2015 at 17:35
  • $\begingroup$ Agree. As you said, if we are talking about measuring encryption/decryption performance, these factors like disk reads, network traffic should be factored out. $\endgroup$
    – Nik
    Commented Sep 2, 2015 at 17:42

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.