photo-ID

[Sandeep Murthy]

Hi

Sorry if I misunderstood, but I didn’t say that the photo ID should
be allowed to be as large as possible, and this is not allowed anyway
by, for example, apps like GPG Keychain.

But I was wondering … instead of attaching a photo to a public key,
why not attach a hash of the photo using an image hashing
algorithm?  I don’t know much about image hashing (but this
discussion has now made me more curious to learn) but such an
algorithm is supposed to calculate a hash value for an image that
could be compared against **perceptually similar** images.  Since this will
be a string it would not lead to the blob attack scenario described before.

I found some interesting resources including a paper describing some
algorithms

http://www.phash.org/docs/pubs/thesis_zauner.pdf

and there are also several API implementations

    http://www.phash.org/ (C++)
    https://pypi.python.org/pypi/ImageHash (Python).

Would it not be possible for gpg to incorporate these so that a user
can attach a set of hash values for their photo(s) to their public key that
recipients could check against some other source?

Sandeep Murthy
s.murthy at mykolab.com





> On 1 Jan 2015, at 02:30, Robert J. Hansen <rjh at sixdemonbag.org> wrote:
> 
>> I don’t agree.
> 
> With what?
> 
>> Why isn’t the photo ID feature not useful?
> 
> I never said it wasn’t.
> 
> I said the photo ID feature, *as used within OpenPGP certificates*, isn’t.  There’s a big difference there.
> 
> Frankly, the possibility of allowing arbitrarily-sized binary blobs to be attached to OpenPGP certificates scares the ever-living bloody f*ck out of me.  (I try to avoid vulgarity, but I’m using it here to underline just how critical this problem is.)  The keyserver network, as currently configured, is susceptible to a total worldwide denial-of-service attack that can be conducted by just one malicious individual who figures out how to turn the photo ID feature into an attack vector.
> 
> I’ve discussed this attack vector on the keyserver mailing list.  The general consensus is that the attack that I’m concerned about is real, and would result in serious disruption to the global keyserver network for an extended period until we developed countermeasures — but those countermeasures would fundamentally transform the keyserver network and force us to radically redefine our expectations of service.
> 
> So, yeah.  Photo IDs on OpenPGP certificates is really another way of saying “OpenPGP supports putting arbitrarily-sized binary blobs on certificates that will be replicated worldwide and, depending on local jurisdictions, will immediately convert keyserver operators into felons.”  That’s enough for me to declare the entire OpenPGP implementation of photo IDs a staggering clusterf*ck of failure, and something that I really wish would get dropped from the OpenPGP spec.
> 
> (I’m not going into specifics about the attack because I don’t want to give anyone ideas, not in any expectation that it really matters a damn.  My write-up is available, but I’m not going to help you find it.)
> 
> 
>> Surely any piece of
>> information that would help another person, with whom you
>> are proposing to communicate, to identify you first, is a good
>> thing.
> 
> Sure, but it would be nice if it didn’t expose people to phenomenal risk while we’re at it.
> 
> We have better ways of doing photo IDs — e.g., keybase.io.  I think we should use them.
> 
> You’re arguing against something I never said and don’t believe.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 873 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </pipermail/attachments/20150101/9d8e89cc/attachment.sig>