Hardware Implementation of Encryption Algorithm

Question

In the abstract of the AES-GCM RFC, the following passage is prominently included:

[AES-GCM] can be efficiently implemented in hardware for speeds of 10 gigabits per second and above...

Is the ease/efficiency of hardware implementation a significant consideration in cipher suite or encryption mode? If so, how big a factor is it in the popularity of the system?

More practically, are there examples of common ciphers that present serious challenges in implementation? Or would this immediately discount them?

---

AES Competition

On the suggestion of the LateralFractal, I looked at the design evaluation criteria for the AES competition. There is a line that references hardware (the criterion is given as "Hardware and software suitability"). That being said, this still doesn't speak to the degree to which this criterion is taken into account.

---

DFC Example

This paper describing an attack on DFC seems to be a good real-world example. Seeing as this SO's own Thomas Pornin had a role in the cipher's development, I'd be curious hear:

• The severity of this proposed attack in the eyes of the community
• The response from the cipher authors
• Possible ways in which this attack could have been avoided

Answer 1

The AES competition received 15 candidates, two of which suffered from "academic breaks" (weaknesses that are only theoretical, but still demonstrate that the underlying block cipher is not "optimally secure"). The remaining 13 are, to my knowledge, still unbroken to this day.

Therefore, the choice of Rijndael had to be done for reasons other than security. Performance, in particular ease to implement efficiently on a number of software and hardware platforms, was what mattered in the end. Rijndael was chosen because it behaved well on many systems. On a PC, RC6 was faster, but on other platforms (RISC-based CPU like Sparc, 8-bit CPU on smart cards, FPGA...) Rijndael was faster/cheaper (RC6 requires a 32x32 bits multiplication, which is cheap when you already have it, not so when you don't). For that matter, DFC was worse, since it needed a 64x64 multiplication. The "attack" described by Harvey is more an observation that reduction modulo 2⁶⁴+13, though it can be done without a division (which would be even more expensive), can be difficult to do properly, i.e. without leaking information (see timing attacks).

Other informal criteria included the fact that Rijndael's key schedule was fast too (contrary to, say, Twofish), and that Rijndael's inventors were from a non-threatening, non-controversial, quaint little country (Belgium), thus more likely to lead to worldwide adoption.

---

As another example, pretty much all of the SHA-3 competition was about performance. All 14 second-round candidates are "equally strong" (we don't know how to break any of them, even in an unrealistic academic way) but they were not equivalent when implemented in software or hardware. The ultimate choice criteria were never made clear by NIST (and it seems they changed mid-competition), but the fact that Keccak is devilishly fast in hardware (ASIC/FPGA) was certainly instrumental to its victory.