On Thu, Sep 8, 2011 at 1:18 PM, coderman <coder...@gmail.com> wrote: [...] >> My question is... Why wasn't AES-NI taken advantage of by default? Why >> did I have to come across it by accident? > > some engines are actually slower than host optimized code. > > hw accel is experimental, and by default all providers in an engine > are used. aesni is specific (aes only) but something like pkcs11 could > use acceleration where not intended (montmult accel is fast but aes is > slow, for example). > > if an engine is loaded (device present) and fails there is no graceful > fallback, this could leave Tor broken in a way that is hard to > diagnose via logs or traces. by explicitly enabling this, you are > assumed to know what you're doing. > > probably other reasons i've overlooked...
The big reason that hardware acceleration isn't on by default is that when we tried it, we found that some versions of some hardware acceleration modules, on some versions of Tor, used with some versions of OpenSSL, made Tor crash ... and we weren't able to do a good job of tracking down which ones were safe. Probably a better approach would be to try to investigate which engines, when used with which versions of openssl, should be on by default -- and add infrastructure to look for those particularly and try to turn them on. Generally I'd limit this to things that are supported automatically on CPUs or in common chipsets: that is, to the hardware crypto acceleration that people are reasonably likely to have without knowing they've got it. I'd also err on the side of only enabling it with unusually recent versions of openssl, so as not to have to deal with all of the known bugs in older versions. I've added a bugtracker ticket for this at https://trac.torproject.org/projects/tor/ticket/4008 yrs, -- Nick _______________________________________________ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
