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.mur...@mykolab.com





> On 1 Jan 2015, at 02:30, Robert J. Hansen <r...@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.
> 

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Reply via email to