PGP Never Gonna Give You Up

(Summary: Cryptographically signing messages with my long-term PGP keys is too important to give up. Doing this on my Android telephone is easier than I thought. You should strengthen your secret key encryption if you’re also going to do this.)

Recently, Filippo Valsorda, cryptography expert and TLS guy at Cloudflare, wrote that he was giving up on PGP, or at least on long term PGP keys.

I agree with many of his points, especially the complexity of managing those keys, lack of forward secrecy (if someone were to steal my keys, they could decrypt all past conversations, unlike for example Signal) and accessibility (how do you verify a message with a baby on your left arm and your telephone in your right?). More generally, it makes a great deal of sense to make your security a moving target, as one of the Ars Technica commenters astutely summarised Filippo’s ideas.

Cryptographic signatures FTW

However, in spite of these factors, I am not yet ready to give up my PGP long-term keys.

Why is that?

Well, one of the most important uses of my long-term PGP keys is to cryptographically sign messages that can be verified by people in my network as having come from my hands.

For example, when I change my phone or re-flash its firmware (this has happened 3 or 4 times over the past two months because Android), I send PGP-signed messages to my main Signal correspondents with our new safety numbers.

With all of these correspondents I have in the past either done some sort of in-person formal PGP signing procedure, or I make use of the web of trust, or I rely on keybase. My business cards even have my key fingerprint on them (yes, I’m one of those nerds).

At their ends, the recipients of my messages are able to determine with an extremely high degree of confidence that I wrote the exact message they opened.

Accessible PGP on your smartphone with OpenKeychain

In terms of accessibility, the post did make me curious enough to experiment with a mobile PGP solution, as I also did have to agree that I’ve in the past often had to wait until I was behind one of my own laptops or workstations to PGP-verify a message.

As my one friend explained on Signal:

It’s tricky to verify a message with a baby in your left hand and a telephone in your right!

OpenKeychain to the rescue!

Strengthen your secret key encryption

Seeing that I was planning on carrying my long-term private keys around on my telephone (BlackBerry PRIV, FDE encryption active FWIW), I had to double-check the security of the secret key encryption.

It turns out that PGP encrypts each of your secret keys with a hash of the passphrase you supply. My passphrase is significantly longer than the average, and consists of random characters (uppercase, lowercase, numbers, symbols). Passphrase length and complexity is by far the most important factor determining the safety of your encrypted secret key.

However, I had the default SHA-1 hash (ouch) with only 64k iterations. Iterating the hash is called key stretching: the passphrase is hashed, that result is hashed, and so on, for very many times, so that the testing of each passphrase takes more time, complicating brute-force cracking approaches.

Inspired by the writings of Chris Wellons who keeps his encrypted secret keys on a public website (!!!), I reconfigured my private key encryption to use 1 million iterations of the SHA-512 hash, and to use AES-256 for the encryption itself:

gpg --s2k-cipher-algo AES256 --s2k-digest-algo SHA512 --s2k-mode 3 --s2k-count 1000000 --edit-key 384435C7E77A4564

After typing that command, enter passwd at the prompt, then follow the prompts. You will have to enter your passphrase, and then enter your new passphrase twice.

You can then check that this operation is successful by using the command gpg --list-packets secring.gpg. My output looks as follows. Most important is that algo is 9 (AES-256), hash is 10 (SHA-512) and protect count in my case is just over 1 million.

:secret key packet:
     version 4, algo 1, created 1376407300, expires 0
     skey[0]: [4096 bits]
     skey[1]: [17 bits]
     iter+salt S2K, algo: 9, SHA1 protection, hash: 10, salt: blabla
     protect count: 1015808 (159)
     protect IV:
     encrypted stuff follows
     keyid: 384435C7E77A4564

SHA-512 is the slowest hash which PGP offers (see these oclHashcat benchmarks for example), which means that each iteration of a brute-force password cracking attempt will take a bit longer / eat more GPU watts, which is exactly what we want. You can increase the protect count for as long as the delay on your smartphone is still tolerable.

However, remember that a stronger and longer passphrase is much better! (so we do both)

Other than that, remember that Android security is far from good, so do as much as you can to keep your phone safe (keep up with OS updates, stay away from unofficial app markets, and so on).

