Why hashed User IDs is not the solution to User ID enumeration

[Daniel Kahn Gillmor]

On 01/25/2012 08:02 PM, MFPA wrote:
>> Ultimately, i don't think the tradeoffs for this scheme
>> are worthwhile for the marginal and limited gain that
>> the proposal provides.
> 
> Definitely limited; I think of it as little more than a
> privacy-enhancing defence against casual snooping rather than a
> security measure. But is it really so marginal?

Compared to the complexity and confusion downsides on a protocol that is
already complex and confusing, yes, i believe the potential gains here
qualify as marginal.

It only takes one party to reverse the User IDs and publish the reversal
for everyone to be able to trivially enumerate them already.

> As I see it, you either:-
> 
> include the UIDs in non-human-readable form (e.g. hashed) in the key
> that's distributed.

which, as i documented in the earlier message, is no better defense
against enumeration than NSEC3.

> or you distribute UIDs separately from their key.

how?  where?  via what mechanism?  how do you determine that the right
key is associated with the relevant User IDs?

> or when you download a key the copy you get includes only the UID you
> requested.

eh?  are you talking about modifying the keyserver protocol?  are you
aware that full keyserver dumps are available for the taking, and that
anyone can run a keyserver?

I remain unconvinced that this is a serious proposal, unfortunately.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20120125/9db14715/attachment.pgp>