Why names are not encrypted?

Post Reply
KGB
Posts: 2
Joined: Fri Apr 27, 2018 4:00 pm

Why names are not encrypted?

Post by KGB »

Anybody can collect all id/ entries and spam their emails. Tor implemented V3 onion addresses to protect hidden sites from discovery of their existense, but public .bit domains destroy this feature.

Instead of storing a plain text name its hash can be used. It uniquely identifies a name. You cannot register a name second time, because the hash will be the same. If you know a name, you can check that it's registered and can decrypt its value with a key derived from the name.

This improvement can be implemented in a separate namespace without support in the Namecoin protocol, but it would be better to allow register secret names in existing namespases to have resolvable secret domains and identities.

virus_net
Posts: 82
Joined: Tue Aug 22, 2017 1:22 pm
os: bsd
Location: Moscow, Russia
Contact:

Re: Why names are not encrypted?

Post by virus_net »

And how DNS will work ? For your opinion.

P.S. If you want your own not public domain, so just create your own zone and use it in own DNS server. Anyone who knows name and DNS IP (and who will be allowed by you) can resolve this name.
bitname.ru:
- whois service for .bit: whois.bitname.ru or whois.bitname.bit
- dns servers for .bit: dns1.bitname.ru dns2.bitname.ru or dns1.bitname.bit dns2.bitname.bit
- bit domains statistics
github

KGB
Posts: 2
Joined: Fri Apr 27, 2018 4:00 pm

Re: Why names are not encrypted?

Post by KGB »

1. You want to resolve a name.
2. You hash it.
3. You find this hash in the public database and obtain its encrypted value.
4. You hash the name again using a different hash algorithm.
5. You decrypt the value with the last hash as a key.

omarabid
Posts: 5
Joined: Tue Oct 25, 2016 12:47 pm
os: mac

Re: Why names are not encrypted?

Post by omarabid »

And what's the purpose?

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

Re: Why names are not encrypted?

Post by biolizard89 »

So there are a few reasons why this isn't supported right now.

1. Trying to encrypt data with a low-entropy key (such as a Namecoin identifier) and then add it to an immutable ledger is generally a *really bad* idea. It's basically the equivalent of using a low-entropy password on a website, and then deliberately leaking the website's unsalted password hash database onto The Pirate Bay.
2. As virus_net correctly points out, you can delegate from Namecoin to DNS, and you then automatically gain all of DNS's nice features for rate-limiting adversaries who are trying to walk your zone. This is a pretty easy problem for DNS to solve, at least compared to Namecoin.
3. If the name identifiers aren't public, that makes it much harder to detect homograph attacks. (Credit to Greg Maxwell for pointing this out.) In theory you could do some magic with zk-SNARKs to prove that the hash preimage isn't a homograph of any pre-existing hash preimage, but at that point we're talking about an R&D budget that significantly outweighs our currently available resources (and gives minimal useful gain, see the above 2 points).

Regarding email address secrecy and spam, this is a design issue in SMTP and it's not something Namecoin can be expected to solve. If you're using SMTP and you care about security, you probably are also using OpenPGP, and the OpenPGP ecosystem already leaks the existence of your email address in most configurations. PoW systems like Bitmessage solve this problem far more effectively than Namecoin encryption would. I'm open to suggestions on the v3 onion service existence issue, but honestly I suspect that if you're operating an onion service whose existence is intended to be a secret, you probably *don't want* a low-entropy identifier for it, which means Namecoin is not something you should be using for that.

If you have a threat model that I haven't considered, under which you think this scheme makes sense, please tell us what it is.

FWIW, I don't see any particular problem with storing identifiers as hashes in the blockchain, since it would limit the storage from 255 bytes down to 32 bytes. However, to get around issue (3), the preimages would need to be stored in a SegVal-style data structure. Also this would be a soft-hard-name-fork, whereas SegVal in its current draft form is a softfork.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

virus_net
Posts: 82
Joined: Tue Aug 22, 2017 1:22 pm
os: bsd
Location: Moscow, Russia
Contact:

Re: Why names are not encrypted?

Post by virus_net »

KGB wrote:
Sat Apr 28, 2018 11:55 am
3. You find this hash in the public database and obtain its encrypted value.
...
5. You decrypt the value with the last hash as a key.
And which soffware will do this ? Or you going to do this by your hands everytime ?
I also dont`t understand purpose.
"I don`t want domain name be used by others" equal to not public
Not public = own dns zone -> any names, as many names -> 2 min configuration in own DNS -> full control on who/when/where

As examle, I have own zone .rus (It was attempt to register own TLD in OpenNic project, but it failed bc they dont like russians)
BIND config:

Code: Select all

zone "rus" {
    type master;
    file "master/rus.zone";
    allow-transfer { allowed-dns; };
};
master/rus.zone:

Code: Select all

$ORIGIN .
$TTL 3600       ; 1 hour
rus                IN SOA  ns1.rus. noc.mega-net.ru. (
                                2017091907 ; serial
                                3600       ; refresh (1 hour)
                                3600       ; retry (1 hour)
                                604800     ; expire (1 week)
                                86400      ; minimum (1 day)
                                )
$TTL 86400      ; 1 day
                IN      NS      ns1.rus
                IN      NS      ns2.rus

$ORIGIN rus.
$TTL 3600       ; 1 hour
ns1             IN      A       91.217.137.1
                IN      AAAA    2001:67c:13e4:11::1:1
ns2             IN      A       91.217.137.2
                IN      AAAA    2001:67c:13e4:12::1:1
mx              IN      CNAME   mx.mega-net.ru.
;
www             IN      A       91.217.137.34
register        IN      CNAME   www
www.register    IN      CNAME   register
reg             IN      CNAME   register
www.reg         IN      CNAME   register
whois           IN      CNAME   www
www.whois       IN      CNAME   whois
abuse           IN      CNAME   www
www.abuse       IN      CNAME   abuse

$ORIGIN opennic.rus.
opennic.rus.    IN      MX      5 mx
opennic.rus.    IN      A       91.217.137.34
www             IN      CNAME   opennic.rus.
mx              IN      A       91.217.137.33

$ORIGIN vi.rus.
vi.rus.         IN      A       91.217.137.34
www             IN      A       91.217.137.34
That`s all.
So now you know the DNS servers for .rus and if you do forward zone in your own DNS or put string to you comp hosts file you will be able to open http://www.rus web page or other name from list above.
Also you can use:

Code: Select all

allow-query { valid-hosts };
In zone section above. To limit who can query names from zone.

Or, if you still want your name visible for others, do this:
biolizard89 wrote:
Sat Apr 28, 2018 8:25 pm
you can delegate from Namecoin to DNS
Put ns servers list to the json value for your .bit domain and control it in bind or other software that can handle DNS requests. NodeJS script as example.
bitname.ru:
- whois service for .bit: whois.bitname.ru or whois.bitname.bit
- dns servers for .bit: dns1.bitname.ru dns2.bitname.ru or dns1.bitname.bit dns2.bitname.bit
- bit domains statistics
github

Post Reply