Thanks Yawning,
I was trying to make due with the equipment I had laying around, but, anyways, I did learn a bit along the way. Thanks for your input.
On 3.5.15 0:40, Yawning Angel wrote:
On Sat, 02 May 2015 12:10:33 -0400 12xBTM 12xbtm@gmail.com wrote:
So, I deleted the /usr/local/ssl/ folder and went from there. I got the sudo make test going again, and it failed D: . So the last thing remains: How do I get/install that patch that supposedly corrects this?
...
Quoting from the README file:
Note that OpenSSL's cryptodev implementation is outdated, and there are issues with it. For that we recommend to use the patches below, that we have provided to the openssl project.
http://...
You're making it sound as if the patches are on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard'.
Anyway...
I haven't bothered to check if the patches apply cleanly, only that they weren't ever merged. Shouldn't be that hard to fix the patches if they've rotted.
According to one of the writeups linked, in 2013 cryptdev wasn't exposing a CTR-AES EVP engine. If this is still the case, the bulk of tor's AES calls will not benefit from the acceleration (Skimming the cryptdev code quickly, this would ultimately be a kernel issue).
The SHA acceleration will only help TLS, because the bulk of the SHA calls in tor don't use the EVP interface (For good reasons in the case of SHA1, and "it's a good idea, someone should do it" reasons for SHA256).
I'd expect in a lot of cases that the gains would be fairly minimal anyway, since using hardware acceleration with this configuration requires a syscall.
if there's a better way to go about having HW-accelerated crypto for Tor (excluding Intel aes-ni), please let me know.
Instead of some garbage TI part, use something that supports ARM-v8's AES, SHA1, SHA256, and VMULL instructions.
Regards,
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays