Opened 4 years ago

Last modified 2 years ago

#15918 new enhancement

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

Reported by: yawning Owned by:
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: unspecified
Severity: Normal Keywords: tor-crypto, openssl, evp, lorax, sponsor8-maybe performance cpu
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

People have recently asked about VIA PadLock and cryptdev (#15503/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.

Child Tickets

Change History (4)

comment:1 Changed 4 years ago by yawning

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.

comment:2 Changed 4 years ago by nickm

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.

comment:3 Changed 2 years ago by dgoulet

Keywords: tor-core removed

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

comment:4 Changed 2 years ago by nickm

Keywords: sponsor8-maybe performance cpu added
Severity: Normal
Note: See TracTickets for help on using tickets.