-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Security risks with re-use of onion address #2005
Comments
Very logical idea. Just riffing here, since onion address is also being used for reputation...if it were to be created anew each trade, it could work if another less detailed system could be used to only represent successful/unsuccessful trades. eg +5/-2 , +9/-0 |
About the reputation: I think the onion address of the hidden service has been chosen because it is readily available and no further thought has been put on this. There is, however, a non-written plan to eventually use the private_key itself for identifying the user and her reputation (@ManfredKarrer) in order to support other networks as well (#1397). However, switching to the private_key makes no difference here as the onion-address is derived from the private_key. In general, a reputation of some sort does require a unique identifier, there is no way around. And the reputation (to my knowledge) gives the Bisq users a tool to judge whether the trading partner is going to fulfill her part in a fast and correct way (very similar to, for example, PGPs trust network). If a user wants to stay completely anonymous and therefore, no reputation data is available, she may have difficulties finding trading partners. Hence, if the user wants to stay anonymous, she has to accept that other people may not trust her. Aside from that: Given, the private_key is stored somehow encrypted (AES, RSA, ...):
technical feasabilityconsidering #1056 and its preparation work (#2009 ff.), we already have a solid base for the onion address being changed everytime Bisq is run. One hidden service per trade, however, remains a challenge... all in all
|
If someone can read your data directory you are already in a pretty bad situation. Basic security assumptions in Bisq is that your system is not compomised on that level. Your onion address cannot change if you have open offers, trades or disputes. For the reputation though we could and probably should use a seperate key pair to be more flexible and make it possible to renew the onion address without losing the reputation. But as @freimair mentioned reputation requires some sort of identity and that is usually in conflict with privacy. So you will not get both in a perfect way. But letting users choose what is more importent for them should be the way to go. Consider also that the main focus of Bisq it on the Fiat exchange side and here the bank details reveal your real life identity so some extent to the other peer anyway. With that in mind trying to get perfect privacy on the network side does not give you much as an undercover agent could easily just do a trade with your and find out your identiy. For altcoins though there is more headroom for a high level of privacy. But also here you should consider the Bitcoin-blockchain (and - if not a cryptonote coin - the altcoin-blockchain) as the weak element where it is very easy to lose privay and for most users who are not very skilled and knwoledgeable very hard to get good privay (e.g. coin merge, block explorer lookup, bloom filters,...). Atm we have many other high prio tasks to complete (new trade protocol, DAO, P2P network stability,...), so no dev resources to get into those rather sophisticated features. If you are a developer you are welcome to join and work on it. |
That topis is handled here #1056 as well. So I will close that as duplicate, but feel free to continue discussion on the othere issue. |
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 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.The text was updated successfully, but these errors were encountered: