Re: [tor-dev] The Onion Name System (OnioNS)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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?) As you can see from the ACM paper, I estimated 16Kb - 28Kb from routers leaving/joining the consensus, and my Markov Model analysis shows ~9000 bits from routers changing in some degree or another. Certainly the size and dynamics of the Tor network are enough to put the entropy above 256 bits, so I'm confident that any sort of malicious maneuvers (such as changing router descriptors so that the SHA-384 hash results in an attacker-pleasing Quorum) is hard because of the cryptographic defenses of SHA-384 and because the consensus has a large degree of entropy. I believe (but cannot prove) that those numbers are a lower-bound, though formally it's just an estimation. Sybil attacks are possible but expensive. They would have to gain the Fast and Stable flags and be subtle enough to not be detected by the Tor community (the Lizard Squad learned that the hard way). Sybil attacks would also likely compromise Tor and hidden services, which is outside my security assumptions. 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. One possible counter-measure is the Sybil attack detector that was posted here the other day. It might be a good idea, I'll think more about that. 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. Thanks, I'll take another look. Alice is always a Tor client. The HS is down, and has been for some days. Yes. I'm currently hosting it myself and I'm currently but temporarily in a remote location where the Internet is spotty at best. By the time I deploy OnioNS into beta or into production I'll have a stable host for the HS. I'll have it up soon. In the meantime, you can always clone and browse the Github repo that powers it, OnioNS-www. 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. If a user wants to use a .tor address with something other than the Tor Browser, they will have to have both the Stem and the OnioNS client software running in the background. It should be application-independent. Eventually I would like the Stem code in the Tor client, and theoretically it should not be hard to do so. Currently I have a very reliable Stem solution (for which I am very thankful) and I will be utilizing that script for the time being. Based on a quick investigation it should also be easy to auto-launch it with the Tor Browser. I would like to see the OnioNS package in Linux or Tor repositories so that it may work as a general solution, and not something tied to the Tor Browser. 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? I may have misused the term. It's not a busy-wait. Currently it's an idle synchronous wait on separate thread in the Stem script. The Tor Browser appears as if it's waiting for a DNS lookup to occur, which is essentially correct. Once that goes through, Tor attaches the stream to a .onion address, and the browser transitions to appearing as if it's waiting for a server over a high-latency connection, which is also correct. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVbg1lAAoJEK2XNk/CC+yAnxEIAMn+XvrKX02+1OGrxQe4poNu hJzDcZHIJ5GTkYJk6iIOu7J+riz/f7rmQbvtxJWt3ZcAfebqcoec0j1kbvnFWDP4 /C35A4nSEN36XlDU/5AkYHv6l5dgvvxX+cDMSvHKFzrZU2m4uGAi5QF4qr3dqbbB ys6i1d4x/kuPvfFvZVrsiFVO0EKK5EzunccxHfly4aOpzksJlTCSrKSWoDwltpOK F9UKww53JTPbfNTMmqnOx9sE6DuPz3mNA7DMTMBiPjhl9nouq4mGFma60up2XY/u Ge9qOE7Wrrn95H9JZAR3uQqi5CehnAFd9h2fC2mcyAGkppJ69oOLhIBi/z94hC0= =Fygz -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] The Onion Name System (OnioNS)
Date: Mon, 18 May 2015 15:48:50 -0800 From: OnioNS Dev kernelc...@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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] The Onion Name System (OnioNS)
On 3 Jun 2015, at 02:07 , teor teor2...@gmail.com wrote: Date: Mon, 18 May 2015 15:48:50 -0800 From: OnioNS Dev kernelc...@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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] The Onion Name System (OnioNS)
On 05/23/2015 06:26 PM, OnioNS Dev wrote: My design also assumes that there is no dynamic compromise of Tor routers (there's no incentive for an attacker to target Tor routers because of OnioNS) I can live with explicitly stated design assumptions, but the claim that there is no incentive for an attacker to target Tor routers because of OnioNS is rather wild. With Namecoin, you have an inherent limit on the rate at which names can be registered. Now, once people start squatting tons of .tor names, maybe even your bandwidth advantage disappears as the consensus may become rather large. That's a fair point. It's a hard problem to solve. It's subtle, but I also put in a requirement that the network must also ensure that the registration points to an available hidden service. Thus it forces innocent users and attackers to also spin up a hidden service. It's not foolproof, but it's better than nothing. Interesting. Is a powerful adversary able to prevent registration by somehow denying/delaying access to the new .onion service and concurrently submitting a competing registration for the same name? I remember such attacks being discussed for DNS, where a candidate's search for available names might cause those to be quickly reserved by some automatism as a means to extort name re-assignment fees. Just wondering if you considered this possibility. (IIRC Namecoin defends against this by having an additional commit-and-reveal process where the name is first reserved without the name itself being revealed). I've also been thinking about a proof-of-stake solution wherein the network only accepts a registration if the destination HS has been up for X days. Can a HS have more than one name? Another idea is to have the Quorum select a random time during the week, test for the availability of the hidden service, and then sign whether they saw the HS or not. Then the next Quorum could repeat this test, check the results from the previous Quorum, and void the Record if they also observed that the hidden service was down. I like both of these ideas, but I have not yet solidified their implementation so I was not ready to announce them in the paper. Sure, good time to discuss them then ;-). Well, I prefer my hidden services to be really hidden and not public. I understand that this weakness is somewhat inherent in the design, but you should state it explicitly. Too late, your hidden services are already leaking across Tor's distributed hash table. Today, yes. Tomorrow, who knows; I'm still hoping that the next generation of HS will fix that, and hope try to get Tor to accept the GNS-method for encrypting information in the DHT. Which, btw, is pretty generic (we also use it in GNUnet-file sharing, and I have other plans as well). In fact, I think if you look at the GNS crypto closely, it might offer a way to encrypt most information in any DHT (and offer confidentiality against an adversary that cannot guess the name/label/keyword / perform a confirmation attack). There are even Tor technical reports and graphs on metrics.torproject.org which count them, which I assume also implies that they are enumerated. You are totally right about the status quo. I just would point out that this may not be true in 2020 ;-). It's not about CPU power, it's about the honesty of nodes in the Tor network. I understand that. But whether you do it on IPs, bandwidth or CPU, you did lower the bar on the adversary. That gives me the globally collision-free property. Perhaps I have lowered the bar, but I do think it's a bit higher than Namecoin because OnioNS is only dependent on the distribution of identities, and not the distribution of CPU power. I agree that it is probably easier to mount a 51% CPU-attack against Namecoin than an attack against the OnioNS quorum. Could we please make the protocol a bit more general than this? Yes, I will look into it. Your description is helpful, but if you want to write up a protocol describing what you want on your end, I'll merge it into my protocol, and then we'll have a protocol that is compatible with both of our needs. I would be happy to modify my software accordingly. I agree that we should have a write-up, but have to add that I hope to delegate most of the writing to Jeff ;-). Happy hacking! Christian signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] The Onion Name System (OnioNS)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/20/2015 12:18 AM, tor-dev-requ...@lists.torproject.org wrote: Furthermore, there is the question of time. As .tor-names are pinned (if you have a name, you get to keep it 'forever', right?), an adversary may invest into the required resources to make the attack succeed* **briefly* (i.e. get the required majority), then re-assign names to himself. New honest nodes would pick up this hacked consensus, and thus it would persist even after the adversary lost the majority required to establish it. This is relevant, as an attack against Tor user's anonymity only impacts the users as long as the attack itself lasts, so the gains between the two attacks (temporary vs. forever) change the economic incentives for performing them. So I'm not sure it is such an obvious choice to just rely on an honest majority of (long-term/etc.) Tor routers. I'm not saying it is bad; however, simply saying that if those routers are compromised all is lost anyway is not quite correct. To carry out the attack you describe, they would need to have control of enough colluding Tor nodes so that they control the largest agreeing subset in the Quorum. It's not about PoW to control the Quorum, the Quorum is a group of Tor routers. My design also assumes that there is no dynamic compromise of Tor routers (there's no incentive for an attacker to target Tor routers because of OnioNS) so we can consider a static level of compromise. As I've shown in my analysis, if the Quorum is large enough, the chances of selecting a malicious Quorum, either per-selection or cumulatively, is extremely low even at Tor-crippling levels of collusion. Ok, let's assume a c4.xlarge EC2 instance (which is ~i7) takes 4h to do this (on all cores). For one month, the price is USD 170, which means the registration cost is 70 cents/name (for eternity, or do I have to do this repeatedly? Don't recall if you require a fresh PoWs). Anyway, 4h sounds pretty inconvenient to a user, but as you can see is still nothing for a professional domain name squatter who today pays closer to 100x that to squat for a year. I predict most 'short' names will be taken in no time if this is deployed. With Namecoin, you have an inherent limit on the rate at which names can be registered. Now, once people start squatting tons of .tor names, maybe even your bandwidth advantage disappears as the consensus may become rather large. That's a fair point. It's a hard problem to solve. It's subtle, but I also put in a requirement that the network must also ensure that the registration points to an available hidden service. Thus it forces innocent users and attackers to also spin up a hidden service. It's not foolproof, but it's better than nothing. I've also been thinking about a proof-of-stake solution wherein the network only accepts a registration if the destination HS has been up for X days. Another idea is to have the Quorum select a random time during the week, test for the availability of the hidden service, and then sign whether they saw the HS or not. Then the next Quorum could repeat this test, check the results from the previous Quorum, and void the Record if they also observed that the hidden service was down. I like both of these ideas, but I have not yet solidified their implementation so I was not ready to announce them in the paper. Well, I prefer my hidden services to be really hidden and not public. I understand that this weakness is somewhat inherent in the design, but you should state it explicitly. Too late, your hidden services are already leaking across Tor's distributed hash table. There are even Tor technical reports and graphs on metrics.torproject.org which count them, which I assume also implies that they are enumerated. I can't remember where I read it, but I do recall reading some report about how the researcher spun up a number of hidden services, didn't tell anyone about them, but then observed that someone connected to them anyway from time to time. Someone out there is enumerating HSs. Tor's HS protocol isn't designed to hide the existence of HSs, my system isn't either. I can state it explicitly, but there's no practical way around it as far as I can see. See, that's the point: Namecoin (and your system) assume a different adversary model than what Zooko intended to imply when he formulated his triangle. When Zooko said secure, he meant against an adversary that does have more CPU power than all of the network combined and unlimited identities. When you say secure, you talk about Namecoin's adversary model where the adversary is in the minority (CPU and identity/bandwidth-wise). Thus, it is unfair for you to say that your system 'solves' Zooko's triangle, as you simply lowered the bar. As you say, Namecoin assumes that it has more CPU power than adversaries. Perhaps I should have clarified more
Re: [tor-dev] The Onion Name System (OnioNS)
Please write an IETF draft asking for .tor to be reserved for Tor under RFC 6761 referencing your documentation. Should take no time if you base it on Jake's .onion draft. Send it to dnsop, they really love to discuss this topic and alternative DNS protocol ideas right now. ^_^. Also, GNS is not a hierarchical zone of names (no hierarchy, just a directed graph). I'm not sure how your proposal significantly improves on NameCoin, except that it is specialized to Tor (and thus doesn't attempt to be as compatible with DNS as Namecoin): for security, you still rely on a PoW-supported consensus, so an adversary with sufficient computational power can register important names first (who gets facebook.tor first?). Given that you probably don't want to double the electicity bill of 'normal' users when they want to register names, my prediction is that if this is adopted, trolls (and name squatters) will have a field day registering interesting names. I didn't see a mechanism to transition a name from one RSA key/.onion address to another. Is that intentionally missing? Will users loose control over their .tor names when they rotate keys? It also seems you are unconcerned about zone enumeration. Both your protocol on authenticated denial-of-existence and the entire consensus system suggest that it should be easy for a peer to enumerate all names in the .tor zone. Why do you limit names to 128 characters, when DNS supports 253? With respect to Zooko's triangle, I would point out that you define it differently than GNS does (and we checked with Zooko about the definition at the time). In particular, you assume that the adversary has limited computational power and doesn't dominate the consensus. For GNS, we assume that PoW is useless (adversary can do PoW for all memorable names) and that consensus is useless (adversary has majority). This is because in practice, governments do have more computational power than citizens, and when it comes to censorship it is important to protect minorities and their opinions, not majorities. (see also http://grothoff.org/christian/fps2013wachs.pdf). Thus, you might want to make it clearer in your paper that you 'square' Zooko's triangle under exactly the same conditions as Namecoin: a weaker adversary model / definition of 'secure'. All that being said, I'm not at all against this: We should have MANY ways (protocols!) to assign names, some more usable, some more secure, especially as the current dominant method is just broken (DNS). So maybe Tor can plan to incorporate .tor, .bit (namecoin), .onion and .gnu. After all, each solution has interesting advantages and drawbacks. (The problem then only becomes educating the user about those.) Regardless, good luck with .gnu and I look forward to the resulting discussions on dnsop (IETF mailinglist), where you really should launch a discussion on this as well. On 05/19/2015 01:48 AM, OnioNS Dev wrote: Hello everyone, I'm the one behind the Onion Name System (OnioNS), a Tor-powered distributed DNS for Tor hidden services. It's been several weeks since my project was selected for the SoP program, and I've finally got around to posting here about it. My project aims to solve the major usability issue that has been with hidden services from the beginning: their un-memorable addresses. I'd like to discuss a bit about how it works, where my project is described, and where I am with the implementation. Under OnioNS, a hidden service operator can anonymously claim a meaningful domain name for their hidden service (a map between the .tor and .onion pseudo-TLDs) and then transmit it over a Tor circuit to an OnioNS server, which is also a Tor router. The claim propagates across the Tor network. Later, a user may type a .tor domain name into the Tor Browser. My software intercepts this domain, performs a lookup over a Tor circuit to an OnioNS node, and learns the corresponding .onion address. Then it tells the Tor client this, which contacts the HS in the normal way. The result of this process is that a hidden service loads transparently in the Tor browser under a meaningful name. 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. Clients don't need a copy of the Pagechain to use the DNS, but
Re: [tor-dev] The Onion Name System (OnioNS)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/19/2015 03:20 AM, tor-dev-requ...@lists.torproject.org wrote: Subject: Re: [tor-dev] The Onion Name System (OnioNS) From: Christian Grothoff groth...@gnunet.org Date: 05/19/2015 03:24 AM To: tor-dev@lists.torproject.org Please write an IETF draft asking for .tor to be reserved for Tor under RFC 6761 referencing your documentation. Should take no time if you base it on Jake's .onion draft. Send it to dnsop, they really love to discuss this topic and alternative DNS protocol ideas right now. ^_^. I will put that on the to-do list. Also, GNS is not a hierarchical zone of names (no hierarchy, just a directed graph). Thanks, I'll make those corrections. Good to hear from someone who is part of that system. I'm not sure how your proposal significantly improves on NameCoin, except that it is specialized to Tor (and thus doesn't attempt to be as compatible with DNS as Namecoin): for security, you still rely on a PoW-supported consensus, so an adversary with sufficient computational power can register important names first (who gets facebook.tor first?). Given that you probably don't want to double the electicity bill of 'normal' users when they want to register names, my prediction is that if this is adopted, trolls (and name squatters) will have a field day registering interesting names. My scheme is better than Namecoin in several key ways: 1) No miners. I'm relying on the existing trust of the Tor network and purposely did not create a new network. 2) Minimal networking costs. Namecoin typically requires users to hold the blockchain, and has very little client-side security when users rely on name servers to hold it for them. I require clients to check a set of signatures from Tor routers. Most of the attack vectors for OnioNS also results in a compromise of Tor, which makes the whole thing moot. Hence it makes sense to rely on Tor. The PoW is only for registration, no one else does it. Yes, it is first-come-first-serve, but so is Namecoin. On the Internet DNS, someone with lots of money could buy up domains too (ISPs do this all the time). For well-known hidden services (such as DuckDuckGo) we could mark those names as reserved such that only the owner of that hidden service could register it on OnioNS, and let all other names be first-come-first-serve. I'm thinking of setting the proof-of-work relatively high, say four hours on an i7 or so. The reliance on scrypt and the complex of the domain registration should restrict this to CPUs. I didn't see a mechanism to transition a name from one RSA key/.onion address to another. Is that intentionally missing? Will users loose control over their .tor names when they rotate keys? I only have 12 pages, there wasn't enough space for that protocol. However, I have already created protocols for deleting, transferring, and updating Records. Domain registration uses the same private key as hidden services, so if the key is compromised, both are compromised and the security of the Record is moot. It also seems you are unconcerned about zone enumeration. Both your protocol on authenticated denial-of-existence and the entire consensus system suggest that it should be easy for a peer to enumerate all names in the .tor zone. I'm considering that all OnioNS data is public. There's no way to hide information in the Pagechain as Mirrors need to verify it. An attacker could also spin up a machine, synchronize with the network, and enumerate them anyway. Clients must also see the domain names in the leaves of the Merkle tree in order to authenticate Records or verify that the domain does not exist by finding two domains that alphabetically span it. I also can't hide the domain names in the Merkle trees via hashes because then I'm mapping unique names to a binary space that may have collisions. It's far easier to just consider the information public. Fortunately, there's no personally-identifiable information in the Pagechain, so there's no advantage in hiding the data. Why do you limit names to 128 characters, when DNS supports 253? For space reasons. Longer names introduce more storage and networking demands. The smaller choice shouldn't make any practical difference; I have yet to see a domain name on the Internet with a 253-character second-level domain. With respect to Zooko's triangle, I would point out that you define it differently than GNS does (and we checked with Zooko about the definition at the time). In particular, you assume that the adversary has limited computational power and doesn't dominate the consensus. For GNS, we assume that PoW is useless (adversary can do PoW for all memorable names) and that consensus is useless (adversary has majority). This is because in practice, governments do have more computational power than citizens, and when it comes to censorship it is important to protect minorities
Re: [tor-dev] The Onion Name System (OnioNS)
In the sense that the IPv6 addresses provided by Onioncat are namelike, these may be of reference interest (I do not know if Bernhard has produced paper/slides/video for the new HS crypto model in english yet. I hope to look it over.) https://www.youtube.com/watch?v=Zj4hSx6cW80 https://www.youtube.com/watch?v=SBb2jy80Itc ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
