param: add bool parameter -ephemeraltoronion to generate ephemeral tor addreses

Saibato commented at 7:15 pm on July 31, 2020: contributor

We have for up till now generated in the torcontroler service call quasi static onion addresses instead of full ephemeral like we call them in doc/tor.md Those address would not have changed like those in torrc as long as the onion_private_key file we created at first creation of the tor address would not have been deleted or changed.

When we transition to ADDRv2 messages it makes sense to allow from a privacy perspective temporary tor address for as long the node is not rebooted or if we decide to go even further for every wallet to have there own onion address.

Saibato force-pushed on Jul 31, 2020

Add new bool parameter -ephemeraltoronion to prepare for ADDRv2 use.

This to make safe v3 address creation possible if we transit
to ADDRv2. If set, we generate ephemeral tor onion addresses instead
of quasi static ones, that are generated on node restart from the
static onion_private_key file we create with the first call in torcontroler.

3a9803f186

DrahtBot added the label P2P on Jul 31, 2020

Saibato force-pushed on Jul 31, 2020

Saibato commented at 7:44 pm on July 31, 2020: contributor

ff/ an example how to use this parameter

 0diff --git a/src/torcontrol.cpp b/src/torcontrol.cpp
 1index 84118b36e..3131e6793 100644
 2--- a/src/torcontrol.cpp
 3+++ b/src/torcontrol.cpp
 4@@ -532,7 +532,7 @@ void TorController::auth_cb(TorControlConnection& _conn, const TorControlReply&
 5         }
 6 
 7         // Finally - now create the service
 8-        if (private_key.empty()) // No private key, generate one
 9+        if (private_key.empty() || gArgs.GetBoolArg("-ephemeraltoronion", DEFAULT_EPHEMERAL_TOR_ONION)) // No private key, generate one
10             private_key = "NEW:RSA1024"; // Explicitly request RSA1024 - see issue [#9214](/bitcoin-bitcoin/9214/)
11         // Request hidden service, redirect port.
12         // Note that the 'virtual' port is always the default port to avoid decloaking nodes using other ports.

laanwj commented at 1:55 pm on August 2, 2020: member

This has been proposed before, but I still don’t think this is particularly useful:

You can already achieve this by deleting the private key file (~/.bitcoin/onion_private_key) before launch.
It takes quite a while to gossip a generated onion address over the network, the average run time of bitcoind is likely not long enough to get any incoming connections. So then, why create an onion service at all?

Saibato commented at 4:24 pm on August 2, 2020: contributor

This has been proposed before, but I still don’t think this is particularly useful: @laanwj …. not for v2 that was dismissed and like you said could be easy mitigated, but be assured you will want that in some form for v3, just a hint