Use your keys with OpenKeychain

I was pleasantly surprised to learn that I could directly import both my secring.pgp and pubring.gpg files from my ~/.gnupg directory. Right after selecting secring.pgp for import, the UI looked like this:

You can see the old 1024 bit key I made in 2000 to use for my Debian activities, and the 4096 bit key I currently use.

After importing your secret and public keyring, you are able to encrypt, decrypt, sign and verify any files or clipboard contents on your Android phone:

So if I receive something like this via Signal:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Never gonna give you up, never gonna let you down
Never gonna run around and desert you
Never gonna make you cry, never gonna say goodbye
Never gonna tell a lie and hurt you
-----BEGIN PGP SIGNATURE-----

iQFEBAEBCgAuJxxTdGVmYW4gdmFuIGRlciBXYWx0IDxzdGVmYW5Ac3VuLmFjLnph
PgUCWE2aUQAKCRDl/rykoDTdZZgvB/9Yi76C9o7xIgQ/d85WbnKDjNosp5uXzgHm
A2y+cxZDLVNLTMrlCTXOMRulaJMvb3Ocsvi+/gQVUF49fT74EXlZpZvvdTzhQfa2
VvQPjZmf/9PNzB3pgUtEDBwyLC21C6dqU+y7mPk91Aw1m8cKBQUSHmQxa7F/dCFc
DCuWOcXjNt5vLQ2Q8mQBMpHaG9J5+4/0k/GEHAVcm55fzb7o2hJyEVb3EoYy8Pls
khIwJpZVdwyY4FPoLXW3iJYanC5qoOoS81YLCyLEyin0jH56ve05uHbF0XcaNY4h
NupkN2D+Dt4X2m2FXieM27eG/Ty9hVx7n7B3pT4P9KqeFDX8hQ/q
=c7j9
-----END PGP SIGNATURE-----

I long-press, copy the message and then select “read from clipboard” from OpenKeychain’s Encrypt/Decrypt screen, which, if everything checks out, shows me the following message:

I can now rest assured that this specific buddy of mine is never gonna give me up and is never gonna let me down.

Cryptographically signing a message is equally easy, except that you’ll have to enter that long passphrase of yours. OpenKeychain will then make the signed and optionally encrypted text text available for sharing to any app, or for copying and pasting:

Easy peasy, and tested under all sorts of usually-PGP-unfriendly conditions!

Conclusion

Maintaining PGP long-term keys certainly has its issues, but the possibility of cryptographically signing any message so that recipients can establish with high confidence that it originated from you is too important to give up.

With an app like OpenKeychain and sufficiently strong passphrase hashing and secret key encryption, you are able to use your keys with ease from your telephone.

Granted, you are trading in some security for this convenience. However, given the choice between discarding my PGP keys completely, vs. taking these steps, I’ll hold on to my keys for a little while longer.

In order to mitigate the potential damage of one of my long-term keys being compromised, I have resolved to generate and start using a new private key as soon as I run through my current batch of business cards, and to continue rotating like this in the future.

Let me know in the comments what you think. Do you know of a better alternative for remotely verifying the identity and messages of your correspondents?

Android security in 2016 is a mess.

Summary

Your phone probably contains banking, payment and personal information that can be remotely stolen via numerous known and unknown bugs in the Android software. This is attractive to criminals.

Vendors (LG, Samsung, Xiaomi, etc.), after selling you their phone, have no incentive to keep your phone’s software up to date with Google’s fixes. Your Android phone is probably out of date and therefore a gaping security hole through which attackers can steal your stuff from the safety of their own laptops.

Read on for more.

Between 1.3 and 1.4 billion Google Android phones in March of 2016. Click image for source.
Between 1.3 and 1.4 billion Google Android phones in March of 2016. Click image for source.

An illustration: MediaTek / BLU phones are uploading your data.

You might recently have read about the incident with the popular BLU phones sold by Amazon in the US. It turned out that these phones were regularly sending bunches of personal information to servers in China: text messages, call logs, contact lists and so forth. After more investigation, it came to light that this was happening via a low-level piece of software called ADUPS.

