Why hashed User IDs is not the solution to User ID enumeration (was: Re: Creating a key bearing no user ID)

[vedaal at nym.hush.com]

Daniel Kahn Gillmor dkg at fifthhorseman.net wrote on
Tue Jan 24 16:21:35 CET 2012 :

> The trouble is that domain names (and e-mail addresses, and human 
names)
are very low-entropy things, and actually are pretty easy to 
enumerate
and test.

-----

Aren't there simple ways around this?

Here's a sort-of workaround, (inelegant, but can be tweaked and  
improved on if it's something desirable) :

[1] The person who wants to create a new key, first generates a 
symmetrically encrypted gnupg message, and decrypts it and gets the 
session key.

[2] Hash the [(preferred key name)+(seesion key)+(e-mail address)]

[3] Generate the key with the uid of 
[(preferred key name)+(session key)+(e-mail address)]

[4] Identify the key to the server by the hash.


These steps would defeat harvesting tools enumerating the low 
entropy names and hash ranges.


(Am not advocating this, just pointing out a possible approach if 
you want to take this further.

Personally, I agree with David Shaw, that the problem can be 
avoided by just generating a random UID (maybe a truncated session 
key) and giving the fingerprint and UID to anyone who wants to look 
it up on the keyserver, as well as the e-mail address separately to 
whomever the user wants to correspond with.)

fwiw,
Have never received any keyserver id related spam on some of my old 
V3 keys that are used only for remailer list correspondence and 
have been on keyservers for well over a decade.


vedaal