C-toxcore: Proposal for reworking the way onion paths are created

[zugz]

https://github.com/zugz/tox-onionPathsProposal/blob/master/onionPathsProposal.md

This expands substantially on #547.

[zoff99]

@zugz the risk here is "only" that an attacker can possibly know what friends we are connected to. so our friendship net.
but the message contents are safe.

is there also a DoS possibility? that the attacker can make our messages never arrive at the correct friend?

[zugz]

• Sunday, 2017-09-10 at 07:35 +0000 - Zoff [e-mail]:

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

[GrayHatter]

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

If the attacker has access to the users ISP, then yes. A silent DoS would be trivial.

but the message contents are safe.

To my knowledge yes, in all cases.

This is correct, (the birthday attack still applies)

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.

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.

[nazar-pc]

Couple of things about proposal:

• I didn't quite understand what those pools are, how exactly they differ from each other and how they are filled, especially initially
• branching random walk is somehow hard to understand too

Could you add some definitions section or something to make it easier to understand?

[nazar-pc]

Just to throw it somewhere, don't you think creating multiple DHT nodes can be substantially slowed down by involving some computationally heavy operation?
Something like blocks mining in crypto currencies, but connected to keypair. It might make keypair generation waaay slower than 0.0007s.

[zugz]

• Monday, 2017-09-18 at 19:56 -0700 - Nazar Mokrynskyi [e-mail]:

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?

[zugz]

• Monday, 2017-09-18 at 18:55 +0000 - Gregory Mullen [e-mail]:

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?

[zugz]

• Monday, 2017-09-18 at 21:18 -0700 - Nazar Mokrynskyi [e-mail]:

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.

[nazar-pc]

I just added an "overview" subsection to the "proposed system" section; hopefully it clarifies things?

It does, thanks!

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.

Definitely, but I think this is an interesting area to explore, not only for anonymity and security, but also for robustness and scalability.

[robinlinden]

@irungentoo Can you have a look at this proposal?

[zugz]

I've just added a section on the problem with the current DHT eviction
mechanism and a sketch of a proposed solution.

https://github.com/zugz/tox-onionPathsProposal/blob/master/onionPathsProposal.md

I now believe that the proposal deals with all feasible attacks aimed at
deanonymising users or obtaining information about the friend graph. I haven't
really tried to formalise what "feasible" means here, but it at least means
that the cost of any remaining attack targetted at a particular victim should
scale at least linearly with the size of the tox network for a fixed chance of
success, assuming that the number of bootstrap nodes scales linearly with
network size.

If anyone can see any remaining vulnerabilities, or ideas for
simplifications/optimisations, please tell. Else, I'm planning to actually
start work on implementation.

[zoff99]

@zugz if the save format changes, will the be a migration function in toxcore?
i would say we should start versioning pretty much everything.
savefile -> with version
toxAV -> with protocol version

so that toxcore can see what version is used, and also migrate on future changes.
same goes for ToxAV protocol. that newer toxcore can handle different protocol versions.

[robinlinden]

@zoff99 Saves are already marked with what version they were saved at: https://github.com/TokTok/c-toxcore/blob/0fce3fc94cac81c8eb8eda52dfb281ccc992d5bf/toxcore/Messenger.c#L2665
https://toktok.ltd/spec#state-format

[zoff99]

@robinlinden excellent. so we just need to migrate that when loading

[nazar-pc]

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.
I don't yet see a grand vision in mentioned proposal yet, moreover, there is no mathematical proofs how much better is it.

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
If someone haven't take a look at it yet, I'd like to suggest you to do so. At least it contains analysis of the properties of proposed solution (which do not yet fully understand to be honest) and it seems to provide pretty good guarantees that can be used as foundation for improved version of DHT in contrast to patching existing solution.

[zugz]

• Sunday, 2017-11-26 at 13:40 +0000 - Nazar Mokrynskyi [e-mail]:

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.

[zugz]

• Sunday, 2017-11-26 at 17:14 +0100 - zugz :

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!

[nazar-pc]

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.

That was exactly my point!

[zugz]

• Sunday, 2017-11-26 at 20:19 +0000 - Nazar Mokrynskyi [e-mail]:

That was exactly my point!

Yep, sorry to be slow on the uptake!

[zugz]

Sybil attacks are the fundamental problem. If a Sybil attacker can poison our
local view of the network, onion paths we build from it will be compromised.
In particular, the "Brahms" system linked to above specifically assumes away
Sybil attackers. Namely, it assumes that attackers have access to only so many
fixed network identities (DHT keys in the tox case) - if the attacker can
generate new ones at will, the guarantees in the paper don't apply.

Section 3 of
http://www.distributed-systems.net/my-data/papers/2011.acm-cs.pdf
gives a nice overview of defences against Sybil attacks on DHTs. If we assume
we want to be able to resist attackers using a botnet, then there are only two
types of known solution. One is to have a central authority certifying users,
which I assume we agree is inappropriate. The other is to exploit features of
human social networks. This may well be appropriate.

The most relevant systems of this kind are SybilGuard
http://www.math.cmu.edu/~adf/research/SybilGuard.pdf ,
and its successor SybilLimit
https://cs.nyu.edu/srg/docs/sybillimit-tr.pdf .

The basic idea is that a Sybil attacker will have only so many friend
relations with honest nodes ("attack edges" in the friend graph); using this,
and assuming that the honest part of the graph is connected and fast mixing,
it's possible for an honest node to verify whether a given node is honest
with a low false positive rate.

So my current thinking is that we should adapt SybilLimit, using the Tox
friend graph, then use it to verify DHT nodes. This isn't straightforward -
SybilLimit assumes a static network of always-on peers, with no privacy
requirements - but it looks like it should be doable. The costs in network
traffic would be considerable, but hopefully bearable.

This would give users resistance to Sybil attacks once they're part of a
sufficiently large connected component of the friend network. Then a
Brahms-like system can be used to get an unpoisoned view of the component,
from which onion paths can be built.

Plenty of details need to be sorted. But I wonder what people think of this
overall vision? It's complicated and might involve a compatibility break, but
as far as I can see it's the only possibility for a true solution. And I'm not
convinced that anything less than a true solution is worth having at all.

[nazar-pc]

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!

[nazar-pc]

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.

[nazar-pc]

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.
Something like 100M is quite feasible on average machine (though seems expensive for such a simple app like messenger), but an attacker will need 1G of RAM for each 10 fake nodes. As RAM is a relatively scarce and expensive resource, I think it might work.

Have anyone seen studies containing such approach?

[iphydf]

100M is going to make mobile users really sad.

[zoff99]

yes, very sad.

[zoff99]

@nazar-pc how is RAM scarce? swapping on disk is easy.

[sudden6]

@zoff99 not if you need true random access, see the stuff Etherum uses.

[nazar-pc]

Yes, RAM should be used in a way that will make swapping even to SSD inefficient.
100M was an example, which will work fine on modern mid-range phones that have 1-2G of RAM, while top models have up to 6G.

It can be 10M instead, depending on security properties and network size.

[zugz]

• Monday, 2018-01-08 at 14:37 -0800 - Nazar Mokrynskyi [e-mail]:

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.

[zoff99]

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

[zugz]

• Monday, 2018-01-08 at 19:47 -0800 - Nazar Mokrynskyi [e-mail]:

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.

[nazar-pc]

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.
Looking forward for your SybilGuard modification.

[zugz]

• Tuesday, 2018-01-09 at 11:23 -0800 - Nazar Mokrynskyi [e-mail]:

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.

[nazar-pc]

@zugz, do you have something to share already?

[zugz]

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

[nazar-pc]

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