[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: Slightly OT: where to get Crypto HW (long, detailed, ends w/questions...)
> SCA6000 is pci-e, so it will not work in a e450. The e450 does,
> however, have 64bit pci slots, so the old SCA-1000 would work there.
> However, the SCA-1000 does not do AES at all, even with the v2.0
> firmware, so my previous discussion (and ebay link) should be ignored.
> The (also discontinued, like the SCA-1000) SCA-4000 does AES, but does
> not appear to do AES-CTR.
> Finally, this page:
> shows that the BCM5825 will work in Solaris. I think this is the best
> option provided that the AES-CTR support it provides can be accessed in
> the same painless way that it can be in the T2 chips. Wyllys ?
Yes, the BCM5825 is supported by the crypto framework and would meet
the requirement for AES-CTR.
> The BCM5825 board, off the shelf, costs less than half of what the
> SCA6000 does ( $462.50 at www.abstractelec.com (see "pxs2510) vs. $1350
> ). A cursory review of the specs shows that they both run bulk AES @
> 1gbps and 12,000 RSA tps for the broadcom vs. 13,000 RSA tps for the
> sca-6000 ... smells like the same part, actually, but I can't confirm that.
I don't know if it is the same part or not, probably not if the price
diff is that great.
> But that begs two questions:
> - Do the crypto framework APIs (PKCS#11) efficiently use multiple
> compute sources, such as a dual-processor T2 system with four SCA-6000
> plugged in ? Wyllys ? :)
The dual-processor support would be provided by the kernel itself, not
anything in userland or the crypto framework. If there were multiple
accelerators, each would be registered in the framework as a unique
instance and each would then be treated as a single accelerator by
the crypto framework. This means that there is no multi-tasking/threading
amongst crypto processors for a given session.
You may get better answers to these questions from the crypto-discuss@xxxxxxxxxxxxxxx
> - Is any of this useful for any conceivable Tor traffic loads ? The
> fastest Tor node I have ever seen on the status page is (roughly)
> 100mbps, which is a lot, but ... more than a pair of modern quad-core
> CPUs can handle ? It's conceivable that even at 200 or 400 mbps you
> wouldn't need any kind of crypto hardware to supplant a pair of modern
The benefit I see is that individual packets are processed much faster.
Which translates to the node being able to handle many more transactions
for a given period of time. I think this should lead to greater
bandwidth utilization, but I don't know if it would approach 100mbps or
not, there may be other limiting factors that get in the way.
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk in the body. http://archives.seul.org/or/talk/