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 teor):

 Replying to [comment:9 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.

 We haven't decided yet. When we do, we'll open a ticket and update this
 ticket.

 > > 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.

 Stem accepts patches.

 > > 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?)

 No, there is no difference between the cryptography or protocol for online
 and offline keys.

 In both cases:
 * The blinding is the same
 * A service must know the master private key to generate the daily blinded
 keys
 * The daily keys limit the amount of time that a service can continue to
 run without the master key
 * The key blinding protects the onion address from HSDirs

 If the master key is online with the service, then it is used to generate
 blinded keys, and the lifetime of a compromised service is unlimited.

 If the master private key is offline, then the lifetime of a compromised
 service is limited by the number of pre-generated blinded keys that are
 compromised with the service. Once it runs out of blinded keys, it can't
 generate valid descriptors for its onion address.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25124#comment:10>
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