hashed user IDs redux [was: Re: Creating a key bearing no user ID]

Daniel Kahn Gillmor dkg at fifthhorseman.net
Wed Jan 25 23:55:12 CET 2012

On 01/25/2012 07:52 AM, Hauke Laging wrote:

> IIRC there is no single technical issue which is regarded as a problem about 
> which it is unclear whether it can be solved.

i've given a fairly detailed technical writeup of why i've stopped
pursuit of this particular goal.

> The dispute is mainly about the interpretation whether is makes sense to offer 
> such a feature given the amount of addresses that cannot be protected: This 
> would only work for addresses which cannot be found by enumeration. Such 
> addresses are not "nice". mailinglisten at hauke-laging.de need not be protected 
> that way. This feature would require something like 
> mailinglisten--noenum-yvsYiP9y at hauke-laging.de against spammers,
> mailinglisten--noenum-zTTgFzNHU3RnkFyAxJuYMbs7 at hauke-laging.de against real 
> threats (government agencies in e.g. China).

If people use e-mail addresses like this, then they could probably just
derive the high-entropy-portion of their e-mail address from their key's
fingerprint directly, and attach only a User ID like "anonymous".


  dkg--noenum-0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 at fifthhorseman.net

Then no keysigning would be needed as anyone who knows the e-mail
address already knows the key to use, and the key is fetchable from the
keyservers by keyid directly.

This can all be done with the current toolchain, without modification,
afacit.  The only problem is that you'd have to adjust your MUA to tell
it which key to use explicitly for mailing to addresses like this.  If
you think this is the way to go, maybe you should talk to MUA
developers, or propose a mechanism or heuristic gpg could use to
pre-select keys from e-mail addresses like this.

> The technical questions would have to be answered but could be rather easily. 
> But why write specs if noone is willing to implement it, why write code if it 
> would not be accpeted, why point at IETF though the other way round is 
> expected there?

Clearly people are interested in the idea and have done some work to
think about it how it can be done, and what would be the right way to
go.  No one who implements something someone else suggests is going to
want to do it without a concrete, well-discussed spec beforehand.
Several of us have had the discussion that resulted in my deciding that
the tradeoffs for the scheme we came up with (hashed userids) wasn't
worth the extra complications.

Please propose an alternate scheme that you think would be an
improvement if you think such a scheme exists.  Hopefully, it will get
critiqued, though there are no guarantees that anyone will implement
whatever scheme (if any) finally overcomes the objections raised during


-------------- 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/9752bac3/attachment.pgp>

More information about the Gnupg-users mailing list