Opened 4 weeks ago

Last modified 2 weeks ago

#31777 new defect

Key blinding in onionbalance v3

Reported by: asn Owned by: atagar
Priority: Medium Milestone:
Component: Core Tor/Stem Version:
Severity: Normal Keywords: tor-hs scaling onionbalance network-team-roadmap-september tor-spec
Cc: s7r, gk Actual Points: 1.5
Parent ID: #26768 Points: 2
Reviewer: Sponsor:

Description

Need to implement key blinding for v3 onions in onionbalance (or stem).

There are already some tests in little-t-tor about it but they seem to be using a custom ed25519 implementation, whereas stem is using hazmat:
https://gitweb.torproject.org/tor.git/tree/src/test/ed25519_exts_ref.py#n34

Need to decide whether I should do the same for hazmat, or adopt the custom ed25519 implementation. Most probably the former.

Child Tickets

Change History (5)

comment:1 Changed 4 weeks ago by teor

I don't think cryptography.hazmat exposes the primitives you need:
https://cryptography.io/en/latest/hazmat/primitives/asymmetric/ed25519/

comment:2 Changed 2 weeks ago 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 since the key blinding is already implemented there, 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.

Last edited 2 weeks ago by asn (previous) (diff)

comment:3 Changed 2 weeks ago by asn

Actual Points: 1.5

comment:4 Changed 2 weeks ago by teor

Here's my opinion:

  1. Let's do as much as we can in stem, and expose a clean interface to Onion Balance v3
  2. Let's use the reference implementation in stem, until python cryptography grows its own
  3. Can we convert from the blinded format to the format that stem needs for signing? How does Tor do it?

comment:5 in reply to:  4 Changed 2 weeks ago by asn

Replying to teor:

Here's my opinion:

  1. Let's do as much as we can in stem, and expose a clean interface to Onion Balance v3
  2. Let's use the reference implementation in stem, until python cryptography grows its own

Agreed, will take this approach for now!

My plan for now is to write a small wrapper on top of the reference implementation that exposes objects that behave like the hazmat keys (in terms of duck typing expose sign(), verify(), public_key() methods) so that they can be used interchangeably in the hsv3 parts of the stem codebase.

  1. Can we convert from the blinded format to the format that stem needs for signing? How does Tor do it?

We cannot do that because hazmat has a different private key format (stores the seed) than the blinded key format (stores the private scalar). And you cannot go from the blinded key format to the hazmat format (you can't compute the seed from the private scalar). It's a mess but I can describe more if you want. Some more info: https://blog.mozilla.org/warner/2011/11/29/ed25519-keys/ and https://trac.torproject.org/projects/tor/ticket/28123#comment:4

Tor uses a custom implementation of ed25519 donna that supports the private key format we use, and donna also exposes the primitives we need.

Thanks for the feedback!

Note: See TracTickets for help on using tickets.