back to article Better onion anonymity possible: researcher

Onion routing – which in spite of its DARPA genealogy are disliked by national security types – could be made more anonymous, according to a an Iranian researcher now working on a PhD at Concordia University in Montreal. In this Arxiv-published paper, Ehsan Saboori and co-author Shahriar Mohammadi propose separating the “request …

COMMENTS

This topic is closed for new posts.

This post has been deleted by its author

Coat

So there's no "suppernode" for ordering delivery service?

Sorry, got the munchies and delivery sounds good right now.

4
1
Anonymous Coward

An Iranian working on this? Close to the US border!

He need to keep a low profile on this, they won't like it you know!

2
0
Pint

Re: So there's no "suppernode" for ordering delivery service?

Yes sounds good. Never mid power-over-ethernet, now we've got food-over-fibre - Mmm burger!

1
0
Anonymous Coward

Supernodes

I admit I didn't read the whole thing, but I'm confused. Are these "supernodes" anything different from what Tor currently calls "directory nodes"? And if so, why are they needed? On the face of it, selected a separate return path looks like a trivial addition that could be accomplished exactly the same way the two-way path is selected now.

2
1
Bronze badge

other alternatives

OK, so I'm not doing this for a PhD, but there are some fairly obvious improvements possible.

The main one involves an anonymous broadcast protocol, eg some version of the Dining Cryptographers problem (hello, "suppernode"). It's a simple protocol where all the diners flip a coin in secret between himself and his immediate right-hand neighbour then they announce "same" or "different" (there are as many coins as there are diners, and each diner can see two coins). If everyone is truthful then a parity calculation should always yield an even number of people saying "different", but if someone lies they throw the parity calculation off and so they've effectively broadcast one bit anonymously.

That algorithm isn't practical for tor, but there are other algorithms for achieving the same results. Mostly they include a fixed hierarchy (think nested dinner tables and "suppernodes" again) but they'd be much better if there was some sort of protocol for assigning "seating" on a random, ad-hoc basis. All these protocols also need to be hardened against deliberate disruption. Search for "dining cryptographers with cheaters"...

Chaffing and winnowing is another sort of protocol that might make sense. If you can set up a secure data channel to your egress point and you have some method of guaranteeing that the channel goes through some number of nodes whose sole function is to introduce random noise into the conversation stream, then a shared, private (configurable) checksumming algorithm is enough to defeat eavesdroppers with any required degree of confidence (it then becomes a form of probabilistic encryption).

The third alternative I can think of is to leverage the store and forward aspect of the network. Tor has some specialised DHT (distributed hash table) functionality but as far as I can tell it's not used in the normal case of operation where you just want to connect to a particular site anonymously. In other words, tor is mostly just forwarding packets and not acting as a storage network for the most part. What I have in mind is changing things so that tor would act more like a short-lived storage network, with each chunk of data effectively having a "half life" and having peers shunt around parts of each chunk among members of their ad-hoc peer groupings and randomly dropping a fixed percentage of all chunks. I won't go into details (the algorithms I have in mind aren't too hard, though), but it should be possible to maintain a coherent DHT even in the face of all this deliberate data loss and also in the presence of cheaters. The point of this is to spread delivery of your requested data (web page) out in the time domain so that even if an attacker can snoop your incoming and outgoing traffic and he has also subverted the exit point (so he knows what web page was downloaded) they can't prove that you were the person who requested it. I suppose what I'm basically saying is that there are algorithms and protocols that would enable a "probabilistic delivery" model with tunable parameters for how often you want your download to succeed within a given time frame (the "half life") and what level of protection you want against eavesdroppers in the worst case scenario. I guesstimate that the network would only have to store something between 6 and 10 times the volume of peak traffic of the equivalent "forward-only" network for this "probabilistic delivery" method to be viable.

3
1

Sounds like Ehsan Saboori and Shahriar Mohammadi should switch to I2P which has done uni-directional tunnels for years (Garlic Routing) and has a fairly sophisticated network database for exploratory lookups.

One drawback being, it doesn't focus on exit-nodes like Tor, but everything remains in-network ( but that's probably a good thing from an anonymity perspective )

0
0
Silver badge
Joke

Onion routing, Garlic routing

What is this, a cookbook ?

3
0
Coat

Re: Onion routing, Garlic routing

Not without ginger rooting its not

2
0
Anonymous Coward

Re: "Not without ginger rooting its not"

On the internets, this is generally referred to as 'figging'. Sticks with the food theme, and handily combines with the sort of activity where an afficionado might wish to remain anonymous.

0
0
Anonymous Coward

Can be more dangerous

Good thinking. However, in this scenario, two computers have access to clear-text data. The one who sent it out directly to the destination, and, the one who received the response. Normally in each request/response there are some key factors that can compromise the anon. client.

Moreover, now both sender and receiver can manipulate request/response to compromise the client.

Therefore, the probability of being compromised by having couple of dodgy network nodes will be increased.

0
0
Anonymous Coward

Re: Can be more dangerous

I'm not sure I follow you. Whether you use a separate return path or not, the message should be encrypted during each hop, and only the Requester (e.g. my desktop) and the Provider (e.g. your computer if I'm talking to you) would be handling it unencrypted. Are you perhaps thinking in terms of exit nodes in Tor? Because that isn't really what this is about. If used for that purpose the exit node would function as the Provider, and would still be the only P2P node to handle the cleartext.

0
0
Joke

Suppernode

Isn't that where workers at the Guardian have their tea?

0
0
This topic is closed for new posts.

Forums