Opened 8 years ago

Closed 3 years ago

#4008 closed enhancement (implemented)

Identify safe, common, useful openssl engines to enable by default

Reported by: nickm Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: crypto openssl tor-relay
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Ever since f0d4b3d1 (svn revision r5829) , all of our crypto acceleration is off by default, since we can't trust any given openssl engine to be secure, stable, and to run without crashing.

We should identify engines which it would be safe and useful to turn on by default, and have them be on-by-default. IMO the criteria should be:

  • It needs to be pretty common for a user to have the requisite hardware but not know about it. IOW, anybody who has bought a special-purpose board can configure it themselves, but people with CPU or chipset support for acceleration are likely not to have thought about it.
  • It needs to be really stable.
  • It needs to be pretty well distributed.
  • It needs to be using a recent version of openssl.
  • It needs to make an actual improvement to Tor's performance or security.
  • We need to be able to test it.

Good candidates to look at for a start IMO are aes-ni instructions.

We'll also maybe need a UI change to let people disable default engines and add extra ones.

Child Tickets

Change History (7)

comment:1 Changed 8 years ago by tmpname0901

Which engines have been tried and found to be crash-prone? Which have not yet been tried?

A related quick-fix is to provide 64-bit Windows executables. (I'm assuming that most users in Unix environments build their own Tor binaries.)

The OpenSSL crypto code is just plain faster when built for a 64-bit CPU (relative to the same CPU running a 32-bit binary), and 64-bit Windows systems are no longer a rarity. The cost in local system responsiveness while running a Tor relay on Windows would be greatly reduced by simply doing a 64-bit build of the same code that's being built now.

comment:2 in reply to:  1 ; Changed 8 years ago by nickm

Replying to tmpname0901:

Which engines have been tried and found to be crash-prone? Which have not yet been tried?

At this point, it's been a few years; I'd have to look it up.

A related quick-fix is to provide 64-bit Windows executables. (I'm assuming that most users in Unix environments build their own Tor binaries.)

The OpenSSL crypto code is just plain faster when built for a 64-bit CPU (relative to the same CPU running a 32-bit binary), and 64-bit Windows systems are no longer a rarity. The cost in local system responsiveness while running a Tor relay on Windows would be greatly reduced by simply doing a 64-bit build of the same code that's being built now.

This is worth opening a new ticket for. This is not a general "Make our crypto faster" ticket.

comment:3 in reply to:  2 Changed 8 years ago by nickm

Replying to nickm:

This is worth opening a new ticket for.

Opened as #4076

comment:4 Changed 7 years ago by rransom

Status: newneeds_information

AES-NI is now on by default. Are there any other ‘engines’ worth the trouble of writing a changes/ file?

comment:5 Changed 7 years ago by nickm

Keywords: tor-relay added

comment:6 Changed 7 years ago by nickm

Component: Tor RelayTor

comment:7 Changed 3 years ago by nickm

Resolution: implemented
Severity: Normal
Status: needs_informationclosed
Note: See TracTickets for help on using tickets.