When Google had previously updated its systems to check for ADUPS, MediaTek (they make the chipset in millions of low-end phones) simply modified their system software to evade Google’s checks. Nice one MediaTek!

This is a painful example of the fact that the software on your phone, although based on Google’s software, is customised by the phone vendor. The further frustrating effect of this is that when Google releases security patches to Android (which they do regularly), there is very little incentive for the phone vendor to spend money on updating phones they have already sold.

What about A-list phone makers?

I bought my LG G3 in 2014 here in South Africa. It was LG’s flagship in that year, and sold extremely well. LG is a well-known smartphone OEM.

However, only because I took steps to flash the official KDZ image (V30a-ZAF-XX), which consumers would normally not do, am I now running Android 6. However, my security patch level is 2016-03, meaning there are 6 months of security updates I don’t have. (You can check your Android security patch level by going to Settings | General | About Phone | Software info.)

Before you think six months lag is not too bad, here’s a nice example vulnerability from the November 1 Android security bulletin:

The most severe of these issues is a Critical security vulnerability that could enable remote code execution on an affected device through multiple methods such as email, web browsing, and MMS when processing media files.

In short, your phone could be hacked wide open from afar through a single innocent-looking email, MMS or web-page.

My friend’s South African LG G3 is still stuck on Android 5.0 (V20n-ZAF-XX). Most probably this is being blocked due to his carrier (MTN). In any case, 5.0 does not even show the security patch level, so we have no idea how many months of security fixes this phone is missing.

(LG seems to be tracking Google’s security updates quite well, but somehow these updates are not reaching phones.)

A scary little aside

I just tried Check Point Labs’ QuadRooter Scanner app on my “updated” LG G3, and this is what I saw:

LG G3 with Marshmallow and Android security patch level 2016-03 is vulnerable to QuadRooter.
LG G3 with Marshmallow and Android security patch level 2016-03 is vulnerable to QuadRooter.

So my manually updated LG G3 is still very much vulnerable to QuadRooter. In theory, my phone could be (or already has been) rooted and pillaged by any old innocent-looking app, although I keep mostly to the official Play Market, so the risk is slightly mitigated.

At this stage, even as a relatively knowledgeable user, there’s not much I can do to patch my phone against this vulnerability.

Google’s leniency cuts both ways: More than a billion Android users, but most of them vulnerable.

It’s fantastic that Google’s openness and leniency with Android has helped to make smartphone technology accessible to more than a billion users (probably closer to 2 billion taking into account Chinese Android phones not connected to Google services, see Ben Evans’s post). However, this same leniency allows manufacturers to be irresponsible about keeping their customers safe.

The fundamental problem here is that there are a great deal of Android phone vendors who make phones from absolute entry-level to top-of-the-line flagships, who have very little incentive to spend money on post-sale security updates.

Once you’ve paid for the phone, you’re not important enough anymore to have a secure(ish) telephone.

What can we do?

Buy an iPhone. No really.

I’ve been using Android since the HTC Desire Z. I love Android, because I love Linux which I have been using since 1993.

However, if money is no object, my only sound advice can be to buy an iPhone. Apple is still shipping security updates, albeit on iOS 9, for the iPhone 4s which was released in 2011 (5 years ago). The iPhone 5 is still being kept up to date with iOS 10.

Furthermore, in terms of phone encryption, iOS 4, released 6 years ago, was already more advanced than than Android 7 Nougat, released in August of this year. In short, already then Apple made better choices in how exactly different files are encrypted, whilst Android implemented full disk encryption, which for the smartphone usecase is not the right choice. In Nougat, Android has finally also changed to file-based, but they’re missing important parts of the puzzle. The phone encryption blog post I link to is insightful, please take a look.

Stick with Android Pixel or Nexus.

If you prefer sticking with Android, the best choice is getting an official Google device, which means either a Nexus or a new Pixel. Google’s policy for Pixel and Nexus security states that they will ship security updates either for three years after device introduction, or for 1.5 years after the device was last officially sold from the Google Store, whichever is longer.

Unfortunately, iPhones are really expensive, and Google’s new Pixel devices are also aiming for the higher-end market. The previous generation Nexus phones offer a more mid-range but very temporary reprieve.

