5
$\begingroup$

I have a laptop without the AES-NI CPU instructions but with SSE4.1.

I'm using Linux and tried the (in-memory) cryptsetup benchmark to get the rough tendency which returned:

#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   101,4 MiB/s   159,6 MiB/s
 serpent-cbc   128b    52,7 MiB/s   203,4 MiB/s
 twofish-cbc   128b   126,4 MiB/s   176,1 MiB/s
     aes-cbc   256b   107,8 MiB/s   120,4 MiB/s
 serpent-cbc   256b    52,9 MiB/s   203,3 MiB/s
 twofish-cbc   256b   135,2 MiB/s   177,0 MiB/s
     aes-xts   256b   160,6 MiB/s   160,2 MiB/s
 serpent-xts   256b   181,2 MiB/s   188,6 MiB/s
 twofish-xts   256b   164,4 MiB/s   166,2 MiB/s
     aes-xts   512b   121,4 MiB/s   121,0 MiB/s
 serpent-xts   512b   181,4 MiB/s   188,6 MiB/s
 twofish-xts   512b   164,7 MiB/s   165,4 MiB/s

I'm very surprised:

  • AES has fewer rounds than Serpent so AES should be faster.
  • AES usage is much higher than Serpent so one could expect the Linux AES crypto module to be much more optimized than Serpent's.
  • There is no speed decrease with bigger key size in Serpent while there is in AES.
  • The tests I made 1 year ago on the same computer gave the same speed for AES but all Serpent entries were averaging at 50 MiB/s.
  • To my knowledge, there has been no huge enhancement of Serpent kernel module in the past year.

Would you trust this "benchmark"? If not, how would you explain the great results for Serpent?

Improve this question
$\endgroup$
6
  • $\begingroup$ What CPU do you have? Intel? AMD? How fast? Which architecture? $\endgroup$
    – CodesInChaos
    Commented Mar 19, 2014 at 12:39
  • $\begingroup$ Intel core 2 duo P8700 with 64 bits Archlinux. $\endgroup$
    – user12593
    Commented Mar 19, 2014 at 13:41
  • $\begingroup$ In that case the AES numbers are plausible (16 cycles per byte) compared to ~12 on i3 without AES-NI in the eBACS benchmark. $\endgroup$
    – CodesInChaos
    Commented Mar 19, 2014 at 14:59
  • $\begingroup$ Did you also benchmark Twofish? $\endgroup$
    – Richie Frame
    Commented Mar 19, 2014 at 19:24
  • $\begingroup$ Yes I did. On my computer it was always between AES and Serpent in terms of performances (except in CBC mode where twofish was the best at writing). AES is the standard and has been widely reviewed; Serpent is said to be even more secure than AES. I'll update my post to put everything in here. $\endgroup$
    – user12593
    Commented Mar 20, 2014 at 10:58

1 Answer 1

Reset to default
14
$\begingroup$

AES has fewer rounds than Serpent so AES should be faster.

The number of rounds by itself is meaningless. Some ciphers have a few complex rounds and others have many simple rounds. See my answer to Why does SHA-1 have 80 rounds? for a related explanation.

There is no speed decrease with bigger key size in Serpent while there is in AES.

The performance is determined by the number of rounds, and not directly influenced by the key-size.

The AES designers decided that 14 rounds are required for a 256 bit security level and 10 rounds for a 128 bit security level. So AES-256 is about 1.4 times as expensive as AES-128. If you add overhead the relative difference becomes a bit smaller.

The Serpent designers decided to use 32 rounds for all key sizes, so performance is the same for larger keys.

How would you explain the great results for Serpent?

When operating on a single block Serpent is more expensive than AES. This was one of the reasons why Rijndael was chosen over Serpent to become AES.

When operating on multiple blocks in parallel, Serpent profits from an implementation technique called bit-slicing. So Serpent is faster in modes that allow parallelization.

CBC encryption is sequential (You need the previous block of ciphertext to start encrypting a block), so Serpent is slow here. CBC decryption supports parallelism, since you already know the previous ciphertext block at the start, so Serpent is fast here.

XTS always allows parallelism since the encryption/decryption of different blocks is independent. So Serpent is fast in XTS mode.

It's also possible to implement AES using bit-slicing, but it doesn't profit as much as Serpent since it's possible to use lookup tables to produce an implementation of AES that's fast even for a single block. Some people prefer bit-sliced AES implementations since they avoid timing attacks associated with lookup tables.

Improve this answer
$\endgroup$
2
  • $\begingroup$ I just want to confirm that: when it was said that Rijndael was faster than Serpent, this was per block wasn't it? That would mean that I can use Serpent to encrypt my new HDD without expecting much performance loss compared to AES. Again, just to make sure I grasp what you meant, when you talk about parallelism, do you mean making use of intrinsic functions? $\endgroup$
    – user12593
    Commented Mar 19, 2014 at 13:51
  • 3
    $\begingroup$ @Gael With parallelism I mean that you have the inputs for multiple blocks (with 16 bytes each) available at the same time. In that case you can call a (single threaded) function that takes e.g. 32 blocks and produces 32 encrypted blocks. This function is cheaper for Serpent than encrypting 32 blocks individually. Using Serpent-XTS should be faster than AES-XTS on your current hardware, but once you get a AES-NI capable CPU AES will pull ahead. $\endgroup$
    – CodesInChaos
    Commented Mar 19, 2014 at 15:34

Your Answer

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