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]

On Wed, 25 Jan 2012 18:19:56 -0500 Daniel Kahn Gillmor 
<dkg at fifthhorseman.net> wrote:

>i'm confused by your proposal.  some clarifying questions follow:

sorry,
upon re-reading it, noticed that I left out mentioning some steps 
that I thought through, but didn't post ;-(

-----

>> [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.

And leaves the encrypted message on his own website, so that 
whoever he decides to give the passphrase to, can easily recover 
the session key.

-----

>This seems like it might just be an elaborate way to ask for a 
>random
>number, but i'm not sure what the intent is.  Is it just trying to 
>get a
>decent-sized chunk of randomness?  or is there another purpose?  
>if it's
>just about randomness, rephrasing more simply might make this 
>clearer.

It's about randomness that can't be brute forced by today's attack 
resources, but easily communicatable.

-----

>> [2] Hash the [(preferred key name)+(seesion key)+(e-mail 
>address)]
>
>What is the "preferred key name" ?  are you expecting users to 
>name
>their keys?

whatever their preferred e-mail name is,
i.e,  alice.surname at domainname.com

-----

>> [3] Generate the key with the uid of 
>> [(preferred key name)+(session key)+(e-mail address)]
>
>What happened to the hash here?  are you suggesting that the User 
>ID is
>the digested form or the non-digested form?

the actual hash of the [name+sessionkey at domainname.com]
i.e.

SHA256 of alice.surnameACed72...F at domainnamne.com

-----
>
>> [4] Identify the key to the server by the hash.
>
>OpenPGP certificates are handed to the keyserver as is; the 
>keyserver
>chooses how to index them.  What do you mean by "identify the key 
>to the
>server by the hash" ?

Here there are 2 ways to go

(a) create the key with the uid of 
alice.surnameACed72...F at domainnamne.com  and send it to the 
keyserver, with instructions to index it by its hash as the only 
search criteria
(major headache for backward compatibility, as you rightly pointed 
out)

or

(b) create the key with uid as the hash itself
i.e.
SHA256 of alice.surnameACed72...F at domainnamne.com

This poses no backward compatibility problems, and is easily 
computable by someone who knows Alice's name, e-mail address and 
passphrase to the symmetrically encrypted message she posted on her 
site.

-----


>> 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.)
>
>how does your proposal above compare to David Shaw's (seemingly 
>simpler)
>proposal, or to the proposal i outlined elsewhere in this thread?

-----

it makes the 'anonymous' key id less likely to be duplicated,
i.e. BE452FD9

but is basically the same idea as your's and David's


anyway,

it seems easier to just give the fingerprint ;-)
than to go through all the above,

but it's a possible doable approach ...



vedaal