Previous Section  < Day Day Up >  Next Section

Selecting a Symmetric Cipher for Your Networking or Programming Needs

To summarize the presented data in a useful and helpful manner, we are going to compare the ciphers reviewed from a practical, system or network administrator's, or software developer's viewpoint.

Apart from DES, all ciphers we described are considered to be secure. 64-bit ciphers are viewed as somewhat obsolete after the appearance of multiple 128-bit algorithms, but there are no known efficient attacks against IDEA, 3DES, or Blowfish as long as the ciphers are fully implemented (as in no shortcuts are taken and no rounds are reduced).

3DES shows an adequate performance only in dedicated hardware implementations; thus, it could be fine to use if you have a tunnel between two or more such (legacy?) devices; for example, an IPSec tunnel between two Cisco 1700 routers equipped with MOD1700-VPN 3DES-supporting modules (novel AIM-VPN/Enhanced Performance [EPII] and AIM-VPN/High Performance [HPII] Cisco encryption modules support AES). Otherwise, do not be surprised when a VPN that uses software-based 3DES encryption brings your wireless network to a standstill by devouring CPU cycles of networked hosts.

IDEA is probably the second slowest cipher after 3DES. Whereas the original PGP used IDEA by default, the latest version of PGP (we use and recommend using GnuPG instead anyway) supports a variety of symmetric ciphers to choose from. Considering that IDEA is licensed, we do not see any particular reason to use this cipher, besides corporate politics.

Blowfish was not designed to work in environments where frequent key changes take place (e.g., many forms of packet-switched network encryption). It does not scale well for restricted memory size devices such as smart cards or mobile phones. This cipher was designed specifically with infrequent key change systems in mind. As such, it performs well in user password encryption cases (e.g., OpenSSH, OpenBSD /etc/master.passwd), when passwords should be changed once every three months or so. A password encrypted with Blowfish starts from the double "$$" sign and is significantly longer than a DES/CRYPT(3) encrypted or MD5-hashed password. Cracking tools such as John the Ripper support Blowfish dictionary attacks and brute-forcing, but the process of Blowfish brute-forcing is painfully slow. Thus, when large key sizes are used, Blowfish is highly secure.

As for the AES finalists, MARS, Twofish, and (in particular) Serpent exhibit very high security margins, and the Rijndael and RC6 security margins are adequate. Rijndael key setup time is the fastest, and Twofish key setup is the slowest among the AES finalists. Recall that Twofish originated from Blowfish and has a sophisticated key scheduling function due to the double use of the key. The rest of the candidates fall somewhere between Rijndael and Twofish in terms of key setup time and resource consumption. Thus, Rijndael is the most suitable cipher for per-packet key generation systems, whereas Twofish can be a source of packet delay. When implemented in dedicated hardware, Serpent and Rijndael are the most suitable ciphers. Rijndael has a performance advantage over Serpent when in output feedback modes. Serpent has a larger security margin then Rijndael and performs better in ECB. It could be the algorithm of choice in highly secure environments where specific hardware encryption appliances are available. RC6 and Twofish are average performers in hardware implementation, even though RC6 is reasonably fast in ECB mode. MARS performance in hardware was not impressive. Rijndael has the highest potential from parallel instructions execution in dedicated hardware. Both Rijndael and Serpent scale very well in low-memory devices, and Twofish is suitable to use in such appliances. RC6 has low ROM requirements, but is very RAM-hungry. MARS is ROM-hungry and slow on low-end processors. Thus, MARS and RC6 are not appropriate for low-resource devices such as smart cards.

As for software performance, there are several factors that affect it, both software- and hardware-wise. Low-level language implementation of ciphers is always more efficient than higher-level language cipher code, with a possible exemption of Serpent in Assembly and C (approximately similar performance). The performance of software implemented algorithms that use very common instructions is homogeneous through a variety of CPU architectures. If multiplication, squaring, variable rotations, and shifts are used by the cipher, its efficiency would vary greatly depending on these instructions being implemented in a used CPU and compiler supporting the CPU implementation of these instructions. These are the instructions of interest in three important processors:

Pentium II/III: shift left, shift right, rotate left, rotate right, variable rotation, multiply, add, graphics/ccc.gif subtract, and, or, not, xor, mov. Mov takes 3 clock cycles, the rest of the instructions graphics/ccc.gif listed uses 1. For comparison, on Pentium I without MMXtm technology multiplication takes graphics/ccc.gif 10 clock cycles. Itanium: int-memory (A): add, subtract, shift-left-add (shladd), and, or, not, xor; int-memory (I): extr, mux, shift left, shift right, shrp; int-memory (M): getf, setf2 floating point (F): xmpy - 5 clock cycles, the rest of instructions listed use 1 cycle. UltraSPARC: integer-processing unit (IU) IU0 - SLL, SLLX, SRL, SRLX IU0, IU1 - ADD, SUB, AND, OR, NOT, XOR load-store unit (LSU) LD 2 clock cycles, the rest of instructions listed use 1 cycle. For comparison sake, in the original SPARC architecture multiplication takes 50 clock cycles.

Before implementing any cryptographic solution, know your chips well! Look out for the arithmetic, logical, and data shift and rotation instructions supported. An extensive, if somewhat old list of CPU manufacturers is available at A helpful site containing x86 processor information is Practically all you need to know about instruction sets of Intel-manufactured CPUs can be downloaded in a PDF file from Data on the chip instruction sets of various manufacturers can be accessed at, and could be generally useful. You might want to take a look at your CPU to identify it better, in which case helps. Or, you might want to use software tools that can tell you which instruction set your CPU has. Examples of such software for the Windows platform include CPUInfo ( and CPU-Z ( CPU-Z has a nice and easy-to-search database on x86 processor instruction sets. Both CPUInfo and CPU-Z are free to download and use.

In total, Rijndael is the fastest software-implemented performer across all platforms, and RC6 is very fast when run on 32-bit processors that support multiplication and variable rotations and shifts (Pentiums II and III). MARS is an average performer dependent on CPU instruction sets supported, and Twofish is a platform-independent average speed and throughput cipher. Software implementations of Serpent are the slowest.

On the basis of what we have described, we have the following propositions on cipher uses.

In highly secure environments where you need a high safety margin plus resistance to unknown attacks and you have to use a software-implemented cipher (or use a cipher when writing software for such an environment), Twofish scales well on all platforms. MARS is appropriate on 32-bit CPUs supporting variable shifts and rotations and multiplications. If performance is an issue, AES with a large key size can be used instead.

In similar environments where the cipher implementation is done in hardware, Serpent seems appropriate.

For fast and reasonably secure encryption of data on Pentiums II and III, RC6 can be useful. Remember the scalability issues, but also remember that RC6 can have very secure huge keys (up to 2,040 bits) and still perform fast on the appropriate architecture. For encrypting user passwords (ECB mode), speed is usually not an issue, so the more secure Serpent, MARS, and Twofish are recommended, but old good Blowfish with a maximum key size would do a decent job.

AES is a good all-around cipher that is very appropriate for VPN encryption. Because AES is a standard, major manufacturers such as Cisco produce powerful hardware AES enciphering devices. AES is particularly useful for highly secure environments where packet-based or session-based key generation could be necessary. Secure wireless networking could provide a good example of such an environment: It might explain why the incoming final 802.11i WLAN security standard implements AES. Another area ruled by AES is low-resource devices, although Serpent might provide some competition as long as it runs in hardware.

Finally, remember that running streaming ciphers always has performance advantages over using block ciphers in feedback modes, but one has to ensure that a sufficiently large seed is fed into the PRNG core of the streaming cipher you plan to deploy for your network protection or add to your software.

    Previous Section  < Day Day Up >  Next Section