Investigate using the EVP interface for non-oneshot hash calls.

People have recently asked about VIA PadLock and cryptdev (#15503 (moved)/some random tor-relays@ post). Both of these things in theory can do SHA1/SHA256 in hardware (though in the case of cryptdev, performance is likely to be worse).

Since it can be a decent gain (at least PadLock will be), we should consider switching over the crypto_digest_t routines to use the EVP interface (People that try to use cryptdev for hashes and suffer a performance decrease did not read the documentation, and thus get what they deserve).

Minor (very low priority) because:

• cryptdev's hash performance will probably suck.
• OpenSSL does not support PadLock SHA acceleration.
• The only hardware SHA implementation that's actually relevant to a significant sized userbase (ARMv8) is supported via the raw SHA* routines.

So this is mostly for future-proofing and code cleanup purposes.

changed milestone to %Tor: unspecified

added component::core tor/tor cpu evp lorax milestone::Tor: unspecified openssl performance priority::low severity::normal sponsor8-maybe status::new tor-crypto type::enhancement version::tor unspecified labels

First cut: https://github.com/Yawning/tor/compare/evp_digests

Notes:

• Not ready yet (compiles and unit tests pass).
• crypto_digest_assign is probably uglier than it needs to be.
• Someone should figure out a good criteria for "use EVP vs the raw SHA interface" that can be ran at runtime. If it were up to me, I would rip the old code out and always use the EVP interface, since it's simpler (and would make fixing the ugly dead easy...).

It's lorax tagged because this is about as much time as I feel like spending on it right now.

It would be good to know, via profiles, how much of our time is spent on these hashes for what reason.

For example, if most of our time in these hashes is via TLS, then we already have the optimizations for free, I believe.

OTOH, if most of our time in SHA1 is because of its use in OpenSSL's silly PRNG, we should probably consider replacing the aforementioned PRNG wholesale.

Only if in-Tor usage is a majority, and it's majority non-oneshot, should we follow this thread.

The tor-core keyword doesn't really make sense now that we have "Core Tor/Tor" for component.

Trac:
Keywords: tor-core deleted, N/A added

Trac:
Reviewer: N/A to N/A
Keywords: N/A deleted, sponsor8-maybe performance cpu added
Severity: N/A to Normal
Sponsor: N/A to N/A

moved to tpo/core/tor#15918 (closed)