Tor OnioNS

Post Reply
domob
Posts: 1129
Joined: Mon Jun 24, 2013 11:27 am
Contact:

Tor OnioNS

Post by domob »

Take a look here: https://github.com/Jesse-V/Thesis/blob/ ... thesis.pdf

Namecoin is credited with being a possible solution to associate .onion to readable names, but dismissed as being not a desired solution. I've not yet fully understood the details of the proposed solution, but from a quick glance it looks like Tor's "consensus" system itself (i. e., a set of trusted nodes votes). Does anyone know more about this?
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

phelix
Posts: 1634
Joined: Thu Aug 18, 2011 6:59 am

Re: Tor OnioNS

Post by phelix »

[my linebreaks:]
While Namecoin is often advertised as capable of assigning names
to Tor hidden services, it has several practical issues that make it generally infeasible to be
used for that purpose and it fails several of our design requirements.

First, to authenticate
registrations, clients must be able to prove the relationship between a Namecoin owner’s
secp256k1 ECDSA key and the target hidden service’s RSA key: constructing this relationship is non-trivial.
???
Second, Namecoin generally requires users to download the blockchain
before use which introduces logistical issues; as of April 2015 Namecoin’s blockchain is
2.45 GB. [33]
hmm... btw I read Bitcoin has merged pruning :)
Third, although ownership and transfer of Namecoins leaks no more than
an ECDSA key, obtaining the Namecoins in the first place (and thus being able to claim
28 a domain name) anonymously is non-trivial due to the logging in the blo ckchain.
Finally,
unlike the aforem entioned naming systems, Namecoin is not based on published works and
literature on it is s parse .
Too bad.
Although we also re je ct Name coin as a p ossible naming system
for Tor hidden se rvice s, OnioNS’ design shares some design principles with Namecoin.

We prop os e the Onion Name System (OnioNS) a Tor-p owered distributed naming
system that maps .tor domain names to .onion addresses.
For security reasons we do not introduce a central repository
and authority from which Bob can purchase domain names; however, domains must not
be trivially obtainable and Bob must expend effort to claim and maintain ownership of
example.tor. We achieve this through a proof-of-work scheme.
Further down they suggest a scrypt algorithm. I hope they choose proper parameters.

Also they say something about the Tor consensus process.


All in all it sounds to me like reinventing the blockchain wheel. We'll see if they can do it right.

btw, I would like to see some more in the direction of i2p :mrgreen:
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Tor OnioNS

Post by biolizard89 »

