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.
Why names are not encrypted?
Re: Why names are not encrypted?
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.
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
- 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
Re: Why names are not encrypted?
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.
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.
Re: Why names are not encrypted?
And what's the purpose?
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: Why names are not encrypted?
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.
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.
Re: Why names are not encrypted?
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; };
};
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
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 };
Or, if you still want your name visible for others, do this:
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
- 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