From: cman@communities.com (Douglas Barnes)
Date: Sun, 1 Oct 95 18:54:35 PDT
To: norm@netcom.com (Norman Hardy)
Subject: Crypto hardware summary
Message-ID: <v02120d01ac94f4da72ff@[199.2.22.120]>
MIME-Version: 1.0
Content-Type: text/plain



[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.