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. >
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
