Wolf: Stop it with those short PGP key IDs!

Posted Jun 4, 2016 0:54 UTC (Sat) by DOT (subscriber, #58786)
In reply to: Wolf: Stop it with those short PGP key IDs! by jberkus
Parent article: Wolf: Stop it with those short PGP key IDs!

You could encode it as a QR code. Would be a rather complex image, but quite easy to understand for a computer.

Wolf: Stop it with those short PGP key IDs!

Posted Jun 4, 2016 0:55 UTC (Sat) by k8to (guest, #15413) [Link] (3 responses)

Could image-based representations of values have attacks around similar-but-not-same values?

I find the idea alluring.

Wolf: Stop it with those short PGP key IDs!

Posted Jun 4, 2016 1:21 UTC (Sat) by DOT (subscriber, #58786) [Link] (2 responses)

QR codes look like noise to people, but they are very reliably read by computers. It's an error correcting code, so the distance between two adjacent values is very high.

I think the attacks mentioned in the article are averted especially because no humans can be involved in the conveying of the images. They are easy to scan, but impossible to summarize or copy by hand.

Wolf: Stop it with those short PGP key IDs!

Posted Jun 5, 2016 0:06 UTC (Sun) by lsl (subscriber, #86508) [Link]

> QR codes look like noise to people

Not anymore! You can also make them look like pictures of Peter Weinberger (the 'w' in awk).

http://research.swtch.com/qart

(the other articles there are worth reading, too)

Wolf: Stop it with those short PGP key IDs!

Posted Jun 7, 2016 23:29 UTC (Tue) by gwolf (subscriber, #14632) [Link]

Back in 2010, Daniel Kahn Gillmor insisted on having all DebConf nametags printed with the PGP fingerprint as a QR code. His reasoning was quite sound: Humans suck at crypto. For keysigning, we could perfectly well take a picture of a person's face+nametag, and run a QR recognition on that; signing the keys would have an effect of making you remind a person instead of just scratching your head (and probably signing blindly, what often happens).

Daniel's idea is sound and very good, provided every person receiving a nametag is able to check right away that QR's content. I don't know why we have abandoned the idea, but it might be worth pushing again for DebConf this year.

Wolf: Stop it with those short PGP key IDs!

Posted Jun 4, 2016 18:05 UTC (Sat) by cortana (subscriber, #24596) [Link] (8 responses)

PGP keys can be a bit too large for comfortable use with QR codes. Even with --export-options export-minimal my key is over 2 KiB. Last time I tried to round trip my key through a printed QR code, the tool I used to encode the data (qrencode) wouldn't correctly process binary data, so I had to increase the size with an ASCII encoding, and then the tools I tested decoding with (can't remember which ones) crashed.

Maybe in 10 years, curve25519 will be more widely supported and keys will be shorter. :)

Wolf: Stop it with those short PGP key IDs!

Posted Jun 4, 2016 21:58 UTC (Sat) by dsommers (subscriber, #55274) [Link] (3 responses)

Except I doubt EC crypto will be that popular when we hit the era of post-quantum computing, if I've understood crypto experts correctly. And to be post-quantum safe, we're talking about quite a lot bigger keys to share than what we're used to today in addition to new crypto algorithms.

When also considering the amount of research efforts in the quantum computing area, this might not be as far away that many would prefer.

But QR encode the full fingerprint and a matching e-mail address, and you might very well have a far better QR code which can download a key easily, regardless of the key size.

Wolf: Stop it with those short PGP key IDs!

Posted Jun 5, 2016 18:05 UTC (Sun) by linuxrocks123 (subscriber, #34648) [Link] (2 responses)

I wouldn't worry about quantum computers yet. We're still a long, long way away from solving the engineering problems necessary to build one. They may still turn out to be unsolvable.

Wolf: Stop it with those short PGP key IDs!

Posted Jun 6, 2016 19:45 UTC (Mon) by dsommers (subscriber, #55274) [Link]

Really?

https://www.youtube.com/watch?v=DZ2DcILZAbM
http://www.research.ibm.com/quantum/
https://www.technologyreview.com/s/537041/ibm-shows-off-a...
http://www.computerworld.com/article/2501748/emerging-tec...

Wolf: Stop it with those short PGP key IDs!

Posted Jun 8, 2016 11:27 UTC (Wed) by szbalint (guest, #95343) [Link]

We're also a long way away from deprecating algorithms imperiled by quantum computing. It'd take decades and pretty serious investment to prepare for a post quantum world so it shouldn't just be neglected.

Wolf: Stop it with those short PGP key IDs!

Posted Jun 5, 2016 7:56 UTC (Sun) by rmayr (subscriber, #16880) [Link] (2 responses)

Just for security purposes, there is no reason to encode the full key in QRcode. As the QRcode can be seen as a so-called out-of-band / auxiliary channel that is assumed to be authentic (in contrast to e.g. confidential), transferring a long-enough hash of the key is fully sufficient. The full key itself can then be exchanged in-band (i.e. on the same channel used for the actual communication, e.g. HTTP download or whatever) and verified that it matches the hash on the receiver side. Just use SHA2-256 or Keccak (SHA3-256), encode the 32 bytes in QRcode along with an identifier (e.g. the email address you'll probably have in the QRcode on your business card anyways) and you're good. The current PGP "fingerprint" is pretty much exactly that.

(Disclaimer: In my research group, we design crypto protocols and have been proposing various out-of-band channels for nearly a decade now. The above may therefore be biased.)

Wolf: Stop it with those short PGP key IDs!

Posted Jun 5, 2016 13:44 UTC (Sun) by sprin (guest, #101377) [Link] (1 responses)

rmayr, can you link to the proposals for out-of-band channels?

I am exploring a system that uses SHA2-256 for OOB verification of a bundle containing a PGP pubkey, a PGP implementation, a form for a message, and some glue code that connects to a HTTP-to-SMTP relay. The idea is to offer a form for first-contact that allows a non-PGP user to send a message end-to-end encrypted with a PGP pubkey. The user receives OOB some brief instructions (brief enough to fit on a business card) and a checksum with which to verify the bundle. Having verified the bundle, they execute the bundle, enter the message and send.

I tested the system last night with a layman friend, who successfully verified the bundle with an online SHA2-256 calculator before sending a message.

Wolf: Stop it with those short PGP key IDs!

Posted Jun 5, 2016 20:13 UTC (Sun) by rmayr (subscriber, #16880) [Link]

The OOB channels we looked at were mostly user-mediated device-to-device authentication channels, e.g. using laser light transmission, indirectly via shared movement (recorded via accelerometers), or transferred via a series of ultrasonic pulses. QRcode would certainly work and doesn't need many of the crypto tricks required for the others, because it can transport the full length of a SHA2-256 output. So with QRcode and the assumption of authenticity in the channel, transferring a hash of the public key together with an identifier of the other party should be enough.

Wolf: Stop it with those short PGP key IDs!

Posted Jun 7, 2016 23:31 UTC (Tue) by gwolf (subscriber, #14632) [Link]

As for now, we are still perfectly safe by cross-signing based on the 160-bit key fingerprints. Having the full 4K of your public key is overkill. Besides, you'd have to strip the key to get just the 4K part (as it would most probably already carry signatures and other attributes).