In other words, most normal consumers on a budget, i.e. the largest part of the Android user base, actually of the smartphone-using world, are stuck with insecure, vulnerable phones. This is not cool.

Consider installing a custom ROM.

Installing a custom ROM such as Cyanogenmod brings with it another set of issues with regard to the phone being rooted, and with regard to driver-level support of proprietary hardware. In any case, this is not something your average consumer will have access to, but Android gurus can certainly apply.

Efforts like CopperheadOS (hardened Android) are certainly promising, but it will be quite a while before they are accessible to the largest group of Android users.

Update: David Metcalfe pointed out in the comments that you can buy a secure Android phone from Copperhead.  If you are in the US or Canada, and you have some budget, you could buy the LG Nexus 5x or the Huawei Nexus 6P with CopperheadOS pre-installed. It’s great that this is available, but due to price and geography not really accessible to most Android users.

Keep manufacturers honest.

Ideally, Google starts taking a much harder line with manufacturers who put Android on their phones. They could for example maintain and publish a list of phone models that are kept up to date with the latest security fixes, and a list of those that aren’t.

I was happy to see that at least Huawei has a pretty good record in terms of keeping their Android phones up to date (although the results were probably skewed as they counted the Huawei-produced Nexus 6P phones, and these formed the majority of the test set, doh). This factor will play a role in the next smartphone that I buy.

Do you know of any (other) manufacturers of more affordable Android phones who are committed to keeping their users safe? Please let me know in the comments!

Addendum: Android phones with acceptable security update records

Blackberry PRIV, DTEK50 and DTEK60

lobste.rs user jabberwock tipped me off to the fact that Blackberry’s Android phones get monthly security updates. Read more at CrackBerry and here in the BlackBerry Android security bulletin for November: It looks like these phones receive monthly updates (when not blocked by the carrier, sigh) and have already received the November 2016 update.

Here is the original blog post where BlackBerry explained their security patching policies for the PRIV.

When we can, let’s use Signal instead of WhatsApp.

(Post updated on August 25, 2016. See section at the end.)

Screenshot of Signal.
Signal, the open source messaging and voice calling app that does end-to-end encryption.

The whole world is using WhatsApp to message each other. I often do too, because I want to inter-operate with the rest of the world.

However, WhatsApp belongs to Facebook.

Although Facebook has promised otherwise, the temptation to link all of your WhatsApp messages with Facebook logins (a straight-forward process, as they have the mobile phone numbers of a great number of their users) must be quite tempting to the people at Facebook. Imagine how well they would then be able to target their advertising, based on their access to both your Facebook profile and your private WhatsApp messages!

Fortunately, we now have an open source app, called Signal (available on Android, IOS and the desktop), which performs end-to-end encryption on all messages and voice calls that go through it. This means that absolutely no-one is able to read your messages or eavesdrop on your voice calls, except the intended recipients.

My request is that you get your contacts to install and start using Signal instead of WhatsApp wherever possible. At the very least some of our messages will not be accessible to various large corporations and any other prying eyes. If the security argument is not enough for you, there is one more extremely important topic: Signal handles animated gifs better than WhatsApp, at least on Android. (Telegram supports them on both Android on IOS, but it is by default less secure than Signal). See here the results of my experiments:

Updates

On August 25, 2016, The Verge reported that WhatsApp will now officially begin sharing data with Facebook. They will indeed link up telephone numbers and social networks, meaning that both parties will get a tremendous boost in what they know about you. I don’t want to say I told you so, but I told you so. ;)

Dear USA, my data has left your building.

NSA, GCHQ, Prism, FISA, Project Bullrun, Sigint.

After Edward Snowden, former CIA and NSA employee, started revealing how massively, intensely and easily we are all being spied upon by the intelligence agencies of various governments, the terms above have suddenly been spending a great deal more time in the media.

Image by BLOGGING via TYPEWRITER
Image by BLOGGING via TYPEWRITER

It turns out that government agencies are allowed to extract, at a whim, your and my data from service providers, such as Google, Microsoft and Yahoo. There is no real legal process (unless you can call a secret judge in a secret court giving a secret order a real legal process), especially if you’re not a US citizen, and the providers that have been forced to give up your data in this way are not allowed to notify you about your digital self being violated. So even if they say that you shouldn’t worry, you can never be entirely sure.

