[tor-bugs] #31777 [Core Tor/Stem]: Key blinding in onionbalance v3
Tor Bug Tracker & Wiki
blackhole at torproject.org
Wed Oct 2 10:03:30 UTC 2019
#31777: Key blinding in onionbalance v3
-------------------------------------------------+-------------------------
Reporter: asn | Owner: atagar
Type: defect | Status: new
Priority: Medium | Milestone:
Component: Core Tor/Stem | Version:
Severity: Normal | Resolution:
Keywords: tor-hs scaling onionbalance | Actual Points:
network-team-roadmap-september tor-spec |
Parent ID: #26768 | Points: 2
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Comment (by asn):
OK, there is some sad progress here. I read about priv key encodings and
reminded myself about the keyblinding.
Seems like stem's hazmat lib does not support the primitives we need, or
the private key format we need, and hence we can't do the blinding using
hazmat, or transfer blinded keys to stem using hazmat.
I also looked at pynacl but it also does not seem to expose scalar
multiplication primitives for ed25519 which are needed for blinding.
Hence, I have decided to use the djb ref implementation we use in Tor's
tests. It's slow, but it does the job correctly, and we don't really need
lots of speed anyway since we are only gonna be blinding keys once a day
or so. I also fully ported it to python3 (#31912).
In terms of interfacing with stem, I will need to pass stem the blinded
private key so that it can sign the descriptor signing cert. However,
again because hazmat does not support the privkey format we need, I can't
just pass the blinded private key.
This leaves us two options:
1) I either introduce the slow ed25519 implementation in stem, and do the
blinding in house (and also use it as a library to do blinding in
onionbalance, since it also needs the blinded public key to calculate
hsdirs). But this leaves stem with two ed25519 implementations which is a
bit messy.
2) I either do the blinding in house in obv3 using the slow ed25519
implementation, and export the ''descriptor signing certificate'' to stem
as a string, so that it can use it when making a descriptor. This is
cleaner and easier, but it results in a messy stem API for HSv3
descriptors.
Will need to think which approach to take.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/31777#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list