I agree. Almost nobody who uses GPG does any of this.
I think people should use GPG without any of the extra options, bells, and whistles. If they really need advanced usage stuff, they should use something better than PGP.
Correct me if I'm wrong, but it seems like a lot of the issues are in implementing PGP in email, not in the cryptography itself. If you made a messaging app that automatically used best practices PGP without any of the email holes/workflow issues, would there still be something significantly better for data at rest?
I think for gpg and encrypted communications to take off, it has to come in the form of an easy to use app combined with a service offering, similar to how TextSecure/Signal works. Though it should use GPG and have a variant for Android, iOS, and native desktop clients.
The cloud service offering should be email and instant messaging, email, and some levels of sync (but not the private key).
It should be/do:
- Open source
- Generate a private key as part of the setup
- Upload your public key to the public key servers
- Access camera to read a key (qr code) from another device
- Display QR code of your private key (so you can sync it
to another device)
- Display a QR code of your public key (so someone you meet in
public can copy it and you can then trust that key)
- Show confidence levels based on how trusted a key is. Help bubbles can explain the confidence level.
- Import your contacts
- Periodically query public key server to see if your contacts have uploaded a public key.
Advanced options like importing your own key, adding "Trusted keys", and using your own email provider should also be a thing. I suppose keys could be exchanged using NFC as well, but I think that's still beyond most people.
For the most part, this should be presented as a secure communication app/service. If you want to start communicating securely with someone, you ask them to install the app. You should be able to do it while grabbing lunch together(which results in trusted keys exchanged between the both of you). Or you can invite them to use the app, which results in them getting an encrypted email address and IM system.
Finally, encrypted emails and messages could be synchronized between devices, maintaining state.
The goal of the app and service is that Johnny will see this app as their secure communication. They will know that until the other person sets up their copy of the app, that they can't send a secure message to them. And since it relies on public gpg servers, if they come across an advanced person out there that setup GPG on their own, it will be able to email that person just as easily (and that advanced person can email the app user).
- Open source
- Generate a private key as part of the setup
- Upload your public key to the public key servers
- Access camera to read a key (qr code) from another device
- Display QR code of your private key (so you can sync it
to another device)
- Display a QR code of your public key (so someone you meet in
public can copy it and you can then trust that key)
^ Keybase [1] has a mobile app in the works that will theoretically be able to do all of this. I'll be curious to see how it comes along.
I am merely a user, not a contributor yet. But I would say a solid base, and not a full implementation of your wanted features list, is in OpenKeychain.
Projects like this are why I continue to use Fdroid, Cyanogen AOSP, and believe the open source movement on mobile is worth the hassle. Oh yea, that and Password Store.
For most instances of "Johnny" I've seen, I disagree. I think the barrier to wide adoption of strong crypto is UX, specifically discoverability.
Learning GPG is really really hard. Testing an assumption takes lots of thinking and many complex commands, undoing something is hard or impossible and it's never obvious how to do it, and doing something wrong can mean disaster. It's not so much "pgp is hard to use" but "pgp is hard to learn".
This article is a great example. I think I've got a pretty good understanding of how public-key crypto works, but there's no way I could have put together the steps myself, I'm just blindly following the words of the Great Ones, Keepers of the Source.
Indeed. Even for a technical person this can be daunting with so many options that if you don't know all that much about encryption you can easily make mistakes.
There really should be an easy-setup mode which defaults to the commonly recommended options. Give the user fewer options and they will make fewer mistakes. I am surprised there isn't such an option actually. Most things in the FOSS world have be streamlined/simplified over the past decade (for example look how difficult it used to be when partitioning a hard drive during a Linux install, now it is all done for you if you just want the defaults).
You may want to reconsider sending email that's merely encrypted as it will single you out as an encryption user and perhaps increase your likelihood of being found interesting (should you care about such things).
In addition to encryption you may want to use steganography[1] and do so in a way that will hopefully withstand traffic analysis.[2]
Some other things to consider:
A - Remember that no matter what faith in math you may have, and no matter how careful you are, your messages may someday be decrypted. So consider carefully what you write, especially if you place your encrypted messages/data somewhere public or if they flow through a public network such as the internet.
B - The authentication and undeniability features of public key crypto and the web of trust, which can be so useful, can also be a two-edged sword, should the plaintext or sometimes even just the ciphertext[3] fall in to the wrong hands.
C - Don't forget your passphrases or lose your keys. Or, if you do forget or lose them, destroy anything encrypted with them or the keys they protect, as you may be[4][5] kept in jail until you cough them up -- which you can't if you don't have them or don't remember them.
You might think you're not important enough for any of this to matter. Or you might think you have nothing to hide (not likely you think that, if you're bothering to use gpg). Or you might think it can't happen to you. But it's a bad world out there. No longer are we in the world where gpg use was considered merely a geeky hobby, used only by a handful of innocent nerds. The world is a much more paranoid place these days, and you should really think carefully not just about the security of your keys, but all of the above.
My understanding is this is contempt of court in the US, which comes with 6 months in jail at a time, at which point the prosecutors have to proactively request the renewal of your imprisonment, and usually don't.
The site is down for me, so I can't comment on anything but the title: The definite article immediately suggested a unique perfect keypair to me... which would be a funny thing.
I think it's time we finally move to generating and storing secret keys on secure elements (Yubikey, NitroKey). This way we only need to worry about the physical security of the key and nothing else.
No air-gapped machine and a random flash memory stick (for storing the backup of the private key) can be considered as secure as the secure element.
And then you drop your key and lose it. Or it gets ran over by a car or something. Now what?
I love my Yubikey, but I generated the keys on it on an air-gapped machine and wrote them to two DVDs and the Yubikey.
Unless you can get everyone to send you messages to encrypt them to both your main key and your secondary backup key you will regret not having backed up your primary key.
> And then you drop your key and lose it. Or it gets ran over by a car or something. Now what?
You can't have both, I think. With a physical key your only concern is the physical security of the key. One should print out the revocation certificate, though.
I don't think many people lose their home keys or get them run over by a car. It's just a matter of making that a priority.
> I don't think many people lose their home keys or get them run over by a car.
All it needs is some idiot emptying his drink over your pants to fry an USB device. Or a drunk driver crashing into your bike and breaking the device.
Print out your passphrase-protected keyset, put it together with an encrypted copy of your most common passwords (I know no one uses a dedicated password for every site!) and your KeePass/Keychain/... database in a bank safe and one in your home's safe.
Put the password to said DBs in your will (or deposit it at a notary's office), so that in case you die your relatives will be able to shut down your online presence, but not if either the bank, your safe or the notary get busted.
I really like this walkthrough. GPG/PGP is pretty complex and getting all the pieces correct is very difficult. In fact, one major reason that I don't use encryption more is that I'm scared that I'll forget a passphrase, or not transfer my keys to a new computer, or lose my "master" key.
However, I wonder if something like Keybase.io might be better. Using Keybase I can do everything outlined in this walkthrough but in a much more user friendly way. I can even instruct other users on how to send me encrypted files without too much trouble. Does Keybase replace the need for shuffling keys around and worrying about losing my keys?
Keybase does offer to store your passphrase-protected private key with them (but never requires it!), so it does help to alleviate those problems. On the other hand, you could do the same using any kind of file syncing tool. And you still have to remember the paraphrase.
More importantly than that, though, since Keybase offers a new way of authenticating any key you upload (even if it's less secure than meeting personally and signing each other's keys), losing it is much less problematic, as you can just generate, upload and authenticate a new one.
Why is the author so concerned about the laptop getting stolen? Even if you know nothing about GPG, your laptop should be encrypted. Even if you somehow can't use full-disk encryption, your private key should be protected with an equally strong passphrase. The thief gets nothing but a useless chunk of base64-encoded blob.
Now of course this doesn't mean that subkeys are unnecessary, but the author should probably find a more realistic threat model that readers who are already privacy-conscious can more easily sympathize with.
Some time ago I too resolved to do this properly and with my limited bash-fu wrote a script to automate the process of installing GPG to a master USB key you can physically secure which can be used to drop a subkey on a PC. Most of the stuff you see in GPG tutorials can be done with a short gpg --batch.
Here's the (67 Lines of Code) script: http://pastie.org/10631164 It's not really prepared for public release so forgive some ungainly code.
I wonder how much of the commands do this, do that, can be put in a batch file? Seems much easier to comment and distribute that than to follow a blog post over once every few months to rotate your key.
Would anyone know if and how much can be done in such a way? Is the bath-mode only capable of instructing the generation of a single key? Must we resort to other programmatic invocations of gpg?
My GPG keys are protected by a passphrase and that has, so far, deemed enough subjective security in order to allow me to rather liberally store copies of the keys as backups on computers and servers I use. It may depend on your personal security requirements whether that is not enough.
That would only happen if you do not know your key has been leaked. If you know the "laptop key", as this article calls it, has been leaked you revoke it immediately and do not use it anymore. It being revoked should mean that other people (whose clients download the revocation list) will not be signing new communications with your compromised key anymore.
so you cron the process over periods of time and update all files' encryption?
at some point you need to acknowledge that there is one ultimate limitation to encryption: if you want to ever see the contents of an encrypted file then someone else will also be able to
the only way to completely 'secure' information is to destroy it, and even then you have to do so meticulously
I'm one of the owners of a domain name that's people use as dummy address when they sign up for stuff. I can't stand getting mail like that.
There is a reserved name for examples, it's EXAMPLE.COM.