Does 3-DES take approximately the same time to encrypt 1B and 1KB?

Question

I am using 3-DES to encrypt some data in Java. I decided to run some tests and plot some graphics to decide how to optimally pack data for its encryption (see how encryption/decryption time behave depending on the length of the plain text), so I measured the time to encrypt one thousand Strings of incremental size (first one of length 1, second one of length 2, etc.) and then did the same the other way around (decrypt the first results).

I find that the decryption time increases with the size of the resulting plain text, although the time/character decreases as a rule. However, for encryption all the tests take approximately the same amount of time (it takes as long to encrypt a 2-character String than a 1000-character String, ~0.003 ms).

Is this something inherent to 3-DES, to how Java implements it or maybe I measured the time wrongly?

Answer 1

This is both a DES (or any block cipher) and a programming concern. It is not a problem, just something to be aware of.

The reason time/character decreases with larger plaintexts is that the initial overhead and memory management takes up the bulk of time with small inputs. With large inputs (megabytes+) the time/char will stabilize to a fairly consistent number. Memory management techniques and encryption mode of operation also effect overhead. Making a copy of the plaintext instead of reading its memory space directly into the block cipher state for example.

DES processes blocks of 64-bits, which is 8 bytes at a time. So your time per character between 0 and 8 will be the same, as it is processing a single block.

There is also the accuracy of the measurements, which in Java is probably not using a high precision event timer, and will therefore be extremely inaccurate in measuring events that take small fractions of a second to complete. Try using a hand stopwatch to measure something that takes 0.02s to complete for example, you will never get a consistent or even accurate measurement.

Because block ciphers are fairly quick in processing block inputs, you will need to process several megabytes of data in order to get a more accurate time/block. Try 8 million bytes to start. You will need to increment the data size to get to around 10s of processing time before you can get an accurate time/block.

Answer 2

One option is that your benchmarking code isn't exact enough to show the small differences. With long enough inputs the time should scale linearly with the number of 64-bit blocks.

However, with small inputs, like your 1 vs. 125 blocks, it is possible to see the symptoms you describe – scaling decryption time, but approximately constant encryption time. You may be using a mode of operation with a random IV. Random number generation can dominate encryption time, but is not needed when decrypting.

Another possible reason for seeing different scaling when encrypting and decrypting would be a mode that can be decrypted in parallel, but not encrypted. Namely, CBC or CFB. However, in that case you'd be seeing the opposite: encryption time scaling faster than decryption.

Answer 3

It's probably the generation of the IV that takes the time, not the 3DES encryption. 3DES encryption itself should indeed at least scale with the size of the plaintext.