the` average run time of bitcoind is likely not long enough to get any incoming connections

tyi, I had often probing inbound connections even after one restart when testing transition to v3.

sipa commented at 6:38 pm on September 14, 2020: member

@laanwj …. not for v2 that was dismissed and like you said could be easy mitigated, but be assured you will want that in some form for v3, just a hint

I have no idea what you’re trying to say here, or why the situation would be any different for v2 vs v3.

fanquake added the label Waiting for author on Sep 15, 2020

Saibato commented at 8:48 am on September 15, 2020: contributor

@sipa

I have no idea what you’re trying to say here, or why the situation would be any different for v2 vs v3.

I want not go further since i did not file a tor trac all those years and also doubt tor will ever change v3 directory and relay logic for an ip dox prone app as is.

tyi; while i dev’ed the base layer in tor support for c-ln some years ago, i stumbled upon an v3 tor edge case and when testing core and dev’ed my private v3 in old v2 ADDR ipv6 tunnel message non BIP tunnel patch, i saw it again against the ADDRv2 test nodes,

But aside all of this, genuine temporary V3 addr might be useful to have for one shot side synced pruned top version nodes that just want stealth tx or for those that are always behind a NAT but also want not there ip or region known but enable short time inbound they advertise by other means, ie, over c-ln invoices or DLC’s

btw, since AFAICS u came up with the wrapped in ipv6 v2 address PR #1174 after enable #1021 and use the OnionCat addr space , i really keen to know what was the motivation in first place to do it that way then?

sipa commented at 4:17 pm on September 15, 2020: member

while i dev’ed the base layer in tor support for c-ln some years ago, i stumbled upon an v3 tor edge case and when testing core and dev’ed my private v3 in old v2 ADDR ipv6 tunnel message non BIP tunnel patch, i saw it again against the ADDRv2 test nodes,

Ok, what is the edge case? I have a very hard time understanding you.

But aside all of this, genuine temporary V3 addr might be useful to have for one shot side synced pruned top version nodes that just want stealth tx

For broadcasting over Tor you don’t need a hidden service at all.

or for those that are always behind a NAT but also want not there ip or region known but enable short time inbound they advertise by other means, ie, over c-ln invoices or DLC’s

Agree, in theory that seems useful and feasible. But in practice I have not seen demand for such a mode of operation. It’s also independent of v2 vs v3.

btw, since AFAICS u came up with the wrapped in ipv6 v2 address PR #1174 after enable #1021 and use the OnionCat addr space , i really keen to know what was the motivation in first place to do it that way then?

It was an easy and somewhat standardized way of making the network relay onion addresses without protocol changes. Perhaps it was a mistake in retrospect, and we should have done something like BIP155 back then immediately, but that was not something I was considering.

ghost commented at 5:31 pm on September 15, 2020: none

not for v2 that was dismissed and like you said could be easy mitigated, but be assured you will want that in some form for v3, just a hint @Saibato Not sure why we will need new address on each restart for v3

Also sipa mentioned it will affect the way node works and end up not listening to anyone. We need a solution which doesn’t affect the functionality and also improves the privacy. I am not sure what kind of attacks are possible if same address is used for long time. I need to experiment more, research, consult few experienced people who are involved in things related to Tor like author of this post: https://www.hackerfactor.com/blog/index.php?/archives/896-Tor-0day-Finding-IP-Addresses.html

Saibato commented at 7:19 pm on September 15, 2020: contributor

@prayank23

it will affect the way node works and end up not listening to anyone

Its often just the seeders big address list view that u get at first start of your node and the randomness and addrman logic of outbound node selection can take a while to get you node considered for outbound, what will be your v3 service inbound That does not mean no one gets the ADDR mesg fast or sees your v3 address a bit local in the tor dir messages , we could even change the code, to prio v3 nodes if underrepresented in the connect list. But the main point i have here, is the problematic for outbound in general after a while of ADDR/ADDRv2 messages , if parts of the net get spoofed and MITM and see not the real chain.

need new address on each restart for v3

not need, more new v3 on restart should be the default, for privacy

author of this post: https://www.hackerfactor.com/blog/index.php?/archives/896-Tor-0day-Finding-IP-Addresses.html

My definition of 0-Day is a bit different and all what was mentioned in the link and by the author of it, is to my knowledge not news or surprising to tor devs. Tor bug trac is an ugly process and it can happen they don’t even mention u if u just hint. But hey if they care about fame when dev for Tor, Tor is probably the wrong place for that, i can not complain that they did not do there best to address bugs or patches I posted. imho.

BTW: A real 0-Day comes out of the blue, hits hard and drops your jaws @sipa .

Ok, what is the edge case? I have a very hard time understanding you.

An edge case is, when something happens only if special sequences of crafted or random probability events predate that event, if not the software works as intended.

For broadcasting over Tor you don’t need a hidden service at all.

Correct but that i don’t call sooooo stealth,,, My point is that i like to use temp on the fly tor nodes remote inbound that create there address like c-ln from a blob or trusted hash sequence or address key byes ( prove of key ) , from a hidden poller that forwards, further.

but that was not something I was considering.

yup shit happens, that;s why i say never rush and for myself i like harsh reviews and no bonus for commit counts, that’s why i often change my names and avatars, so never hesitated to call me out if i am wrong, :partying_face:

We have still some time until v2 fades out and that should be used to the limit, for review and testing. And if seeders would add there v3 addr now in chainparams.cpp and disable doxing ipv4 seeding if -onlynet=onion we would have even now out/inbound v3’s and could easy bootstrap full in Tor also with v3, that i would like and that would btw be a good testbed for the advertised seeders v3 nodes,

i.e.

 0diff --git a/src/chainparams.cpp b/src/chainparams.cpp
 1index ffd2076c9..4903e3bda 100644
 2--- a/src/chainparams.cpp
 3+++ b/src/chainparams.cpp
 4@@ -10,6 +10,7 @@
 5 #include <tinyformat.h>
 6 #include <util/system.h>
 7 #include <util/strencodings.h>
 8+#include <util/system.h>
 9 #include <versionbitsinfo.h>
10 
11 #include <assert.h>
12@@ -113,6 +114,7 @@ public:
13         // This is fine at runtime as we'll fall back to using them as an addrfetch if they don't support the
14         // service bits we want, but we should get them updated to support all service bits wanted by any
15         // release ASAP to avoid it where possible.
16+        if (gArgs.GetArg("-onlynet", "") != "onion") {
17         vSeeds.emplace_back("seed.bitcoin.sipa.be"); // Pieter Wuille, only supports x1, x5, x9, and xd
18         vSeeds.emplace_back("dnsseed.bluematt.me"); // Matt Corallo, only supports x9
19         vSeeds.emplace_back("dnsseed.bitcoin.dashjr.org"); // Luke Dashjr
20@@ -122,6 +124,11 @@ public:
21         vSeeds.emplace_back("seed.bitcoin.sprovoost.nl"); // Sjors Provoost
22         vSeeds.emplace_back("dnsseed.emzy.de"); // Stephan Oeste
23         vSeeds.emplace_back("seed.bitcoin.wiz.biz"); // Jason Maurice
24+        };
25+
26+        if (gArgs.GetArg("-onlynet", "") == "onion") {
27+        vSeeds.emplace_back("sipasv3onionaddressasdasdasdasdad.onion:8333"); // Pieter Wuilles onion v3 address
28+        }
29 
30         base58Prefixes[PUBKEY_ADDRESS] = std::vector<unsigned char>(1,0);
31         base58Prefixes[SCRIPT_ADDRESS] = std::vector<unsigned char>(1,5);
32u

sipa commented at 7:31 pm on September 15, 2020: member

@Saibato You never answered this:

@laanwj …. not for v2 that was dismissed and like you said could be easy mitigated, but be assured you will want that in some form for v3, just a hint

All I can see is you arguing that ephemeral onion addresses are useful, but nothing specific about v3. If there are specific arguments in favor of that, or “edge cases”, I’d like to see them spelled out concretely. Please don’t tell people to “be assured” without backing up your point.

Correct but that i don’t call sooooo stealth,,,

It’s the most private approach there is… you don’t have any identifier at all, not even an ephemeral one. I really don’t know what you’re trying to say. Please be specific.

not need, more new v3 on restart should be the default, for privacy

I think this is a bad idea. If you’re that concerned about privacy you should just disable listening entirely, and not create hidden services - not even ephemeral ones.

Creating new ones on restart makes the privacy/usefulness tradeoff dependent on how frequently your node restarts. If you restart all the time, it’s equivalent to not having a hidden service at all. If you never restart, it’s equivalent to having a persistent onion address. If this is an interesting tradeoff at all, it should be an option to configure how frequently to create a new one - but I don’t think that anything less than days or weeks even is useful.

Saibato commented at 8:08 pm on September 15, 2020: contributor

@sipa

It’s the most private approach there is…

Hmm, never trust the NSA footprints in Tor and Bitcoin?, I like chained inbound services created like in c-ln that can use the non clamped full edwards key space,

The standard keygen call we use now, id liked anyway replaced (PRNG and clamping) , to have full keys. But that would make bitcoin almost a privacy coin and then Wall Street and HRT might get mad at us?

@Saibato You never answered this: not for v2 that was dismissed and like you said could be easy mitigated, but be assured you will want that in some form for v3, just a hint

Sorry but i cant …

sipa commented at 8:14 pm on September 15, 2020: member

I like chained inbound services created like in c-ln that can use the non clamped full edwards key space,

I see no reason to deviate from standard cryptographic constructions for this.

If you want to have a reachable onion service but not have it result in an identity, just don’t advertize it.

My question above was why you were stating that not creating a hidden service at all is less private than an ephemeral one, but perhaps I misunderstood you.

ghost commented at 2:24 am on September 16, 2020: none

If this is an interesting tradeoff at all, it should be an option to configure how frequently to create a new one - but I don’t think that anything less than days or weeks even is useful. @sipa even I was thinking about having such option. Maybe if enabled it should either ask the user to save the time interval or randomly delete the file once in every few days. Random because it will avoid any pattern that someone may observe.

laanwj commented at 4:50 am on October 16, 2020: member

There seems to be agreement that there doesn’t need to be specific functionality for “ephermal onions”. If you do not want your node to be reachable on an onion address it’s best to disable -listenonion. There’s no point in having time-limited onion addresses in bitcoin, the time it takes to gossip an address and for other peers to really connect is long enough that it’s undesirable to repeat that process every time. So better to just disable it than bother with extra complexity to say, rotate private service keys.

And if you really, really want this functionality it can already be achieved from outside by say, a crontab, deleting the onion private key periodically and restarting bitcoind. Or even by managing Tor’s configuration yourself.

In any case I’m repeating myself here, closing this PR.

laanwj closed this on Oct 16, 2020

DrahtBot locked this on Feb 15, 2022

param: add bool parameter -ephemeraltoronion to generate ephemeral tor addreses #19635