Furthermore, it has also been revealed that the NSA has for years being acquiring encryption keys via legal (secretly forcing companies to give them the keys) and extra-legal (simply hacking into company servers) means. Even worse, they have for years been deliberately introducing security weaknesses into software products and encryption software in order to be able to crack open your data even more easily.

You can read more about this state of affairs in The Guardian’s NSA files. The Guardian has been doing a sterling job of analysing and bringing to light the depths to which our governments have sunk. There’s a whole lot of information, and most of it is quite upsetting.

For me the final straw was when secure email service lavabit voluntarily shut itself down, when faced with the prospect of being forced to leak user information to the US government without being allowed to tell anyone. The message on the site is quite chilling, and concludes with the following:

This experience has taught me one very important lesson: without congressional action or a strong judicial precedent, I would _strongly_ recommend against anyone trusting their private data to a company with physical ties to the United States.

At this point, I was a super happy and pretty heavy user of a number of US-based services, including GMail (all my email, about 40000 conversations consisting of 60000 mails, that’s excluding my work email which I also hosted on GMail), Google+ Photos (all my photos, about 21000 of ’em), Google Drive, Dropbox (50G of data spread out over 120000 files). In all cases, I still consider these to be best of class services. In putting my money where my mouth is, I was paying both Google and Dropbox for extra storage.

I also had no problem with Google filtering through my email to show me targeted advertising. This is the deal I had with them. I also had no problem with the possibility of someone getting my data after due legal process. However, the idea that some NSA or other government agency flunky could quite easily stick their grubby paws into my data, and that I would never know about this, was too much.

There’s probably nothing much of interest in my data. However, it has become a matter of principle; Privacy is a basic human right. Here’s an old essay by Bruce Schneier if you need to read more about why privacy is so important.

In short: It was time to extricate all of my lovely data from probably well-meaning US companies, thanks to the ridiculously powerful and secretive NSA, and thanks to all of its shadowy counterparts around the world.

Here’s how I did it:

  • Considered building another low-cost Linux server, or even a Raspberry Pi. Decided against this due to time required for configuration and acquired a Synology DS213j NAS, which is at this moment standing on the desk about 1 metre to my left. My recommendation: Just get this, you won’t be sorry.
  • Downloaded 60000 emails to Synology using Thunderbird mail client. Deleted everything from GMail. Google engineers assure me that after a few months, data will really be gone.
  • My webhoster (WebFaction) receives mail for all my domains. My Synology retrieves mail every 5 minutes via POP (you can set this up via Roundcube on the Synology) and deletes it from WebFaction.
  • Outgoing mail is relayed by the Synology via the WebFaction SMTP server. I don’t have to worry too much about blacklisting and whatnot, my hoster does this.
  • I’m back to interacting with my mail using Thunderbird and IMAP SSL. The loss of GMail conversation view was initially really REALLY painful. People have forgotten the ancient art of quoting. However, I’ve configured Thunderbird to archive all mail to year-stamped archive folders, and to put my sent mail there. Poor-man’s Conversation View! (the conversations plugin is wonky. it’s shocking how much the availability of GMail, which works really well, has stunted the development of alternative email clients) Importantly, I am now able to use OpenPGP again for the strong encryption and cryptographic signing of my emails.
  • On my Android telephone (whoops…) I am using the Kaiten IMAP client.
  • All the data I had in Dropbox is now being synced between the Synology, two laptops and a workstation using BitTorrent Sync. This peer-to-peer syncing system is still a little rough around the edges, but falls squarely in the category of “Best Things Since Sliced Bread”, and it’s FAST. CloudStation, Synology’s dropbox-inspired solution, was just far too slow on my Synology model.
  • My photos (21000 of them) have been downloaded from Google+ Photos (thank you Google Takeout) and are now being served from the Synology using PhotoStation.
  • My music (5400+ tracks) is downloading from Google Music as we speak, and will be served from the Synology using AudioStation.
  • I make incremental backups of everything to an encrypted external USB drive, using dirvish. I will probably add an extra external drive to the mix and try to keep that off site.

