Re: [tor-bugs] #25124 [Core Tor/Stem]: Stem v3 Onion Service support

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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 maqp):

 Thank you for the detailed reply!

 > I doubt we'll expose this feature, we'll fix the bug instead.

 Does fixing the bug mean what you described in the first bullet point
 (fetch descriptor, increment revision counter by one and re-upload
 descriptor) works reliably and automatically? My concern is the fix is
 related to bullet point 3, and after the fix, Tor writes the revision
 counter state to a file similar to how `create_hidden_service` stores
 persistent keys to hidden service directory.

 > It's not something Stem needs to handle.

 Most developers using Stem will probably do fine with `NEW:ED25519-V3`.
 But there are examples where pre-generating private keys and deriving
 Onion URLs from those would be helpful.

 * With OnionShare, this would allow publishing Onion URL (e.g. on Twitter)
 for service that hasn't been yet brought online. The URL would act as dead
 man's switch for releasing documents. More about the feature here:
 https://github.com/micahflee/onionshare/pull/572

 * In TFC, a computer (call it Networker) that hosts Onion Service probably
 runs Tails that might not have persistence enabled. The private key /
 derived KeyBlob is delivered from another computer (called Source) over a
 unidirectional link. I'd rather not install Tor+Stem on Source, just so I
 can create KeyBlobs with Stem's `NEW:ED25519-V3`. I'd prefer the
 possibility to export key (generated by Source with `os.urandom(32)`), and
 use some pre-existing utility in Stem to convert that key to KeyBlob, that
 can then be passed to Stem. I can implement one by myself, but these two
 show there's demand for such utility.


 > At some point in the future, Tor may support offline key blinding for v3
 onion services:

 There's a lot to understand and I'll be digging into the documentation
 soon. But is it correct to say there are two kinds of blinding
     * Descriptor key blinding that's always present in v3 services (even
 when persistent `ED25519-V3: KeyBlob` is given to
 `create_ephemeral_hidden_service`), and that prevents Onion site Crawling
 / Introduction Point discovery unless the .onion URL is known?
     * Offline key blinding where lifetime of service is limited by
 directory services, and where new descriptors can only be generated by
 knowing the offline private key. (Does the client need anything other than
 the Onion URL to detect rogue services operating on compromised keys?)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25124#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs