> > The only justification these days I have for crypto is for embedded
> > devices that need accelerated crypto for VPN, and smart-cards or USB
> > crypto-tokens that protect RSA private keys from the host computer.

Opps, that was a typo on my part.  I meant to say that "The only
justification these days I have for hardware-accelerated crypto is for
..."                                ^^^^^^^^^^^^^^^^^^^^

> There are many such embedded/small-CPU devices (not just for VPN, mind
> you) that need low power consumption, which is certainly not an
> amd64-type-CPU strong suit.  A CPU of the power you mention is a *very
> very bad* fit here; typically these machines are 486 or Pentium-II
> generation at best.  It's like comparing pears vs. tangerines, or
> something like that.
> Now, show me a complete amd64-based machine in the ballpark of the
> speed you mention, using less than 2A of current @ 5VDC, and we'll
> talk.  8-)

Actually, on the embedded side, I have been using Renesas SH2 & SH3
boards lately, that contain some built-in crypto hardware acceleration.
So there is no need to convince me about the benefits of hardware-
accelerated crypto on tiny embedded devices, since I use it myself.

> Aside from power consumption, there is also the issue of physical
> volume.  Putting another machine in a rack just to do crypto--even if
> you found it on the street--could very well end up costing a lot more
> in colocation fees than a crpyto card would.  This is especially true
> in parts of the world with government-owned PTTs, etc.  All things
> considered, if you have a few crypto cards, the price differential
> could scale geometrically.

Co-location has never been an issue for me since I primarily deal with
the financial sector, including banks and credit card agencies, all of
which are legally required to host all of their own equipment on their
own premises, and thus cannot colocate.  These days, data is as important
as money.  So you would not expect a bank to colocate its cash at an ISP
or telco trunk.

> This is saying nothing about a PC having many more points of failure
> than a PCI card.  I doubt that any x86-based machine which is reliable
> as a crypto card would save anyone much money.

Although I typically do a lot of clustering with multiple redundant
machines and load balance them.  AMD64's are so cheap these days,
and you can get them in cute (tiny) cases.  It's a shame not to get
a few at a time.  ;^)

> Yes, if you are a crypto nut, and/or you are trying to do only
> networking things, then your argument holds. 

YES, I definitely consider myself a crypto-nut!  A while back, I did
write my own my own cross-platform SSL/TLS, ASN.1, CMS & TST library
and applications entirely 100% from scratch in C, which I mostly use
on embedded devices that choke on OpenSSL, or CMS (Cryptographic
Message Syntax) applications which OpenSSL does not fully support.

Back in late 2004, I needed to set up a financial TSA (Time Stamping
Authority) that was able to generate over 80 millions ISO-18014-2 time-
stamps per month, containing digital signatures from a 2048bit RSA key,
and also handle bursts up to 10000 time-stamps per second.

Even though these time-stamps were only used to prevent back-dating
and forgery of financial transactions, since I was dealing with a
country outside of North America and Europe, getting all of those
export licences for crypto-cards would be very onerous, costly, and
time-consuming.

Using load balanced clusters of inexpensive AMD64 machines with fast
software crypto did the trick for me.

Besides, now that I live in Japan which has some of the worst crypto
export restrictions, and I typically travel throughout Asia-Pacific,
software crypto on fast machines is the easiest and best way to go
for me.

Alicia.