Cover Image

PGP NFC

May 15, 2018 - Reading time: 2 minutes

I think NFC (near field communication) is now quite a common feature on mobile phones. It's the thing where you need to be in physical contact, or within a couple of millimetres, to read the code. Similar to RFID, but with more data storage capacity.

I've been using an elliptic curve PGP/GPG key since last year and the size of the keys is much smaller than the RSA ones I used to use in the olden days. So I was wondering whether I could get the exported public key onto an NFC tag as another way of doing face-to-face key signing events. The traditional PGP key signing protocol involves a ceremony including tea and sometimes cake and government ID documents and key fingerprints printed out on tiny slivers of paper. You're then supposed to download the public key from a keyserver, check that the paper fingerprint matches and sign it. It's all a bit cumbersome and tedious (well, apart from the cake), and it's for those sorts of reasons why PGP never gained much popularity.

The largest type of NFC tag currently available can store 888 bytes of data. An elliptic curve public key exported from GPG is 640 bytes. So you can get the public key, plus some extra text such as name and email address, onto a single tag. Even though these are high end by NFC standards if you buy them as stickers then they're really cheap.

So I made a few of these and stuck them on my laptop and the back of my phone above the internal NFC sensor so that they don't conflict. If other people did the same then just tapping phones together would be enough to do the exchange. Far simpler than the established procedure.

If proper verification of encryption keys is to go mainstream then it needs to be something like this which is extremely simple and quick to do, and doesn't necessarily involve third parties like keyservers. The other obvious way to do it is with QR codes. I also experimented with doing it that way and it's entirely feasible to store an elliptic curve public key within a QR code and have it readable with a phone camera.


Cover Image

efail and other failures

May 15, 2018 - Reading time: 2 minutes

Yesterday there was a security flap over possible PGP bugs. There's some legitimate concern behind it, but the biggest feature of this disclosure was that the way that it was communicated was really poor and alarmist. There have been a series of high profile software bugs over the last five years and the trend seems to be to always create a bigger razzle than the previous one.

As far as I can ascertain the security implications for the Freedombone system are zero, even though GPG is used quite extensively within it. Freedombone uses the Mutt and Mailpile email clients and neither of those are very affected. Mutt has S/MIME turned off and Mailpile doesn't display HTML in emails by default. There are a few issues with Mailpile which are described here. The TL;DR is that unless you are reading encrypted mail from 10+ years ago and you're being actively targeted then there isn't likely to be a problem.

In reality efail is a low impact security issue with some email clients or some people running extremely old versions of GPG. These issues had also mostly been known about for a long time.

This wasn't how the problem was publicised though. Instead the advice from EFF was to immediately turn off PGP encryption or uninstall PGP software. Even if you are running an email client which has one of the efail problems the EFF advice was not an appropriate or proportionate response. It suggested to me that the people at EFF were not thinking in terms of threat models. Out there in the wild how likely is the exploit to happen and what are the chances of that weighed against the security features provided by GPG/PGP email encryption? Most users of PGP are not fools, and it has been widely understood for a long time that including HTML within encrypted email is bad opsec which can expose you to a bigger range of threats.

"Recommendations to disable PGP plugins and stop encrypting emails are completely unwarranted and could put lives at risk. The correct response to vulnerable PGP implementations should not be to stop using PGP, but to use secure PGP implementations"

In the years after the Snowden revelations quite a lot of effort went into getting more people - especially those in "at risk" categories - to encrypt their email. To then encourage all that to be thrown away was reckless and I think there is still a debate to be had about what constitutes "responsible disclosure". What information was EFF supplied with and why did they report in the manner that they did? Was it just clickbait one-upmanship, or something else? Nothing on the internet is perfect and security software which has some bugs under some conditions is probably still better than transmitting communications in the clear where it can be trivially read by any intermediary.