[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-dev] Tor and Namecoin



I'm also a noob, so just to be clear, is the goal here to adopt namecoin as a naming mechanism for hidden services or is the goal to enable a generic extension mechanism where multiple different naming solutions can be experimented with and namecoin wants to build the code to leverage that mechanism so it can be part of the more general naming experiment?

	Thanks,

		Yaron

-----Original Message-----
From: tor-dev [mailto:tor-dev-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of George Kadianakis
Sent: Tuesday, August 2, 2016 6:54 AM
To: Jeremy Rand <jeremyrand@xxxxxxxxxx>; Tor-Dev <tor-dev@xxxxxxxxxxxxxxxxxxxx>
Subject: Re: [tor-dev] Tor and Namecoin

George Kadianakis <desnacked@xxxxxxxxxx> writes:

> [ text/plain ]
> Jeremy Rand <jeremyrand@xxxxxxxxxx> writes:
>
>> [ text/plain ]
>> Hello Tor devs,
>>
>> Namecoin is interested in collaboration with Tor in relation to 
>> human-readable .onion names; I'm reaching out to see how open the Tor 
>> community would be to this, and to get feedback on how exactly the 
>> integration might work.
>>
>> The new hidden service spec is going to substantially increase the 
>> length of .onion names, which presents usability concerns.  Namecoin 
>> provides a way to resolve a human-readable .bit name to a .onion name.
>> Another benefit of Namecoin is that it provides a way to lookup TLS 
>> fingerprints for clearnet .bit sites, which reduces the risk of MITM 
>> attacks on clearnet websites from malicious or compromised CA's.
>>
>> <snip>
>>
>> There are a few options I can think of for integrating this with Tor 
>> for .onion naming.  One would be to modify OnioNS to call the 
>> Namecoin SPV client.  This would concern me because OnioNS is in C++, 
>> which introduces the risk of memory safety vulnerabilities.  Another 
>> would be to use an intermediate proxy like Yawning's or-ctl-filter.  
>> A third option would be to try to get external name resolution 
>> implemented in Tor itself, which I believe Jeff Burdges has suggested 
>> in the past.  If Option A or B is used, any solution would need to 
>> pass the stream isolation info to the SPV client.
>>
>
> Hello Jeremy,
>
> I'm a big noob when it comes to blockchains, namecoin, SPV clients and 
> such, so I'm mainly going to focus on how to integrate this with Tor.
>
> It seems to me that a plausible way to kickstart this big project 
> would be to make an unofficial add-on for TBB that can do the namecoin 
> dance. People can then install it and experiment with it. If it fits 
> the Tor use case well, then a community might be formed that will push this project forward even more.
>
> If it's an optional add-on, we also don't have to worry that much 
> about the 400MB blockchain size, since it's gonna be optional and only 
> people who want it will have to download it. This way we can learn how 
> much of a problem the download size is anyway (it seems to me like a 
> total blocker for people in non-western fast-internet countries).
>
> That's why I would suggest experimenting with the first two approaches 
> you mentioned that don't require a modification to Tor's protocol.
>

On this front, please check out Nick's new mail showing how to integrate external name resolvers into Tor:

https://lists.torproject.org/pipermail/tor-dev/2016-August/011253.html
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev