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

[MFPA]

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

Hi


On Thursday 26 January 2012 at 5:03:14 PM, in
<mid:4F218752.90300 at sixdemonbag.org>, Robert J. Hansen wrote:



> So let's see if we can't use a 'Problem',
> 'Goal', 'Requirements' and 'Constraints' model to focus the conversation
> a little bit.
>
> PROBLEM:
>   * Some people want to make it possible to opt out of their email
>     addresses being harvestable on the keyservers.
>
> GOAL:
>   * Give users an optional way to make their user IDs resistant to
>     harvesting.

The use of the word "harvesting" in this context suggests to me a
concern about spamming rather than about privacy. And I would like the
ability to protect my name as well as (or instead of) my email
address.



>
> REQUIREMENTS:
>   * The solution must work within the OpenPGP framework without
>     requiring any extensions.
>   * The solution must work with SKS without requiring any extensions.
>   * The User ID must be searchable (otherwise the solution is trivial,
>     create a User ID with a name but no email address).  If a user
>     searches the keyserver for exactly a given email address, matching
>     certificates must be returned.

Is "without requiring any extensions" a necessary requirement?
If a solution were feasible that required an extension or a local
proxy to handle the keyserver queries, why should it be discarded?



>
> CONSTRAINTS:
>   * Key enumeration.  There are only roughly 10 million login names
>     five characters or less.  Searching those 10 million login names
>     over the top 100 email domains amounts to about a billion queries.
>     Split over a botnet of 100,000 elements, each bot would have to
>     make 10,000 queries.  Even if each query took one second (an
>     unreasonable number: it would substantially impact OpenPGP adoption
>     because people would be furious over the slow speed of lookups),
>     that means a spammer network could break any such blinded hashing
>     scheme in about three hours.

Why would a spammer network bother to generate email addresses and
submit them as keyserver queries, rather than just sending spam out to
them all?

I guess the day *could* arrive when we start receiving spam that is
encrypted to the right key(s) for the email address(es) it goes to,
but I currently see that more as a possibility than a probability.



> ... Looking over this, I don't think that what MFPA wants is possible.
> I just don't.  The key enumeration issue and the ease of getting past
> it, *even if we require each search to take one second to execute*, is
> the gorilla in the center of the room that's threatening to pound to a
> pulp anyone who seriously tries to take on this problem.


I think that what you say is impossible, is more than I am looking for
from this scheme. That strength of protection would be brilliant but
rather pointless in the context.

Lets assume for a moment the goal you have stated above has been
reached, including an airtight solution to the key enumeration issue.
What do we really have? I have names and email addresses in blinded
User IDs on my key and they are believed to be safe for a long time
given the current technology.

For want of a better analogy, the names and email addresses readable
from User IDs on the keyservers are akin to listings in the phone
book. The names and email addresses that cannot be read because they
are obscured in blinded User IDs are akin to unlisted phone numbers.
There is a certain level of protection afforded by choosing not to have
your number listed, but you can still tell anybody the number yourself
and they might accidentally or deliberately pass it on.


>
> Even if you succeed, how many people will join up?

I don't know.

For telephone numbers, as I posted in a thread here in July 2010, the
owners of 78% of the non-business landline numbers in my address book
at the time had made the effort to not have their numbers listed in
the phone books. Mobile phone numbers are unlisted by default; not a
single person had arranged a listing for their non-business mobile.
Not scientific. Not representative. Just the contents of my address
book.


- --
Best regards

MFPA                    mailto:expires2012 at rocketmail.com

Pain is inevitable, but misery is optional.
-----BEGIN PGP SIGNATURE-----

iQCVAwUBTyHkqaipC46tDG5pAQpIFAP+Pk6XUci+VVZaGeN7D3nLM3sZuCRhL03O
iIAwQR0TnTYIUC8uD07TfrQDsXmEOVa3a4yDSX7AGIFgbqG0oKUioEecpDwbZinm
6LKorTNkxbp2J2WiVdaLW+4/fQ5ytjn0jxDKvmoRb3Bf8hgSjCUy/zxkYCQ2KHxT
xoU7IlSeC9g=
=a9JS
-----END PGP SIGNATURE-----