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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev