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
Proposal for reworking the way onion paths are created #596
Comments
@zugz the risk here is "only" that an attacker can possibly know what friends we are connected to. so our friendship net. is there also a DoS possibility? that the attacker can make our messages never arrive at the correct friend? |
* Sunday, 2017-09-10 at 07:35 +0000 - Zoff <notifications@github.com>:
@zugz the risk here is "only" that an attacker can possibly know what friends we are connected to. so our friendship net.
*If* we're connected via TCP relays which the attacker doesn't control,
then yes. Otherwise a deanonymisation attack is also possible - see the
"current implementation" section in the proposal for details.
but the message contents are safe.
To my knowledge yes, in all cases.
is there also a DoS possibility? that the attacker can make our messages never arrive at the correct friend?
The only DoS attack that I know of is that an attacker can occupy our
announce neighbourhood and pretend it hasn't seen us when others ask.
This prevents us receiving friend requests. If a friend of ours is
simultaneously attacked in same way, then we and the friend won't be
able to find each other. This is a serious problem, and there are ways
we could try to mitigate it, but it's a separate issue which this
proposal doesn't touch on at all.
|
If the attacker has access to the users ISP, then yes. A silent DoS would be trivial.
This is correct, (the birthday attack still applies)
You could use this attack to learn/confirm a friends list. There's also another attack that would allow you to force any DHT node it's friends list. Combining the two attacks, you could trivially, and silently, DoS selected connections at will/whim with very little resources. |
Couple of things about proposal:
Could you add some definitions section or something to make it easier to understand? |
Just to throw it somewhere, don't you think creating multiple DHT nodes can be substantially slowed down by involving some computationally heavy operation? |
* Monday, 2017-09-18 at 19:56 -0700 - Nazar Mokrynskyi <notifications@github.com>:
Could you add some definitions section or something to make it easier
to understand?
I just added an "overview" subsection to the "proposed system" section;
hopefully it clarifies things?
|
* Monday, 2017-09-18 at 18:55 +0000 - Gregory Mullen <notifications@github.com>:
> The only DoS attack that I know of is that an attacker can occupy our
> announce neighbourhood and pretend it hasn't seen us when others ask.
You could use this attack to learn/confirm a friends list. There's also
another attack that would allow you to force any DHT node it's friends
list. Combining the two attacks, you could trivially, and silently, DoS
selected connections at will/whim with very little resources.
Could you explain these attacks a bit more? Are you assuming the
attacker can observe the target's network traffic for the first attack?
What's the second attack?
|
* Monday, 2017-09-18 at 21:18 -0700 - Nazar Mokrynskyi <notifications@github.com>:
Just to throw it somewhere, don't you think creating multiple DHT nodes
can be substantially slowed down by involving some computationally
heavy operation?
Proof-of-work would help against some of the attacks, yes. But there's
always the problem of choosing the parameters to make attacks
sufficiently difficult while not inconveniencing ordinary users too
much, and having this remain the case as hardware improves. Anyway, it
wouldn't help much against attackers occupying the announce
neighbourhoods of particular targets, since we can assume the attacker
is willing to spend the necessary resources. They could also precompute
enough keys to quite densely cover key space, such that they have some
quite close to any given point.
|
It does, thanks!
Definitely, but I think this is an interesting area to explore, not only for anonymity and security, but also for robustness and scalability. |
@irungentoo Can you have a look at this proposal? |
I've just added a section on the problem with the current DHT eviction https://github.com/zugz/tox-onionPathsProposal/blob/master/onionPathsProposal.md I now believe that the proposal deals with all feasible attacks aimed at If anyone can see any remaining vulnerabilities, or ideas for |
@zugz if the save format changes, will the be a migration function in toxcore? so that toxcore can see what version is used, and also migrate on future changes. |
@zoff99 Saves are already marked with what version they were saved at: Line 2665 in 0fce3fc
https://toktok.ltd/spec#state-format |
@robinlinden excellent. so we just need to migrate that when loading |
Well, everything boils down to building a DHT that is resistant to an active attacker. DHT node should be able to protect itself from neighborhood poisoning even at early stages of operation. In one of the issues I've already mentioned Brahms: Byzantine Resilient Random Membership Sampling: https://gnunet.org/sites/default/files/Brahms-Comnet-Mar09.pdf |
* Sunday, 2017-11-26 at 13:40 +0000 - Nazar Mokrynskyi <notifications@github.com>:
Well, everything boils down to building a DHT that is resistant to an
active attacker. DHT node should be able to protect itself from
neighborhood poisoning even at early stages of operation.
Yes. It's true that poisoning the DHT is a way to attack the onion, and
that what I'm proposing for the DHT doesn't actually make it immune to
poisoning, just more expensive to poison.
You can still bombard a node with Nodes Requests from nodes you create
using random DHT pubkeys, until eventually you hit upon the right keys
and they add your nodes. A more subtle but less effective attack is to
bias the closelists of peers by responding to Node Requests with
information about only your own nodes.
(These are the manifestations in Tox of the 'push' and 'pull' poisonings
discussed in the Brahms paper.)
In one of the issues I've already mentioned Brahms: Byzantine Resilient
Random Membership Sampling:
https://gnunet.org/sites/default/files/Brahms-Comnet-Mar09.pdf
Thanks for pointing to this again. It does have some interesting ideas
which may well be applicable. It looks like we could even implement much
of it without breaking backwards compatibility (though not the "limited
send" component).
I think for now we should leave making the DHT fully unpoisonable to
future work. In this issue I want to concentrate on the onion modulo the
DHT, i.e. making the onion do its job when we assume that the DHT is
doing its job. As long as poisoning the DHT is expensive, this is
worthwhile in itself.
|
* Sunday, 2017-11-26 at 17:14 +0100 - zugz <mbays+tox@sdf.org>:
I think for now we should leave making the DHT fully unpoisonable to
future work.
Thinking again: if it's really possible to ensure uniform local views of
the network, we can directly use that to pick path nodes for the onion.
This would be much better than the solution I'm proposing here, which is
based on the uncomfortable assumption that the bootstrap nodes are not
colluding.
Looks like I should spend some time with the literature!
|
That was exactly my point! |
* Sunday, 2017-11-26 at 20:19 +0000 - Nazar Mokrynskyi <notifications@github.com>:
That was exactly my point!
Yep, sorry to be slow on the uptake!
|
Sybil attacks are the fundamental problem. If a Sybil attacker can poison our Section 3 of The most relevant systems of this kind are SybilGuard The basic idea is that a Sybil attacker will have only so many friend So my current thinking is that we should adapt SybilLimit, using the Tox This would give users resistance to Sybil attacks once they're part of a Plenty of details need to be sorted. But I wonder what people think of this |
I agree that nothing less than complete solution is worth the effort, as it will not fundamentally change situation. Yes, Brahms assumes that nodes should not have multiple IDs, which is not something that is possible to guarantee in true distributed network. I'll look at SybilGuard and SybilLimit now, thanks for the links! |
So I've looked at SybilGuard and then at SybilLimit and I have one major issue with it: both of them assume that attacker knows the whole friends graph, which is, I believe, one of the things Tox aims to protect from. |
I've read a few more researches and came to conclusion that it might be effective to require each node to store some significant amount of state that depends on node ID in order to function. Have anyone seen studies containing such approach? |
100M is going to make mobile users really sad. |
yes, very sad. |
@nazar-pc how is RAM scarce? swapping on disk is easy. |
@zoff99 not if you need true random access, see the stuff Etherum uses. |
Yes, RAM should be used in a way that will make swapping even to SSD inefficient. It can be 10M instead, depending on security properties and network size. |
* Monday, 2018-01-08 at 14:37 -0800 - Nazar Mokrynskyi <notifications@github.com>:
So I've looked at SybilGuard and then at SybilLimit and I have one
major issue with it: both of them assume that attacker knows the whole
friends graph, which is, I believe, one of the things Tox aims to
protect from.
The protocols described in the paper leak a lot of information about the
friend graph, yes. But I believe I see a way to adapt SybilGuard (though
not SybilLimit) to deal with that, in a way which hopefully can be made
not too expensive in network traffic. I have a half-written account of
it; I'll finish it off and show it here soon.
|
@nazar-pc 100MB+ RAM for 1 app on a phone is really not possible now. most phones will kill other apps. remember this thing is a background app, until there is some sort of PUSH service for Tox. |
* Monday, 2018-01-08 at 19:47 -0800 - Nazar Mokrynskyi <notifications@github.com>:
but an attacker will need 1G of RAM for each 10 fake nodes.
Just limiting the number of concurrently active fake nodes isn't really
enough. At least to prevent a targetted attack on Brahms, we also need
to ensure an attacker can't cycle through lots of identities.
|
Brahms just assumes there is a authority that issues identities, simply because of this fact I think it is out of scope of our needs. |
* Tuesday, 2018-01-09 at 11:23 -0800 - Nazar Mokrynskyi <notifications@github.com>:
Brahms just assumes there is a authority that issues identities,
Right, but as far as I can see, all it actually needs is that an
attacker can't create too many identities which will be accepted by
honest participants. So a SybilGuard-like system should do just as well
in place of a central authority.
|
@zugz, do you have something to share already? |
@zugz, do you have something to share already?
Sadly not. The idea didn't work out. Sorry for not saying earlier.
There are lots of problems, but the fundamental one is this: any such
scheme requires us to have a long-term identifier which we share with
arbitrary DHT nodes, which they will try to use to determine whether or
not we're sybil. But this in itself is a big problem: since friend
relationships between nodes identified by IP address / DHT public key
are not kept private in tox, a crawler can easily map out the friend
network indexed by these long-term identifiers. That's a big privacy
problem.
So I'm coming reluctantly to the conclusion that we should give up on
making the DHT sybil-resistant. That does also mean giving up on the
onion.
Grayhatter suggested using per-edge rendezvous spots, and I'm belatedly
coming round to the idea that this might be the best (only?) solution.
But that's a topic for another issue.
|
I was recently messaged with presentation called "S/Kademlia: A Practicable Approach Towards Secure Key‐Based Routing": https://pdfs.semanticscholar.org/3165/2823ca71520038773346b6e5bbfadc5c8419.pdf I found it very interesting and planning to use it in my project, which at the moment has Mainline DHT-like implementation (with some inherent hardening on top). |
https://github.com/zugz/tox-onionPathsProposal/blob/master/onionPathsProposal.md
This expands substantially on #547.
The text was updated successfully, but these errors were encountered: