Cover Image


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.

Some thoughts on cryptocurrency

May 13, 2018 - Reading time: 2 minutes

The hype around Bitcoin within the last six months got me thinking about cryptocurrency and whether it's possible to make a cryptocurrency that works. Bitcoin has a decade long history. According to the original whitepaper it was supposed to disintermediate banks and financial institutions who had ruined the economy so badly. When you look at Bitcoin today it's an absolute failure in those terms. Banks and financial institutions are making themselves into Bitcoin intermediaries and the usual suspects are benefiting from it.

A heretical thought is that maybe it's just not possible to make a cryptocurrency for the arbitration of use values. That is to use as a way of buying and selling ordinary commodities, like clothes or groceries or furniture. "Simple commodity exchange" as economists call it. Perhaps this is why there has never been a practical micropayment system for the web which doesn't depend on banks. Maybe cryptocurrencies are too easy to hoard and so nobody wants to spend them on anything. The always declining availablility results in there being no incentive to spend and a lot of incentive to collect an increasingly exclusive thing.

Another thought is that maybe money was never really about exchange and was always just a way of exercising power within a society. Perhaps the story about money being an exchange medium was always just folklore to placate the populace. If you look at it this way then so long as there are monarchs, presidents and central banks there won't be any workable decentralised money system, because in many societies political power is very unevenly distributed. Any new money system invented won't fit with the existing power structure and the social conventions which that generates and so won't get much traction.

I hope I'm wrong about the above, and that workable cryptocurrencies have just not been invented yet. The lack of progress since the creation of Bitcoin inclines me to believe otherwise though, because it's not as if smart people havn't been thinking about this problem.

Down the Firefox Rabbit Hole

May 6, 2018 - Reading time: 3 minutes

Firefox will be adding some kind of ads to the new tab screen. They call it "suggested content" or something like that, but you can be sure it will really be primarily about ads. The classic open source thing is that if someone includes an antifeature then you can just remove that part of the code, recompile and continue. I had never actually read the source code for Firefox, so this was also an interesting exercise.

While reading the code I soon ran into things related to telemetry. There's a python script in the build directory which sends telemetry data unencrypted to a static IP address. I don't want anything reporting back to the mothership, so the question then became one of whether I could remove the telemetry code, as an exercise to see what's involved in doing that.

What do I mean by telemetry, you may ask. The word is normally associated with NASA and space probes sending back images from other worlds, but in this context it means monitoring what users are doing with some software and then sending that data back to some central location for analysis.

The telemetry code which I initially found turned out to be just one small corner of a much bigger thing. The main telemetry code is complex and it's difficult to determine where it pushes out exfiltrated data onto the wire. There appears to be a substantial ecosystem around spying on Firefox users, in which arbitrary queries can be performed and bespoke requests for data can be submitted for approval. The level of monitoring by what is known as "telemetry probes" seems really detailed. It's as if the software is a sophisticated instrumentation system for monitoring users with some web browsing features also appended.

If you then start reading the associated mailing lists and bug tracker entries it gets into a new level of creepyness, in which users appear to be being talked about as if they were "inventory". A quote from here:

"It is my understanding that our advertisement clients will rely heavily on our inventory projections, to the extend of budgeting campaigns based on the number we provide. If our projections are wildly wrong, clients will under or over budget, which will corrode industry trust in Mozilla brand"

And then some stuff about experimenting on users:

"Users can only run with a single experiment at a time. We have other experiments pending, and so it really is not practical to ship this as an experiment and operate on large samples of the beta population."

On the mailing list they talk about Firefox as a "data platform", with strange surveys. It's a side of Firefox that I'd never encountered before, because I was only coming at it from a user angle. I'm not entirely sure how to feel about it, but it seems resolutely within the creepy corporate surveillance arena. Previously I had known at a high level from their financial statements that Mozilla Corporation sells user behavior data to search engines (that probably means Google primarily), but seeing how the sausage is made is another matter. It's a bit like the difference between knowling at a high level that the NSA is spying on everyone and then later reading the Snowden documents containing the gory details of how they're doing it and being a lot more disturbed.