Jesse Victors was selected by Tor's Summer of Privacy to work on "The Onion Name System" this year. Jesse had contacted me last year about his thesis project. He was initially interested in using Namecoin, but ended up deciding the technology wasn't a good fit (for reasons that I wasn't entirely clear on at the time).

I have not read the thesis at this point, so I am unable to comment on it as a whole. (I intend to look at it in the future.) However, I do notice the following:
Several systems have been developed that aim to serve names in a decentralized environment. Cachin and Samar\cite{cachin2004secure} extended the Internet DNS and decreased the attack potential for authoritative name servers via threshold cryptography, but the lack of privacy in the Internet DNS and the logistical difficulty in globally implementing their work prevents us from using their system for hidden services. Awerbuch and Scheideler,\cite{awerbuch2004group} constructed a distributed peer-to-peer naming system, but like GNS, made no guarantee that domain names would be globally unique. More recently, Zooko's Triangle was proven false by practical demonstration by the development of Namecoin, a cryptocurrency discussed below.

\subsection{Namecoin}
\label{sec:Namecoin}

Namecoin is a decentralized information registration and transfer system, developed pseudo-anonymously in early 2011. It was the first fork of Bitcoin\cite{nakamoto2008bitcoin} and inherits most of Bitcoin's design and capabilities. Namecoin holds digitally-signed information transactions in a data structure known as a block; each block links to a previous block, forming a public ledger known as a blockchain. Each participant in the Namecoin network holds a copy of the blockchain and listen for and broadcast new blocks peer-to-peer. New Namecoins are generated at a fixed rate in a process known as mining, which is the computationally-expensive generation (due to proof-of-work) of a new block. Namecoins are then transferred peer-to-peer, and the registration of a domain name has some cost as it consumes a quantity of Namecoins. Domain names use the .bit pseudo-TLD and expire approximately every 250 days and so must be renewed periodically to preserve exclusive ownership. In 2014, Namecoin was recognized by ICANN as the most well-known example of a PKI and DNS system with an emphasis of distributed control and privacy.\cite{NamecoinReportICANN}

\begin{figure}[htbp]
\centering
\includegraphics[width=0.7\textwidth]{images/Namecoin/bitcoin_transaction.eps}
\caption{Three Namecoin transactions. Each owner broadcasts a digitally signed transaction that moves Namecoins from one ECDSA key to another. Every participant in the Namecoin network can validate the transaction by examine the blockchain and tracing ownership back to the point of origin.}
\label{fig:NamecoinTransaction}
\end{figure}

As previously stated, Namecoin is noteworthy for being the first naming system to demonstratively achieve all three properties of Zooko's Triangle. It supports privacy-enhanced lookups as anyone can obtain a copy of the blockchain and perform queries against it, names are guaranteed to be unique as each participant (and thus the network as a whole) will reject new blocks that contain names already contained in their blockchain, and it is distributed by nature. While Namecoin is often advertised as capable of assigning names to Tor hidden services, it has several practical issues that make it generally infeasible to be used for that purpose and it fails several of our design requirements. First, to authenticate registrations, clients must be able to prove the relationship between a Namecoin owner's secp256k1 ECDSA key and the target hidden service's RSA key: constructing this relationship is non-trivial. Second, Namecoin generally requires users to download the blockchain before use which introduces logistical issues; as of April 2015 Namecoin's blockchain is 2.45 GB.\cite{BitInfoCharts} Third, although ownership and transfer of Namecoins leaks no more than an ECDSA key, obtaining the Namecoins in the first place (and thus being able to claim a domain name) anonymously is non-trivial due to the logging in the blockchain. Finally, unlike the aforementioned naming systems, Namecoin is not based on published works and literature on it is sparse. Although we also reject Namecoin as a possible naming system for Tor hidden services, OnioNS' design shares some design principles with Namecoin.
Some initial thoughts:
  1. Linking a TorHS RSA key to a d/ name doesn't appear particularly difficult to me (Justin Paupore of BlueShiftLabs talked about a similar idea on IRC about a year ago), although no one has yet written a spec for doing so (it's been on my to-do list for a while).
  2. The blockchain download is known to be solvable using SPV and UNO commitments (which Hugo and Daniel, among others, have been working on).
  3. Jesse is correct that Namecoin has anonymity problems. That said, Bitcoin anonymity tech has improved a lot lately, and continues to improve (e.g. Zerocash's SMPC paper is set to be released in May 2015 -- note that Zerocash is not the only Bitcoin anonymization tech out there, although it appears to be the most secure in terms of privacy). It is not necessary to port these to Namecoin (although this would be nice), because there are Bitcoin to Namecoin exchanges (e.g. ShapeShift) which permit Tor users. We certainly are not at a point yet where Namecoin can be considered anonymous, but there is an apparent path forward. Also, not all TorHS owners need anonymity. Many (e.g. WikiLeaks and SecureDrop) only need location anonymity and encryption/authentication. Namecoin is fully capable of doing this in its current state if routed through Tor (using Whonix or something similar).
  4. Literature on Namecoin is sparse? The vast majority of the code is identical to Bitcoin. Is Jesse claiming that Bitcoin doesn't have literature? I guess "sparse" has different meanings to different people.
It is fully possible that my above comments are addressed elsewhere in Jesse's thesis.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

markm
Posts: 2
Joined: Wed Jul 29, 2015 9:53 am
os: linux

Re: Tor OnioNS

Post by markm »

Wouldn't Tor users be able to simply use/create a onion/ namespace in namecoin and consider therein any entry that does not contain a hidden service's Tor address (minus the .onion), signed by that hidden service itself, to be an invalid entry that ought not belong in the onion/ namespace thus can either be ignored by them or, if they can convince namecoin developers to enforce such a rule, could even be pruned automagically by namecoin miners?

EDIT: Hmm, squatters. The "miners enforce the rule" approach would be needed to prevent squatters simply blocking all onion/ namespace entries from use. But, of course, Tor users could simply look for signed Tor hidden service addresses in all namespaces that exist, so until squatters squat a name in all possible namespaces a hidden service could always choose to create a whole new namespace. Maybe even using its Tor address AS a namespace? How many characters long can a namespace-label be?

-MarkM-

phelix
Posts: 1634
Joined: Thu Aug 18, 2011 6:59 am

Re: Tor OnioNS

Post by phelix »

markm wrote:Wouldn't Tor users be able to simply use/create a onion/ namespace in namecoin and consider therein any entry that does not contain a hidden service's Tor address (minus the .onion), signed by that hidden service itself, to be an invalid entry that ought not belong in the onion/ namespace thus can either be ignored by them or, if they can convince namecoin developers to enforce such a rule, could even be pruned automagically by namecoin miners?

EDIT: Hmm, squatters. The "miners enforce the rule" approach would be needed to prevent squatters simply blocking all onion/ namespace entries from use. But, of course, Tor users could simply look for signed Tor hidden service addresses in all namespaces that exist, so until squatters squat a name in all possible namespaces a hidden service could always choose to create a whole new namespace. Maybe even using its Tor address AS a namespace? How many characters long can a namespace-label be?

-MarkM-
In theory it does work already. See d/torexample (torexample.bit):

Code: Select all

{
    "tor": "yspwdthzg3tnmpzn.onion", 
    "fingerprint": [
        "F3ABCF9B979CAAADD6E3B5E7674A886A25F3F0BB"
    ]
}
I think it should still work if you point a normal browser with .bit resolving to a Tor socket. But it is more difficult to achieve with TorBrowser (which would be safer).
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Tor OnioNS

Post by biolizard89 »

markm wrote:Wouldn't Tor users be able to simply use/create a onion/ namespace in namecoin and consider therein any entry that does not contain a hidden service's Tor address (minus the .onion), signed by that hidden service itself, to be an invalid entry that ought not belong in the onion/ namespace thus can either be ignored by them or, if they can convince namecoin developers to enforce such a rule, could even be pruned automagically by namecoin miners?

EDIT: Hmm, squatters. The "miners enforce the rule" approach would be needed to prevent squatters simply blocking all onion/ namespace entries from use. But, of course, Tor users could simply look for signed Tor hidden service addresses in all namespaces that exist, so until squatters squat a name in all possible namespaces a hidden service could always choose to create a whole new namespace. Maybe even using its Tor address AS a namespace? How many characters long can a namespace-label be?

-MarkM-
I actually have a proposal for making squatting of such names not a problem. I'll post it when it's cleaned up a bit. This is not a super-hard problem to solve. There is still the question of whether it's actually beneficial to force .onion names to sign their corresponding .bit names. I'm trying to get feedback from some of the Tor people on exactly what use cases are relevant here.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

Post Reply