However, there's a cheap, compatible, technical hack that
substantially increases the difficulty of front running attacks
without any new policies: allow WHOIS searches on hashes of domain
names. The way this would work is that the WHOIS operator would create
a parallel tree of phony domain name registrations in WHOIS. For
instance, if I registered example.org
, then they would
also create an entry for SHA-1(example.org)
=20116dfd6774a9e7b32eddfea3f6cb094e38fc3f.org
(we might need to register a new TLD to make this work and guarantee no
collisions) and populate
it with the record for example.org
. Then, I could
locally compute the hash for each domain name I wanted to check on
and easily verify its existence or nonexistence.
Other properties:
- The WHOIS server doesn't get the name being searched for, just the hash. It's in principle possible to iterate through all possible names to see what hashes match, but this isn't practical for any at all unusual name, and of course most obvious names have already been registered.
- The WHOIS protocol doesn't need to change: this looks like a valid domain name.
- It's easy to generate the records on the server side: just run some script over your WHOIS database.
- It's easy to enhance your WHOIS client to do the hash first, but even if you don't, command line hash programs are easy to get.
- Note that there is some chance of name collisions
You still might need ICANN or someone like them to force the operators to do this, since it's not clearly in their interest. On the other hand, direct cost to them is so low that it's hard to really object to on difficulty grounds.
Technical Note 1: This problem is related to private information retrieval but is dramatically easier because we don't care about the server knowing what record we fetched if it exists, only if it doesn't exist. Actually, we only care if the record exists. We don't need the record itself, which makes the problem yet easier.
Technical Note 2: It would be nice to have a solution that didn't allow dictionary attack. The best solutions I know use Bloom filters.
- The server can send you a Bloom filter with the names he knows. This is completely resistant to dictionary attack but is still of linear size in the number of inserted domain names per key. And, of course, there are false positive issues.
- The client can request the values of specific bits in a server-side Bloom filter. By asking for a superset of the bits you want you can get some dictionary attack resistance. This has much lower space requirements, but still leaks some information to the attacker—I haven't done the math on how much, but it clearly scales to some extent with the number of bits requested, with the limit being all of them.
Note that the hash solution isn't technically constant size in the number of registered names either—the required hash size for any given false negative probability depends on the number of registered names. However, since 160 bits is so small people just think of this as constant size.