Is there a real purpose to use Twofish, Serpent or Threefish instead of AES?

Question

I am wondering if other ciphers like Serpent or Twofish or even Threefish have really an use in real life, because AES seems to be very efficient in most situations.

But for example TrueCrypt or VeraCrypt offer Serpent and Twofish to be the algorithm to encrypt your drive, so why would anyone choose those ciphers and not AES? (I know that Threefish is tweakable, therefore efficient in encrypting disks).

So to clarify my question: Is there a real purpose to use Twofish, Serpent or Threefish instead of AES?

Answer 1

Serpent is straightforward to implement with side-channel resistance due to the bit-sliced design. Because AES incorporates an S-Box that is most simply implemented as a lookup table, implementations of it tend to be prone to side-channel attacks.

Threefish was designed for the SHA-3 competition, and was intended to be a part of a sort of package of cryptographic primitives, including encryption, hashing, and a MAC. If you wanted a crypto library that didn't require implementing a whole host of different algorithms, Threefish might be a good choice.

One compelling reason to use AES is that many modern CPUs support the AES-NI instruction, which will make encryption with AES almost certainly faster than any other algorithm. A faster algorithm is mostly always better, but unless you are encrypting large amounts of data you will likely never even notice the difference. It might save a couple of cents on your power bill since AES-NI requires fewer CPU cycles.

Of course, as a user, these implementation details may be invisible. And the libraries you mentioned already implement a whole host of different algorithms, so that advantage is negligible in the situation you are concerned with.

Offering multiple options is generally better than a single option (within reason - too many choices is bad). It's a bit like asking why a restaurant has more than one item on the menu. Some people might not care for that one item, for arbitrary reasons.

For a point-by-point overview of why Rijndael was selected as AES instead of Serpent or Twofish, you can investigate these other related questions

Answer 2

In most cases, you should probably use AES, especially if there is hardware support.

In some cases, it might make sense to use one of the others. For example, the simplicity of Threefish would make sense for an embedded controller using a micro lacking hardware support for AES. Its lack of S-Boxes reduces the amount of ROM needed. If you don't need the tweaking feature, a partially pre-computed key schedule will require only a small amount of RAM. You can pre-calculate just the K[n] subkey (from K[0] through K[n-1]), then add in the subkey number "on the fly" as you inject the subkeys into the encrypt/decrypt operation.

Theoretically, you could do something similar with the tweak sub-values, if the amount of data encrypted/decrypted is small enough. (This is likely in an embedded controller.)

On the other hand, in an embedded application with pre-computed key schedules, I think it would make more sense to use different keys rather than use the tweak feature.

Also, when using a pre-computed key schedule, you should use CBC or other mode that uses an Initialization Vector.