[bisq-network/bisq] Security risks with re-use of onion address (#2005)

[qubenix]

Some discussion here: http://bisq.community/t/why-re-use-onion-address/6670.

It's better for user privacy and security if onion addresses are not re-used (aka 'ephemeral'), and if Bisq does not know or store the private key for the onion address. This can be achieved with `DiscardPK` flag, and makes sense if Bisq is using the system's Tor or the bundled Tor.

In either situation the privkey is stored in `/.local/share` and readable to any other software run by the same user. This would solve that security issue when using the system's Tor, when using bundled Tor you should think about encryption for the privkey as mentioned in the forum post.

Creating a new onion address on each run is also better for user privacy against adversaries on the network, and probably for other reasons I'm not aware of. It is mentioned in the [Tor friendly applications best practices doc](https://trac.torproject.org/projects/tor/wiki/doc/Tor_friendly_applications_best_practices) to keep onion services ephemeral.

It was mentioned in the forum that the onion address is used as an identifier for reputation. This is concerning since the privkey is so easily readable. Compromise of the privkey could allow an attacker to mimic the onion address of the victim. I'm not sure what the complete implications are there with regards to Bisq and the reputation system.

It may make sense to come up with another identifier. For instance, `lnd` (I only use this example because it's another system I'm familiar with where the identifier is critical for use) is using a specific path from the wallets seed to [derive the identity_pubkey](https://github.com/lightningnetwork/lnd/blob/master/keychain/derivation.go).


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/bisq/issues/2005
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20181129/1e267704/attachment.html>