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

[MFPA]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi


On Wednesday 2 March 2011 at 8:27:50 PM, in
<mid:4D6EA846.4080402 at sixdemonbag.org>, Robert J. Hansen wrote:



> The analogy continues to break down.  "Binding," in the
> context of the analogy, means "if someone breaks this
> instruction, they will be hurt."  Maybe the government
> will start a criminal prosecution, maybe you have
> recourse in a civil lawsuit, but ... ultimately, "if
> someone breaks this instruction, they will be hurt."

> Okay, fine: who are you electing to be the
> hurt-inflicter for the OpenPGP community?  And in the
> absence of a designated hurt-inflicter, how can there
> be a "binding instruction"?

You are going off at a tangent. The mechanism for preventing the phone
number being obtainable from a query of the phone book or directory
enquiry services is not relevant; just the fact that it can easily be
done.

Consider these scenarios:-

1.      I have a phone number that you don't know.
        This phone number is listed in the phone book and at directory
        enquiries.
        It is trivial for you to obtain the number.

2.      I have a phone number that you don't know.
        This phone number is not listed in the phone book or at
        directory enquiries.
        It is harder for you to obtain the number.


A parallel exists with:-

3.      I have email addresses that you don't know.
        These email addresses are readable from my key's user IDs.
        It is trivial for you to obtain these email addresses.

4.      I have email addresses that you don't know.
        These email addresses are not readable from my key's user IDs.
        It is harder for you to obtain these email addresses.


"This phone number is not listed in the phone book or at directory
enquiries" is easily achieved by being ex-directory; this does not
affect the usefulness of my telephone service. It is only easy because
the appropriate mechanism has been put in place to achieve it.

"These email addresses are not readable from my key's user IDs" is
easily achieved by simply not including them in the user IDs. This is
easy because the user ID field is free-text and doesn't have to be
Name (Comment) <email address>. This adversely affects the usefulness
of my key, since MUAs commonly rely on the email address in the user
ID for key selection.

Hashed user IDs are a possible alternative mechanism to achieve "these
email addresses are not readable from my key's user IDs" that could
have less of an adverse affect on key usefulness.


> The analogy you're drawing is appealing at first
> glance, but the more I look at it the more it breaks
> down.

I said "in this respect the two are similar."
You appear to be saying "they are not similar because in these
other respects they are different."



>> It is also much easier to create new email addresses
>> than it is to change phone numbers.

> I would *far* rather change my phone number than change
> my email address.  Probably a total of 50 people have
> my phone number: if I change it, big deal.  If I change
> my email address, I'd probably need to inform upwards
> of a thousand people of the change.

A good point well made.

I was comparing the effort involved in actually creating a new email
address (a few seconds to a couple of minutes at the keyboard) to the
effort involved in actually getting the phone company to change a
phone number (ringing the phone company, navigating their stupid menu
system, eventually getting through to a customer service agent in
foreign parts who barely speaks English, trying to make them
understand, discussing the reasons why they should provide the number
change - such as nuisance phone calls you have been receiving, wait
for the change to happen, chase up the billing errors, etc.).


- --
Best regards

MFPA                    mailto:expires2011 at ymail.com

Never lean forward to push an invisible object.
-----BEGIN PGP SIGNATURE-----

iQE7BAEBCgClBQJNbtQRnhSAAAAAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf
a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC
OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB
MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pARsD/1iG
sr2ROg6NOqTJDhasftiQwXYZ9YiEFK4TacuT1TIl8MRYynMJU35EgqioWvh3B3LJ
Mfqaqvff9OlK8wyrmbQ585USxmXYf7aDtsfI3tqzrvgoYIMpl/iLRxpN4JGwSpv1
D2r2jlIHUq1LehNUYjbl0DGR+1kishfWhAHkxiSO
=euzF
-----END PGP SIGNATURE-----