Thor Lancelot Simon wrote:
On Thu, Oct 27, 2011 at 12:15:32PM +0300, Martin Paljak wrote:
You have not described your requirements (ops/sec, FIPS/CC etc) but if
the volume is low, you could take USB CryptoStick(s)
(crypto-stick.org), which is supported by GnuPG and what can do up to
4096 bit onboard keys, unfortunately only one signature/decryption
pair usable through GnuPG. Probably you can also stack them up and
populate with the same key for load sharing.
So this appears to be basically a smartcard and USB smartcard reader
built into the same frob. I can probably find a way to put it within
the chassis of even a fairly compact rackmount server without fear it
will come loose and take the application offline.
Unfortunately, it also appears to be unbuyable. I tried all three
sources listed on the crypto-stick.org website yesterday: two were
out of stock, while the third said something along the lines of
"low stock - order soon", walked me through the whole ordering process,
then said my order had been submitted -- without ever asking for
payment.
It's possible I might walk into my office next week and see two
crypto-sticks, provided free of charge, but I am not too optimistic
about that!
Is there a way to actually get these?
This sounds familiar to me: while the direct cost, per unit, of crypto
gear would seem very low when compared with mass market devices with the
same kind of electronics, crypto gear remains very difficult to procure
without a massive contribution to engineering costs incurred by the
supplier (for the crypto "added value").
Ultimately a crypto gear under discussion is merely a CPU plus a
rudimentary memory subsystem and an interface to a host (it may have a
separate keypad, and/or a key injection port). The packaging matters to
provide confidence that the secret/private keys remain "onboard".
Likewise, the API with the host is a can of worm about which you want to
avoid discussion, again to provide this "well informed sense of
assurance that information risks and controls are in balance".
This being said, there is indeed a practical security benefit of having
computations directly involving secret/private keys done by a CPU
unlikely to be infected by a Trojan. Security certification concerns put
aside, the architectural demands are no more elaborate than "a CPU
unlikely to be infected by a Trojan". From there, you either pay for the
certification gimmick, or you mend your own solution. This is the basis
for an "open source HSM" ...
Regards,
--
- Thierry Moreau
CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1
Tel. +1-514-385-5691
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