It’s been an interesting process moving my stuff out, and getting used to these alternative systems is sometimes slightly uncomfortable, but I am quite happy with the end result. I hope that more people will take this step, and I really hope that more and easier-to-use alternatives for secure email (such as mailpile) and for ubiquitous private data will become available.

Addendum 2013-09-16

My submission of this post spent some time on the Hacker News front page, and from there was picked up by reddit as well. This brought many comments, a number of which were positive and thoughtful, and a number of which that were far less so. It’s amazing how anonymity and comment sections can bring out the worst in people. (if you have to know, the Hacker News community is generally MILES more polite than reddit)

In any case, I wanted to clarify an issue or two: After moving my data away from GMail and Dropbox, I am not under any impression that my data is now secure. I can still be hacked. My hardware and software could be full of backdoors. My email will still be read as it jumps from server to server, probably ending up in someone else’s GMail. :) However, if more people were to move their data out to their own premises, it becomes more complicated and costly for government agencies to monitor us all. At the moment, the NSA cuts deals with a few large email and other cloud service providers, and with that they’re able to monitor large swathes of users. However, if more of those users were to move away, many more deals have to be cut and servers hacked, costing more time and more money. Add to that increased used of OpenPGP (which I do use, and mention in my post), and it becomes even more difficult. I know that I’m just a drop in a bucket, but hey, at least I am a drop in a bucket!

My goal with posting this was to show that it’s relatively easy to move much of your data away. I have the feeling that many of the most impolite anonymous commenters still store their data with cloud providers, and would really prefer to believe that there are no worthwhile alternatives, hence all the ad hominem attacks.

Fortunately, each polite and humane comment makes up for a whole pile of bad ones. :)

What I did this, err, summer

Taking a hint from Joe, aka Swimgeek, here’s a summary of my life since the previous time we spoke:

  • The VCBM 2008 workshop, my first attempt at playing the organising conference chair, went swimmingly.  Two days of solid presentations, a lovely dinner at Van der Dussen (no Ronald McDonald in sight!) and meeting up with many old friends.  I stopped stressing during the conference dinner.
  • I joined the ranks of the intelligentsia (As opposed to the millions of plebs with iPhones – oh stop whining and look at the stats.  Can’t find the stats?  Go figure out how to copy and paste, then get back to me. :) ) and acquired a Nokia E71.  Best. Gadget. EVAR.
  • Had a fan-tas-tic holiday in South Africa.  Had profound conversations and the most raucous get-togethers with best friends and family.  Realised again how extremely lucky I am with people I’m this close with, on two different continents.  Linked up with my dad for the first time in too many years, which was cool.
  • Migrated my extremely complex todo system (I’m a foaming-at-the-mouth GTD follower) from todoist to a local installation of the open-source RoR-based Tracks software.  Todoist is really cool, but it’s very much deadline-oriented, whilst in the GTD world deadlines are just so passé.  DAMN I’m with it.
  • My laptop was sort of stolen and then returned 5 minutes later.  Besides the acute trauma that this caused, it got me wondering about the security of the Windows XP Encrypted File System thingy that I use to encrypt some of the more sensitive, err, documents on my laptop.  On Windows 2000, the fact that on a local install the administrator was the default data recovery agent (DRA), made it possible to decrypt a user’s files without having to crack that user’s password.  On a local install of XP, this is fortunately NOT the case.  I repeat, on a local install of XP there is no default recovery policy.  In other words, a laptop thief needs to crack your password to decrypt your EFS encryption.  You can double check this by downloading efsinfo and running it on your files with “efsinfo /u /r your_files”.  It should confirm that there’s no recovery agent.  You should also check the strength of your Windows passwords with ophcrack.  Your EFS is only as strong as the user password protecting it.  After my little episode, I’ve deleted most of those sensitive, err, documents from my laptop (they’re duplicated on a server at home) and encrypted even larger parts of my laptop hard drive, just in case.

Now I’m supposed to conclude this blow-by-blow with something profound.  I know, I’ll end with a quote attributed to Plato that I first saw in the PhD thesis of a friendly colleague.  At the time it made quite an impression on me:

Be kind, for everyone you meet is fighting a hard battle.

Heck, it still does.