Re: [tor-dev] Namecoin .onion to .bit linking

[Jeremy Rand <biolizard89@xxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/19/2015 03:31 PM, OnioNS Dev wrote:
> 
> 
>> On 05/19/2015 10:02 AM, Daniel Martí wrote:
>>> I'm not familiar with Namecoin, but I thought I'd just point
>>> out that someone will be working on OnioNS, the onion name
>>> system, as part of the SoP in Tor. The person who will be
>>> working on it just sent an e-mail to this very list yesterday.
>>> 
>>> You two seem to be after the same "human-readable way to
>>> access .onion domain names" target as you yourself described,
>>> so there might be room for collaboration.
>> I'm aware of OnioNS, but haven't yet had time to thoroughly read
>> the proposal.  It's certainly on my to-do list, if nothing else
>> for cross-pollination of ideas.
> 
>> - -Jeremy
> Yes, I'm here. Last year I explored Namecoin as a possible 
> alternative DNS for Tor hidden services.

Indeed, we conversed a few times last year about that topic.  I'm
quite looking forward to catching up on what you've come up with since
those early conversations -- more ideas are always a good thing.

> I spent some time over it, but I also ran into the same problems 
> previously mentioned above: how to link HS RSA keys to Namecoin
> ECDSA keys. I came up with two solutions: sign the Namecoin key
> with the HS key and embed that signature in the blockchain, or
> introduce a new blockchain that relied on the same cryptography as
> hidden services (RSA, Ed25519, ECDSA, etc, as long as they
> matched).

I hadn't actually thought of the idea of using a parallel blockchain
with different signature opcodes as a solution for this particular
problem.  I'm not sure if you're aware, but some people have proposed
creating altcoins that use quantum-resistant signatures such as
Lamport signatures just in case such quantum resistance turns out to
be useful, so that actually isn't as crazy an idea as some might assume.

Generally for this purpose, I think signing a Namecoin name with a HS
key makes more sense than a parallel blockchain.  Signing a Namecoin
*address* (what I assume you mean by key) would be harder, because
Bitcoin-based currencies like Namecoin intentionally don't reuse
addresses, so a name will get transferred to a new address every time
it is altered or renewed.  Of course, then you need to deal with the
ability for the .onion key to revoke a Namecoin name's authority.

> As I mentioned in the ACM paper, it's non-trivial to build this 
> correlation and I came to the conclusion that solutions would look 
> more like a hack than an elegant solution.

Certainly not trivial, but it doesn't seem like an overly complex
issue to attempt, to me.  But that's why I'm asking for feedback --
I'd prefer that any solutions have holes poked in them before
implementation effort is expended on them, and certainly you've
expended a lot more thought on this particular topic over the past
year than I have.  The biggest issue I'm aware of is cross-protocol
attacks... are there other pitfalls you've encountered that I should
be aware of?

> Moreover, even if the correlation could be built, it's impractical
> to require clients to download the whole blockchain before use, so
> you still have to address the issue of preventing name servers
> from lying.

SPV-based systems appear well-suited to solve that problem for most
cases.  HashEngineering created a Namecoin port of the BitcoinJ SPV
library (it only took him a few days, I think), and used it to create
an Android Namecoin client.  He didn't implement parsing of the name
script opcodes, but that's not a super-complicated thing to do.
Almost all of the code in Namecoin is the same as Bitcoin; the
differences are pretty minimal, so Bitcoin's lightweight client modes
such as SPV work pretty much verbatim when applied to Namecoin.
Actually getting a working product that handles the name opcodes is
mainly a matter of implementation rather than any novel engineering.

SPV by itself does allow a peer to falsely claim that a name hasn't
been updated after the block that the SPV proof is for.  Daniel Kraft
(Namecoin's chief scientist) is experimenting with a fix for that, by
having miners place a merkle trie commitment of the unspent name set
in each block's coinbase transaction, whose accuracy would be enforced
by blockchain validation.  This mode (abbreviated SPV+UNO-CBC) would
ensure that name values returned over SPV are current (up to a
sufficient block depth to avoid a lucky miner being able to mine a few
invalid blocks with bad commitments; 12 blocks seems to be reasonable
there).

> I hope you can see that it's a difficult problem. I think Namecoin
>  could use a solution if you come up with one, and I would be 
> interested in hearing about it. I came to the conclusion that 
> Namecoin would not work and wrote something different. Namecoin
> does many things well and I took those good design ideas, but I
> also changed the setup to solve many of its weaknesses. Namecoin,
> GNS, and OnioNS are good alternative DNSs, each with their own
> approach. Let's see if we can work together here, we might be able
> to help one another.
> 
> Jesse V.

Totally agree -- working together is preferable to worrying about
which solution is "the right one", so to speak.  These things all have
their benefits and drawbacks.

Cheers,
- -Jeremy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVW61hAAoJEAHN/EbZ1y06dQIP/36kc3ayQdyoXDHNuNRLOq92
cNcpZo9kENR/YlTMZrxeXlHUrI0a4ZjQZVcuTBSRruTWzSQzkNC6YlPo7Ff6SK6q
iyzBjT1UWA6nXigAhjkkx7Z549wo9bJWhL7h/KVsPJz7DtC+AxDw3u8sE/lkgkic
WrnV8Y7fnDdbhiSDmMyWhQDtrgtTMWIKS8jRv9vQxryRUrjCja3I4ErReOAlXYKU
Ms7yEg3giGYVF763h4dO4hUqU32sayPGj6is9o0Zyq1l8EG1oQk0lbxUEvQbhkKA
77AXIhWG/+kAAvWmHvfqDEGIVioXnYtTp2/1PsyfCYJRJ+GHpF2b79gqfskqJy9A
H/bk+E67kP88I6PH3iomHzZCdsUczBm0IPyYI6AJbV7dgnFg8Wp6gt54/4Bzj/1h
Q9gR0xjfIaddYzh6dDUcAVT1y3lmeL4fHrR0OcVcXen/tDzz8HBIFCjNri1iJxrs
jggIYq7b9c5yozZ1yC/vXpDGvGdnuNcaD36B0nVs9lZ26Be1dzFAcjhK8MvC/s1G
rh/U+jQhx4z9MpObfBn80h4ABLUsSYAjXiF1ybU+S1SCxRUg6rJc3QyT20Qf6o9/
xNBXFRdy+oZXVYIyS6k3/HZ7jIx1Z1v98LvJ2FmQaPZKulMlWywVDkLl5eKNKXfv
JWxClZ80TPvjN9dpBl6b
=Kt9w
-----END PGP SIGNATURE-----
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev