[tor-bugs] #25124 [Core Tor/Stem]: Stem v3 Onion Service support
Tor Bug Tracker & Wiki
blackhole at torproject.org
Sun Mar 4 11:22:25 UTC 2018
#25124: Stem v3 Onion Service support
Reporter: Dbryrtfbcbhgf | Owner: atagar
Type: defect | Status: needs_information
Priority: Medium | Milestone:
Component: Core Tor/Stem | Version:
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
Comment (by teor):
Replying to [comment:6 maqp]:
> Glad to hear you're feeling better atagar! Hi everyone,
> So the bug is related to applications where the Onion Service uses
persistent key but where the service goes online and offline frequently.
Examples of those include file transmission applications like OnionShare,
and instant messaging like Ricochet or TFC (that I'm working on).
> During development I noticed that by re-using a few times the same long
term v3 ED25519 private key (passed to
controller.create_ephemeral_hidden_service), would cause Stem to raise
> stem.OperationFailed(message = 'Failed to upload our hidden service
descriptor to %s' % ', '.join(failures)) stem.OperationFailed: Failed to
upload our hidden service descriptor to
F4263275CF54A6836EE7BD527B1328836A6F06E1 (UPLOAD_REJECTED)... <followed by
rest of directory services>
> I started to investigate this: I doubled delay between launched
services, and at the point of one hour, the UPLOAD_REJECTED stopped
happening. Example code and output here:
> The issue happens even with latest Stem dev build that includes
> Now this is a problem with the applications that are online for short
periods at a time. Say the computer or client crashes at start. User
shouldn't have to wait for an hour before they can relaunch the software.
> I have only skimmed Tor's source code and documentation, but it is my
understanding that the descriptor is uploaded with something called the
revision counter. From what I've read I've understood those mean that
descriptor for same service can be uploaded frequently if the bundled
revision counter is incremented every time. If the revision counter is not
incremented, new descriptor is only accepted after one hour when the
The Tor onion service should do one or more of these things:
* fetch and validate its own descriptor, and then use the revision counter
in that descriptor to pick a higher revision counter
* on failure, retry uploading with a higher revision counter (but that
places a lot of load on the network if the revision counter is high)
* keep the last revision counter in a state file, and use it to choose a
higher revision counter (this doesn't have to be a huge disk leak, because
you only need one number: the highest revision counter for the entire
instance - but it does leak some state)
> I'm using Tor 0.3.3.2-alpha (that should support v3 Onion Services), so
I'd assume the revision counter update not happening automatically is
related to feature not yet in Stem.
No, it's a bug in Tor.
> On a side note, if Stem indeed needs to manage persistent revision
counter, it would be very helpful if developers could access them via
something like response.rev_counter and provide them as arguments to
create_ephemeral_hidden_service, kind of like how persistent keys can be
I doubt we'll expose this feature, we'll fix the bug instead.
> The last thing I'd like to understand is the key expansion and blinding.
The private key's expansion function in the Gist I posted above was
modified from Tor's testing code. It works but I'm not sure if developers
should be doing all that: It's probably something Stem should handle, at
least with some helper function.
It's not something Stem needs to handle.
If you want Tor to generate your key blob, use "NEW:ED25519-V3", rather
than "ED25519-V3:" KeyBlob
Then Tor will tell you what the blob is, and you can store it, and feed it
back next time.
The blob is intentionally opaque: if you insist on creating your own key
blob, it's something you will have to handle yourself:
> Related to this is the key blinding aspect. It is my understanding the
Onion site crawling has been solved by uploading blinded (sub?)keys inside
the descriptor. It is not at all clear whether this is the job of
application developers, Stem, or Tor 0.3.3.
Blinding is implemented in Tor, using this algorithm:
At some point in the future, Tor may support offline key blinding for v3
When it does, it will probably be implemented like offline ed25519 relay
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25124#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs