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:

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


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!


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?

8 thoughts on “PGP Never Gonna Give You Up”

  1. Having recently authored a post about PGP myself…

    I’m very much inclined to agree with you. This is a good use of PGP.

    In particular, PGP is valuable here if you believe your correspondents have at least as good operational security around their key management (A) as the product of their operational security around their credentials on a site that asserts identity (A’) and that site’s security (B). So long as (A) is significantly greater than (A’ * B), then PGP is significantly better.

    Back on the FastMail example (since I work here) this is actually something interestingly missing at the moment in our product, and on our roadmap for next year. We publish a header (was X-Sasl-Enc, now X-ME-Sender) which _we_ can use to correlate users back to authenticated accounts. We don’t publish the actual account of senders for privacy reasons, so two recipients can’t correlate the sender if they use different aliases.

    But what we don’t have is a way for the recipient to reliably correlate the sender if they _do_ want that. We sign outbound email with our domain regardless of the claimed address, and we don’t (yet) enforce ownership of the contents of the From header.

    … unless you use your own domain, in which case we will only DKIM sign with that domain if you are authenticated to us as a user within the account which owns the domain.

    That’s definitely on the cards for next year, so that if you receive an email DKIM signed by FastMail and you’ve heard from that sender before with another DKIM signed email, you will know that _we_ believe it’s the same person. Of course our belief is only as good as (A’) above – the operational security of that user around their FastMail credentials, but with easier 2 factor support which we added this year, that’s strong.

    Still, (B) – our security, is by definition less than 1 by some amount, however tiny. Assuming equal levels of protection for your correspondent’s PGP key and their FastMail creds, (A) is still going to be greater than (A’*B).



  2. Instead of storing your private keys on your phone, try storing them on a Yubikey Neo. Anyone brute forcing the Yubikey gets 3 & 3 attempts on the PIN (up to 128 characters) before the key is locked & the Yubikey will need a destructive reset to be unlocked. So I feel it’s pretty secure. You’ll still use OpenKeychain for public key management & to interface with the yubikey; so everything will work basically the same.

    I’ve had great success with this approach & use it with K9-mail & cross platform password masagement via pass (*nix: pass, Windows: QTpass, Android: Password Store) & git for syncing. Since SSH auth by the yubikey isn’t supported on Android yet, my phone stores a SSH priv key, with a long random pass phrase held in pass. Password Store supports app-fill.

  3. It’s a shame that you didn’t mention K-9 Mail which, in conjunction with OpenKeyChain, offers a FOSS PGP capable mail client.
    (Please note that PGP/MIME is currently only implemented in the beta)

    1. There are a whole bunch of other apps I also did not mention, I’m so sorry! :P

      Seriously though, I chose to focus on OpenKeychain. Users will figure out where to go from there. K-9 is certainly one of the options, thanks for mentioning it here.

      (Personally I prefer AquaMail which has no built-in PGP support and is a paid-for app, but is in terms of usability significantly better than K-9.)

  4. This made me realise I’ve forgotten the passphrase to my old GnuPG key… I wonder what are the odds are that I’d be able to figure it out again, recovering access to old encrypted data.

    1. Oi!

      There are reports online of people partly brute-forcing their own passphrase: They had *some* knowledge of the passphrase, and used this in their automated guessing attempts.

  5. “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.”

    Isn’t better to generate newer secret subkey for that purpose.
    GPG use only the newer subkeys for encrypting or signing.
    So when you generate a new subkey pair, you get the same as generating a new private key but you still conserve the same primary key id (and the trust that is associated with).

    More, you can delete your primary private key keeping your private subkeys for signing and encrypting. In that way, even if your private key ring is stollen on your mobile phone, you can revoke the subkeys concerned.

    The only problem is that you can’t sign keys anymore in that way since GPG trust is based only on signatures made by primary private key.

    Is it not a better alternative ?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.