Hi,
How long time can we spend signing status documents before tor gets sad?
I ask because I'm planning on putting dirauth signing keys on a sloooooow HSM and would like to understand if I'd have to make format_networkstatus_vote() and networkstatus_compute_consensus() (and their callers) be "restartable", much like dirvote_act() is "restartable".
Current measurements indicate a worst case figure of 6.5 seconds for a hashing and signing operation. This may even increase some over time. (It may also shrink considerably with some optimisations but this is where we are today.)
On 15 Apr 2018, at 07:38, Linus Nordberg linus@torproject.org wrote:
Hi,
How long time can we spend signing status documents before tor gets sad?
I ask because I'm planning on putting dirauth signing keys on a sloooooow HSM and would like to understand if I'd have to make format_networkstatus_vote() and networkstatus_compute_consensus() (and their callers) be "restartable", much like dirvote_act() is "restartable".
Current measurements indicate a worst case figure of 6.5 seconds for a hashing and signing operation. This may even increase some over time. (It may also shrink considerably with some optimisations but this is where we are today.)
Connections and circuits might timeout over that 6.5 seconds.
Can you shift the signing to its own thread? Or make it asynchronous?
Tor has cpuworkers, which could be used to do signing work.
T
teor teor2345@gmail.com wrote Sun, 15 Apr 2018 08:48:01 +1000:
Connections and circuits might timeout over that 6.5 seconds.
OK, good to know.
Can you shift the signing to its own thread? Or make it asynchronous?
Tor has cpuworkers, which could be used to do signing work.
Some non-blockingness would be required, yes.
An asynchronous cryptographic tokens API would be useful but if we're unable to pull that off, having a cpuworker blocking on the call would be a solution.
-
Linus Nordberg -
teor