hashed user IDs [was: Re: Security of the gpg private keyring?]

[Ben McGinnes]

On 10/03/11 9:23 PM, Hauke Laging wrote:
> Am Donnerstag 10 März 2011 06:17:25 schrieb Robert J. Hansen:
> 
>> while you could conceivably come up with an email address with high
>> enough entropy, it's easier to just use anonymous services and
>> dead-drop emails.
> 
> Of course, you can create a key with UIDs without name and email
> only but such keys are not very comfortable to have in your keyring
> ("What's that?").

There's nothing stopping you from creating an alternate gpg.conf file
(invoked via the --options flag) which points to different default
keys and even alternate keyrings.  Put the entire lot in a TrueCrypt
volume and when it's not in use, people won't be able to decrypt
enough to know about the alternate identities.

> Of course, you can add a UID annotation feature without having the
> hashing feature.  But not having the hashing feature makes it more
> difficult to get the key (and key updates).

Not necessarily.  You can put anything you like in the UID and people
can search on that.  Just running "gpg --search-keys
alt.anonymous.messages" should show a good list of keys where people
have done exactly that over the years.

> Keyserver access is pretty anonymous. If you put keys on a website
> (the address of which the one can have given you who gave you the
> non- public email address) then that is another way to try to reveal
> the identity of the communication partner.

There are plenty of ways to reveal the identity of of correspondents
unless a certain amount of effort has been put into anonymising the
transmission.  Anyone wanting to do this (including just to play
around and see how it works) would be well served by looking into Tor
and remailers.

> I appreciate your effort to consider the problem as a whole. It
> would be a pity to create something that turns out to be useless in
> the end.

Yes and it would be dangerous to create something which instills a
false sense of security.  This hashing idea is an interesting method
of preventing the revelation of a given identity (real or
pseudonymous) from a casual observer, but it does not prevent a number
of things which enable that information to be determined, including
traffic analysis.

> But that is not a problem here any longer: Those people who just
> want to protect their social connections by signing other keys
> without revealing their identity to those who don't know it already
> have no need to cover their target addresses because the marketing
> people and "just curious" normal ones are not capable of reading
> their email traffic. So there already is a use case. Your objections
> for the high security cases are very good to raise awareness but
> point outside the gnupg sphere.

The thing is, the hashed UID idea isn't attempting to address an issue
with GPG per se.  It's attempting to address an issue with privacy of
identity in a larger context; to whit, by attempting to conceal names
and social connections as they are displayed as UIDs and signatures or
certificates.  There are other ways to obtain this information, even
without utilising GPG or examining the body of a message.  Traffic
analysis alone reveals far more than who may have signed someone's key
at some point in time.

> You made a brute force calculation. Why should keyservers allow
> brute force searches for hash IDs? If you use millions of remotely
> controlled idiot PCs simultaneously for that then it may be hard to
> track them but then we are close to a DoS, aren't we?

Robert's already covered this pretty well.


Regards,
Ben

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