[Freedombox-discuss] identicons are not strong crypto [was: Re: Tap-to-share PGP key exchange]

[Daniel Kahn Gillmor]

On 09/30/2011 03:28 PM, Timur Mehrvarz wrote:
> On 30.09.2011 19:36, Daniel Kahn Gillmor wrote:
>>other
>> I quite like Ted Smith's idea of combining the RF/bluetooth/NFC
>> full key transmission with the QR-code optical verification step.
>>
> 
> Can you explain how the QR-code optical verification step would work
> in here please?

sure:  Bob's smartphone puts a QR-code of Bob's key's fingerprint on its
display.  Then, Alice snaps a photo of Bob's phone's screen, and her
phone interprets the bar code and verifies that it matches the
fingerprint of the key transferred via RF/bluetooth/NFC.  If it doesn't
match, throw out the key, alert the users that something has gone amiss,
and let them restart.  If it does match, Alice doesn't have to read any
hexadecimal strings at all -- she knows that she has Bob's full key
stored on her phone.

(subsequently, Alice and Bob do the same operation in different roles,
so that Bob can verify Alice's key)

What's really going on here?  the important bits are:

Assuming Alice and Bob are sighted humans, they can observe their
surroundings, and ensure that their cameras are taking photos of the
expected data (just the screen of the other phone), and aren't
compromised by fancy antennas hiding in the bushes or whatever.  Then
they rely on the cryptographic digest in the fingerprint to bootstrap
their way into confidence that the larger file (transferred wirelessly)
does indeed have the key the peer meant to send them.

does this make sense?

	--dg

PS There's still a minor gap here, for a motivated and skilled attacker
who can control the airwaves: they can make it so the user gets the
peers' key, but gets a different set of OpenPGP certifications on it.
The key fingerprint alone wouldn't let users ascertain that all the
associated certifications were correctly transferred.

however, users are going to need to refresh their keys at some point
anyway to get updated certifications, revocations, changes in expiry,
etc.  So this is just another instance of that situation.  If you really
wanted to be sure that the entire key+certifications packet collection
made it through, you could have the QRCode contain two lines instead of
one, something like:

 OPENPGPFPR4: 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9
 X-OPENPGP-PACKETS-SHA1: 2A1AC9A4AE0A62AADA8A05015B96FFC1BD1FB31A

it's twice as much data to fit in the QR code (which makes capturing a
bit more finicky), but maybe that's a tradeoff people could make.

 (i just invented the X-OPENPGP-PACKETS-SHA1 header, and calculated it
with "gpg --export $GPGID | sha1sum", but i'm sure you could come up a
similar approach that would work well).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20110930/ae1532a8/attachment.pgp>