[A summary of my points on crypto hardware follows my response to Norm.] Norm Hardy writes:
What key length are you using that takes 3.2 sec? The DSP can operate concurrently with other processing, giving an improvement greater than 3.2/1.9.
I'm aware of this -- I was using Tim's pessimistic estimate of improvement... to make it clearer for those who didn't read his post, I should have said, "Even if the reduction is only from 3.2 seconds to 1.9 seconds, it would be significant for someone running a server." I'm aware that with DSPs you can get rather better results; an ASIC will get you another order of magnitude over DSPs (assuming equivalent price -- the Moto 96K DSP is a real gem for bignum math but is many times more expensive than an equally effective ASIC. They were also having serious availability problems last year...) Here is a summary of my points on this subject to date, for those who haven't been following this discussion: o Using coprocessors of any sort to achieve speed in cryptography operations is probably not justified for end users; it is almost always justified for servers with a high volume of transactions requiring public key authentication or encryption. o DSPs are not really as attractive as general purpose CPUs for accelerating cryptography for high-volume servers. Although DSP architecture is somewhat more conducive to bignum math, the benefits seem to be offset by the wide availability of standard CPUs and tools for programming them. If a large increase in speed is desired without resorting to single-purpose hardware, I recommend using a large number of standard CPUs as coprocessors, rather than an equivalent approach with DSPs. (The fact that uint multiplies on a 486 take multiple clock cycles is offset by the higher internal clock speeds and lower cost of the 486. You can point out super-fast DPSs, and I can point out their super-large price tags, more expensive tools, and substantially more expensive programmers.) o The real way to go for speed is ASICs, which give you much better bang for the buck, although they have disadvantages, including problems of export, inflexibility, etc. My favorite RSA chip board so far is from Uti-Maco in Belgium, which is a tamper-resistant add-in card with a 8086-compatible controller and a custom BIOS for doing RSA and DES operations in h/w, which allows s/w to be developed using standard tools. (I have ranted at length about the complications involved with _Beligan_ crypto export controls, which seem to stem from NATO pressure and US desire to balkanize the market for cryptography products.) o People doing valuable transactions on servers are going to want tamper resistance and hardware-key security. This is more important in some cases than speed, although speed is also very important. o People running cryptography-based transaction clients on their PCs are going to learn, one way or another, that having valuable secret keys on their hard disks is not a great idea. This, not speed, is the primary motivation for consumer-oriented cryptography hardware. People want their keys and financial transactions on secure, removable, non-mechanical media. Products that provide this are just starting to come on the market, notably from National Semiconductor and Telequip. o End-user software will need to be written to allow, but not require, external cryptography devices. Consequently, consumer software that performs valuable transactions still needs to be written in an extremely paranoid fashion with respect to the reliability and security of the underlying hardware.