I have also tried to this same argument in the past. A prompt counter argument that I have received was: why not use a standard cryptography co-processor that is already available in the market?
http://www-03.ibm.com/security/cryptocards/pcicc.shtml

Are FPGA/ASIC based initiatives re-inventing the wheel or actually trying to provide solutions to voids that cannot be (or are not being) addressed by existing implementation techniques?

I have been unable to provide generic and robust answers to such questions. The general question in the industry is “make or buy.” Whenever a company can buy, it usually does not prefer to make. This has been a stone wall that has prevented many of my efforts to introduce high-speed, jitter-sensitive processors in the civilian domain. I know that there are advantages but I have been unable to provide a conclusive answer. I think that this forum could be a nice place for arriving at such an argument. Such argument can greatly improve the adoption of FPGA/ASIC based cryptography subsytems in commercial systems.

I feel that valuable arguments can come from the validity of the following assertions:
1) ASIC/FPGA implementations can be optimzied for power-constrained. environments such as embedded systems (if you do not activate a circuit, its power consumption will be minimal);
2) ASIC/FPGA implementations can provide improved resilience to side-channel cryptanalysis such as power analysis and so on.
3) ASIC/FPGA implementations inherently have superior jitter properties.

I think that conclusive findings to the above arguments could provide a better justification for why such implementations are not “reinventing the wheel” in any manner.

Hope that these feedbacks will be useful.

The argument in this article should not be about raw speed. It should be that of cost ($) and jitter properties that are required when one goes down the communciation stack such as to the ATM layer, which is usually below the IP layer.

For real-time communciations (such as those for space communications, control systems, and SCADA systems), jitter is a greater evil than delay. Jitter can be understood as unpredictable delay. Imagine that you have to secure all GPS (Global Positioning System)communications with strong cryptography algorithm and provide a low-cost solution. Firstly, we cannot mandate every application to use a laptop for such implementations — the utility of embedded systems is proven and here to stay. Secondly, given the acute real-time requirements of GPS systems, what would be the best implementation you would opt for? I would bet on ASIC/FPGA implementations that are nicely dove-tailed with application-level software systems.

ASIC/FPGA implementations are inherently parallel in their operations — they are electronic circuits! The jitter characteristics of ASIC/FPGA would be far superior to any microprocessor that is required to execute multiple jobs. If we were to design a special electronic board with Pentium 4 processor and design the software module such that its shall only execute one job (which is to compute a cryptographic algorithm), then this hardware-software combine might possess similar jitter properties such as a similar, low-end ASIC/FPGA product. But, the cost of making such a hardware would be so prohibitive that nobody would make or buy such products. This is where the ASIC/FPGA advantage would be useful over a pure software system.

Additionally, this article may not be a stream cipher or block cipher debate. To make blanket statements that stream ciphers are not used for bulk encryption is incorrect. Do mobile phone networks use block or stream ciphers for bulk encryption on the network? I have designed a network-level, point-to-point bulk-encryption system that can use block or stream ciphers in order to cater to differing end user needs. If you have two-party communications, stream or block ciphers can be used. If you have more than two communicating parties, stream ciphers cannot be used nor can certain configurations of block ciphers that are not self-synchronous like OFB and CFB modes. If we are designing a cryptosystem for point-to-point communication applications that do not allow any form of message buffering and send very short messages, we will have to use stream ciphers. Very short messages may be messages that are 8-bits in length. We cannot have a secure 8-bit block cipher!

I do not believe in silver bullet solutions. Customized (or optimized) designs appeal to my beliefs and experiences. I have seen people in the industry trying to use IPSec for safety-critical real-time applications, which I believe are dangerous and wasteful attempts.

Bit-based stream ciphers are not used in software. There is whole bunch of stream ciphers that are word-oriented and use block-cipher like operations. They achieve better performance than block ciphers in software.

Have a look at the ECRYPT eSTREAM website where the world’s stream cipher experts have been slaving away for the past few years.

There’s a whole bunch of stream ciphers that encrypt 8 bits every 3-5 cycles on Intel Pentium 4 and later. Even AES is capable of 8 bits every 15 cycles.