So if you're a Firefox user what should you do about this? First of all don't panic. The derivatives of Firefox, such as the Tor browser, have all this telemetry stuff deactivated. If you are using a vanilla Firefox browser then block on your firewall and maybe also add it to /etc/hosts to make sure it doesn't resolve. If you're doing software development on the Firefox code then block the IP address where it sends build information to.

End-to-End Policy

May 5, 2018 - Reading time: 2 minutes

Another thing changed recently on the XMPP configuration within Freedombone is the end-to-end security policy. Previously if you posted anything without encryption there would be a big scary and usually also noisy warning notification telling you to do better. This is ok for private one-to-one chats, but not for public multi-user chats such as channels used for open source projects.

So I did a little tweaking and now either OpenPGP or OMEMO are required for one-to-one chat (if you try anything else it will just fail) and there is no encryption requirement for multi-user chat. So you won't get any annoying alarms when posting to multi-user chats. You can of course still do encrypted multi-user chat if you want to, it's just not a strict requirement enforced by the server.

I now find that using XMPP with Conversations on Android is actually a nice experience with very little friction. The cryptostuff all seems to "just work", and there is no possibility of accidentally sending an unencrypted private message as there was before. As of Conversations 2.1 OMEMO encryption is now the default, so you don't need to be concerned about turning it on.

Also in cryptostuff-related news I noticed recently that the Tor daemon on my server was struggling and that apps were not accessible via their onion addresses. This happens occasionally, because Tor is not a perfect system. Relays appear or disappear. Guards change. Systems are attacked and defended. It would be nice to know when these outages are occurring though, so I've added a watchdog to monitor the health of the Tor daemon and report any changes in status via email. So now just by reading your email you can know whether there are any Tor problems happening. In future I'd like to integrate this with XMPP, because that might be more useful. I don't read emails all that often.

Cover Image

For the Birbs

May 3, 2018 - Reading time: 2 minutes

The first continuous integration (CI) system I saw in use was back in the mid 2000s. Back then I don't think it was even called "continuous integration". It was just a way to test that builds worked, run unit tests and the send alerts if things had broken. For long builds that would usually be run overnight. It also wasn't anything formal, just some arbitrary and completely bespoke scripts on a server.

More recently I was discussing whether it would be a good idea to have continuous integration for the Freedombone project. Since making images involves building a minimal Debian and then installing and configuring other apps this can take quite a while. A couple of hours on a fairly powerful machine. At first I thought there wouldn't be much to be gained by doing this, but on second thoughts maybe it might be useful if I can find or requisition an old desktop machine to do it. At present testing of Freedombone builds is very manual and quite laborious.

I know that Lars Wirzenius has been developing a CI system called ick. As a side note you might also want to check out his Getting Things Done for Hackers. Ick looks ok and I could probably use it, but the code looks rather complicated and I'm not a huge fan of yarns as a software validation methodology, although I can understand why developers might be attracted down the path of making things as similar to natural language as possible. I was thinking that for my purposes CI doesn't need to be this complicated, since there's only a small set of things which it needs to do.

So I spent roughly a day writing a CI system and the result is BirbCI. This is really a single command implemented as a bash script which can set up systemd daemons to run builds and then report the results as a html page. It's about the simplest possible CI system at roughly 330 lines of script including comments. I also blinged it up a bit with a background image and coloured icons and text representing build status, so that it doesn't look too sparse and utilitarian.

This should be good enough to start thinking about making some sort of Freedombone build server. It's not a super-high priority, but maybe something to work on as a background task in the next few weeks or months.


The blog of Bob Mottram, a Free Software hacker and maintainer of the Freedombone project.

Web site