John Case wrote: > > On Mon, 12 Oct 2009, Wyllys Ingersoll wrote: > >>>> "tor is actually cpu-bound rather than ram-bound on the fast relays i >>>> think you should be able to push 10MB/s in 1G of ram" >>>> >>>> So crypto-acceleration appears to be useful. >>>> >>> The symmetric-key processing is very fast and takes up little >>> CPU time. >>> The apparent hangup on the high-rate relays is the asymmetric-key >>> processing >>> (i.e., onion-skin encrypting/decrypting). FWIW, when I was running a >>> relay, >>> it could be running at rates over 300 KB/s while using less than 1% >>> of the >>> CPU when it was simply passing cells back and forth among the various >>> connections. When new onion skins came in to be decrypted was when >>> tor would >>> suddenly use much more CPU time for a moment or two. > > > You discuss the performance benefits of using the AES CTR in hardware > below, but before I get to that, I wonder if you experienced the same as > what is quoted just above: that the real CPU load occurs during "the > asymmetric-key processing (i.e., onion-skin encrypting/decrypting)" and > that that is the only area where we can attempt to speed things up with > hardware ?
I think that is correct. > > Thank you very much for your testing, blog post, and this exchange. > > So, if I understand correctly, the HardwareAccel option can be turned on > by anyone, regardless of OS or hardware platform. It will then > (probably) just do AES CTR with OpenSSL (since most people use OpenSSL) > and just get no benefit because OpenSSL won't do AES CTR through hardware. Correct. The counters are updated in software so the benefit is minimal. > So, even if I got a BCM5825 working with with the ubsec driver on > FreeBSD, and used HardwareAccel, it would just be wasted with OpenSSL. Correct. > > On the other hand, there are Solaris-specific routines (crypto framework > APIs (PKCS#11)) built into Solaris that Tor can call instead of OpenSSL, > which _will_ do AES CTR in hardware, yielding a huge gain in performance > (you mention 25x). > > Do I have all of that correct ? > Yes. > If so, some follow-up questions that I hope will be of help to others: > > > - Are there analogues to the "crypto framework APIs (PKCS#11)" in other > OS's ? What is this layer called for Linux, for instance ? For FreeBSD > ? Or is hardware AES CTR with HardwareAccel something we're only going > to see on Solaris for now ? There may be hardware accelerators with drivers for Linux and FreeBSD that offer AES CTR, but I'm not familiar with the offerings on those platforms. > - How does the T2 (Niagara 2) compare to dedicated hardware such as the > Sun Crypto 6000 which is currently available ? Presumably the crypto > framework APIs will use whatever is available, whether it be a SCA-60000 > or a Broadcom based card or ... ? I don't think the SCA6000 offers AES CTR support. The N2 (T2) crypto chips are newer and offer more algorithm support and faster performance. You are correct, though, we (Solaris security) do strive to offer crypto framework support for the underlying hardware devices. > - Am I correct that if a new version of OpenSSL appeared with AES CTR > hardware support, an end user could just proceed blindly with card > insertion, driver install, add HardwareAccel=1, and poof! Yes ? Yes, in theory that would be the ideal solution. I think there are some patches floating around that do add AES CTR to OpenSSL, but I don't think any have been yet accepted into the main openssl codebase. Even so, it would also require a hardware engine that could support AES CTR in order to get the full benefit. > If I am correct in the above, it would appear that there is a nice, > platform specific feature in Solaris to complement a specific CPU > feature in T2 (and later, I hope) processors, and that the correct path > for the rest of the world is to lobby OpenSSL to implement hardware AES > CTR so we can just plug and play. Yes, I think that sums it up nicely. > Thanks very much for your help and contributions. No problem, I hope it was helpful. -Wyllys *********************************************************************** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/
