Date: Mon, 18 May 2015 15:48:50 -0800 From: OnioNS Dev kernelcorn@riseup.net
...
I introduce several data structures, but the most important one is the Pagechain, a distributed structure of linked Pages. Pages contain Records, Records contain .tor -> onion associations. Anyone who is familiar with blockchains will recognize the behavior and application of this structure immediately. However, here the head of the Pagechain is not managed by miners, but rather by a short-lived subset of Tor nodes called a Quorum. They receive Records and merge them into the Pagechain. At the moment I've decided to use 127 Quorum members and rotate them every week. They are randomly selected, but the process is deterministic; I am using the cached-certs + cached-microdesc-consensus documents, which everyone has, to seed a PRNG that then derives the Quorum.
What's to stop a sybil attack where the malicious relays try to occupy likely site(s) for the next Quorum?
Is the consensus unpredictable enough to thwart this attack? Even during quiet times? (Does Tor have quiet times?)
Can we ensure the Quorum servers have to be long-lived and high-capacity (for example, guards) to make it harder to spin up servers and immediately be added to the Quorum? I'm not convinced the Stable flag is hard enough to get.
Of course, there's a trade-off where making the set of Quorum Candidates too small makes the Quorum easier to predict, too.
By the way, in your ACM paper 5.4.2 you switch from Charlie to Alice, but I think they're meant to be the same Quorum Candidate.
Clients don't need a copy of the Pagechain to use the DNS, but rather they can just rely on their existing trust of the Tor network (including the Quorum and name servers) and verify their signatures on data structures. Also unlike a blockchain, my Pagechain has a finite length: the oldest Page will eventually drop off, which forces domains to be renewed periodically. I have also introduced mechanisms that 1) allows clients to authenticate the domain name to the hidden service, 2) allow clients to authenticate a denial-of-existence claim from a name server, and 3) prevent name servers from forging .tor -> .onion associations. These vulnerabilities are still generally open on the Internet DNS. I have also tried to minimize networking costs, since Tor circuits are slow.
To reduce CPU and network requirements, I want Tor routers to have Ed25519 keys. Let this project add additional pressure on that item on the to-do list.
Recommended readings: http://onions55e7yam27n.onion -- the official hidden service for this project, but a work in progress. https://github.com/Jesse-V/Thesis/blob/master/conference/acm-ccs.pdf -- the ACM paper pending peer review I no longer recommending reading my original thesis, please use the above links instead.
The HS is down, and has been for some days.
For those having trouble accessing the paper through the direct link, try clicking on acm-ccs.pdf on: https://github.com/Jesse-V/Thesis/tree/master/conference
I got a format error from GitHub when I tried the direct link in Tor Browser 4.5.
…
I am asking for help with the client-side functionality. I'm currently doing the *.tor interception and lookup resume in connection_edge.c but the software frequently crashes with this approach, (I've learned why) and I'd like to migrate it to Stem for now. I need to intercept .tor domains, pause the lookup (letting the Tor Browser spin), send the hostname over a named pipe or TCP socket, read back a .onion address, then tell Tor to resume the lookup under the .onion address. This way, the HS loads under a .tor domain.
I have two questions about the Stem-based approach: 1. Applications which use Tor via SOCKS won't be able to use .tor domains without using Stem. This adds another dependency to apps which want to use .tor addresses, and confuses users by making .tor addresses work with some torified apps, and not others. Is your final goal to have .tor lookups contained within the Tor client? I'm sure someone could help with the C coding if that's the issue, particularly given a working implementation in Python/Stem.
2. I always feel nervous when people say "letting app X spin". I assume Tor Browser just looks like it's doing a DNS lookup or similar?
teor
teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5
teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7
On 3 Jun 2015, at 02:07 , teor teor2345@gmail.com wrote:
Date: Mon, 18 May 2015 15:48:50 -0800 From: OnioNS Dev kernelcorn@riseup.net
...
I introduce several data structures, but the most important one is the Pagechain, a distributed structure of linked Pages. Pages contain Records, Records contain .tor -> onion associations. Anyone who is familiar with blockchains will recognize the behavior and application of this structure immediately. However, here the head of the Pagechain is not managed by miners, but rather by a short-lived subset of Tor nodes called a Quorum. They receive Records and merge them into the Pagechain. At the moment I've decided to use 127 Quorum members and rotate them every week. They are randomly selected, but the process is deterministic; I am using the cached-certs + cached-microdesc-consensus documents, which everyone has, to seed a PRNG that then derives the Quorum.
What's to stop a sybil attack where the malicious relays try to occupy likely site(s) for the next Quorum?
Is the consensus unpredictable enough to thwart this attack? Even during quiet times? (Does Tor have quiet times?)
Can we ensure the Quorum servers have to be long-lived and high-capacity (for example, guards) to make it harder to spin up servers and immediately be added to the Quorum? I'm not convinced the Stable flag is hard enough to get.
Of course, there's a trade-off where making the set of Quorum Candidates too small makes the Quorum easier to predict, too.
Some day, I will learn to read the whole paper before opening my mouth.
I apologise - I withdraw my questions in the face of thousands of bits of entropy per hour, and a comprehensive security analysis.
By the way, in your ACM paper 5.4.2 you switch from Charlie to Alice, but I think they're meant to be the same Quorum Candidate.
In an earlier section, "Alice" is a Tor client. This makes this section make sense.
teor
teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5
teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7
-
teor