[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