[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:
> http://www.opensolaris.org/os/project/crypto/Accelerators/
> 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
mailing list:


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

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/