I suspect that people would gladly accept the ability to send and receive encrypted, signed emails, but the hassle factor of getting set up is simply too high.
Definitely true. Even if you have a properly setup key - which less than 50k people possibly do - there's even a high maintenance cost of adding and validating new contacts.
It's an interesting method of trying to circumvent the key distribution and validation process. I'll be talking more about it in the next article, but it still requires you to have a well generated key. It's also somewhat of a different theat model than the traditional PGP web of trust.
This site promptly had me returning back to GPG again when it first came out and I got access to it. After a couple months the initial novelty of it all wore off (yet again). It's a decent idea, but when even the tech people in your circles can't be bothered with your encrypted emails it's a sign that we need to stop fooling ourselves and move on to whatever the next idea is.
This is a good idea, we have Field day, SET exercises, and weekly nets. There are always contests where hams rack up points by making contacts. We have contests that are specific days (like field day), and standing awards liked "Worked All States" (you made a contact to someone in each of the 50 states).
In the computer tech world, we do rank ourselves. We post w3c validation badges on our page, we run our sites through ssllabs.com for a security report card. We work towards being an IPv6 Sage from he.net. So why not a GPG contest? Keybase might be a good site to organize such things.
Generate a key and upload it to a keyserver is a basic level. You key can be graded based on bits (1024 vs 2048 vs 4096) and algorithm chosen. Send an encrypted email awards more points. Send a signed message for more points. Receive an encrypted message (and respond with the unencrypted text) is more points. Receive 3 emails and reply to the one that is properly signed for more points.
At some point in your journey you can start socializing. Advertise on your blog/github/keybase/social media that you are participating in a gpg contact contest. People can send you signed messages, you can send to them. You both sign and forward the message to keybase, who uses the signature to validate both of you exchanged messages with gpg. Keybase could even provide uuid/tokens to hand out (encrypted) and further validate. The more gpg contacts you accumulate, the higher your score. The "worked all states" from ham radio could be an achievement in gpg contesting as well.
In addition to my other comment, it's always ironic seeing ham radio mentioned in an encryption thread. Are communications must not be encrypted or sent in a way with the goal of obscuring the meaning.
I've been looking at truly peer to peer communication systems to use on an amateur radio mesh network with no internet access. The best solutions have encryption baked in. I would have to get a major project going to rip the encryption aspect out in order to use them on amateur frequencies/amateur power levels.
Does anyone have a good source on what kind of keys I should make? Or what ciphers I should enable on my key (is that the right terminology?)
Should I add a small thumbnail photo of myself in my key? Or is that generally frowned upon?
Finally, are there good sources on how I would create a 4096 bit master key, and then add a 2048 bit subkeys for signing and encryption that I can add to my smart card which only allows for keys up to 2048? Would generating 2048 subkeys allow me to still decrypt gpg encrypted emails sent to me encrypted with my 4096 bit master key?
Still trying to figure this all out after picking up some YubiKeys
The best document I've found for key generation (the one I turn to myself, when my memory needs refreshing) is the one on Riseup: https://help.riseup.net/en/security/message-security/openpgp... . If you follow that guide, you will get a keypair that avoids the common pitfalls.
The photo question is an interesting one - some people frown on it, some people like it. Personally, I lean towards not adding them, just because the number of times I've actually checked it is so low (maybe once, ever.) That being said, I don't think people feel so strongly that they'd refuse to use or sign your key over it; they might just not sign that particular uid. (The photo is stored the same way an alternate email is, basically.)
Properly setting up an offline subkey involves some rather archaic incantations; even more so when you are burning them into a smart card. Specifically, I would probably use some combination of the above instructions (to get my gpg.conf into the correct state), and then something like this guide: https://gist.github.com/abeluck/3383449
Specifically, I would look for a guide that instructs you to have a master key that is valid only for certification. I have a personal dislike for allowing your "master" key to be used for encryption, because it incentivizes you to do things that are not best-practice: specifically, using it. In the ideal world, your master key is kept, encrypted, on one (or more) USB drives that are all kept in various safes, and are never plugged into a computer that has an internet connection. Bonus points if the computer isn't used for anything else either. This is because your master key is the Thing That Must Not Be Compromised -- or you need to revoke the entire key and can never use it again. If a "working" subkey gets compromised, you can revoke it without losing all of the certification effort you've put into validating your identity in the web of trust.
I wrote a short guide called "Creating the perfect GPG keypair" < https://alexcabal.com/creating-the-perfect-gpg-keypair/ > some time ago. I mainly wrote it for myself as a sort of step-by-step reminder on how to create an ideal key, but it seems others have found it useful. In particular it borrows from the Debian guide on creating subkeys for use on a laptop (or other device that has a high chance of being stolen/compromised).
I don't consider myself an expert, and the guide is compiled from synthesizing several other guides. If anyone has tips on how to improve the guide, or spots any errors, please do let me know so I can update it.
Most mail clients "don't suck" at secure email: S/MIME is readily available, virtually everywhere.
Only because of some irrational dislike in the Open Source community do we even have this discussion. Self-signed X.509 certificates would have done more for the cause of "secure email" than all GnuPG advocacy ever did.
Most mail clients suck in one very fundamental way: Importing someone's published public key is a manual process, and usually a fairly obscure one.
Mail clients should automatically query keyservers for all of the addresses on the TO: line and automatically import the keys they find. Instead they assume you're going to pass keys around on USB sticks or some such nonsense and import them into GPG by hand using some arcane syntax. It's ridiculous.
I've seen a lot of how-to use PGP writeups, but I haven't found a single good one that helps both windows and mac users (or linux). And by good, I mean something that walks the user through the process of securely creating a key, protecting their private key, explaining the difference between a public key and a private key, explaining how to PGP sign an email, PGP encrypt an email properly, encrypt files, decrypt files, upload public keys to a key server (or why you shouldn't), how to decrypt an email... and anything else you need to know to not make any mistakes that would compromise yourself. PGP is great but there are a lot of ways you can make a mistake.
I dream of a day when secure communications is simple and usable by all.
I agree but this comes quite close (minus the walk-troughs) https://www.mailvelope.com/
Like with many things there is this "Ah that's pretty smart on several levels" with public private key crypto. But it takes a while and some repeated explaining, at least for me it did. This pasage in Little Brother (by Cory Doctorow) introduced me to it in a better way than ever: https://www.wattpad.com/12853166-little-brother-chapter-10
The big huge thing GPG installs tend to gloss over is publishing your damn key. It doesn't help that the online keystores tend to be poorly supported by mail clients (why is it such a challenge to auto-lookup emails?), but the alternative of mailing your key around so other people can use it is a joke.
If you want the masses using encrypted email the key distribution needs to be as seamless as possible. Right now it is the opposite of that. Key management in GPG is a straight up nightmare of dozens of keystores and downloading text files and arcane commandlines. Public key distribution is the elephant in the room with encrypted email. Well, that and the fact that so many people use webmail now and all major webmail providers have completely given up on encryption. I've even seen arguments that since Javascript can never be fully trusted that webmail will never support encryption. Those arguments feel a bit like the "if it can't be perfect it is useless" argument you see a lot in crypto circles that keeps people using entirely unsafe technologies instead of safer partial solutions.
GPG/PGP is a VERY hard tool, conceptually hard. Yes, you can run through these “quick-starts” but they give you zero understanding what exactly you are doing.
GPG requires a deep understanding of things it's based on: web of trust, public key, private key, revokation key, keys repository structure etc. And these things are really really hard.
Yes, it is. But that's a fault of the tool, not a fault of the world; while many of these problems are very difficult, and solutions are not easy to come by, some of them we do have good strategies for. And even for GPG itself, it could be far more forgiving than it is. Without fundamentally changing the protocol, we could eliminate a large portion of GPGs configurability, and streamline it to make the "correct" choices. We as a tech industry are slowly coming around to the idea that secure systems are ones with less choices, not more.
What's so hard about GPG? People say this all the time but don't qualify it. Most people who use GPG don't use "web of trust", "revocation keys", or know anything about "key repository structure". They generate a key, give it to their peer, get a key back, and encrypt messages to each other.
It's not the easiest tool in the world, but it's not that much harder than, say, using a nonstandard compression tool.
Number one issue for common people: "I use webmail".
Another issue common people don't think about: How do you backup your key and actually restore it in such a way that you can read your old mails again?
Oh, and how long was GpgOL not working for the current Outlook version? Another big stone that lies in your way.
And I wish tech-savvy people would just "allow" the workflow you described above.
I have encountered too many discussions where people got scared off, because "the web of trust is the only acceptable way", and "check your government-issued ID cards! Yes, even if he's your best friend since kindergarten and he gave you the key in person!".
Nerds love playing the key party game. They love calling some first-level support and asking to recite the key's fingerprint. They love showing how goddamn smart they are. And that puts everyone else off.
It's another expression of the "security is binary" mindset that also hinders opportunistic encryption. Because there is something better we must not use this.
Lose the web of trust (and "marginal trust" is something only techies can come up with...), have a nice UI with only four or five buttons, make it work with all Outlook versions and make it work with webmail (at least GMail) and you may have a winner.
The last one is the big one and nearly impossible for anyone else, but Google seems to be working it (end-to-end for Chrome).
>Number one issue for common people: "I use webmail".
Which is actually two issues. One, the interface; there's a GPG thingy for GMail, but it's kind of junk. Two, and no less important: how do I search my archive?
(Did you just say "download it"? You lose. Did you just say "don't use webmail"? You lose again.)
No, the webmail users lose because they have acclimated themselves to using a dumb terminal system which makes full confidentiality at least an order of magnitude more work to achieve. A user who is 100% unwilling to switch away from webmail will accomplish that security goal with just as little success as a steadfast fast-food patron pursing a healthy-eating goal.
Yeah, sorry, that's not how this works. Y'see, you're sending emails to people using webmail (I mean, if you're a nominally functional human being). So your emails are insecure, too, because you are insisting on something that is fundamentally not compatible with how normal people use computers in 2015.
This is a community thing. You need to give to get them to give. And you're not giving.
As the author points out, GPG makes it unnecessarily complex on top of that because it prioritizes backwards-compatibility over of ease of use.
Why not have sane defaults instead of asking for all these parameters?
There are apps that use crypto which have a much nicer interface. Telegram and Schildbach Bitcoin Wallet come to mind. Even BitMessage is easier to use.
You really only need to understand public key and private key, and the rest of that is not necessary for most of the use cases. If someone has any familiarity with the command line, then can pick it up quite quickly.
If you are on Android, use OpenKeychain. We don't ask these questions. Instead, we have a simple wizard guiding you through the process of creating a key. We don't ask for the algorithms (RSA, DSA,...). We don't ask for User IDs. We don't mention the words private or public key.
I would never have my private keys leave a smart card. I'd assume your PGP private key on hard drive, located in your home directory no less, is as good as compromised.
38 comments
[ 2.6 ms ] story [ 66.7 ms ] threadI suspect that people would gladly accept the ability to send and receive encrypted, signed emails, but the hassle factor of getting set up is simply too high.
In the computer tech world, we do rank ourselves. We post w3c validation badges on our page, we run our sites through ssllabs.com for a security report card. We work towards being an IPv6 Sage from he.net. So why not a GPG contest? Keybase might be a good site to organize such things.
Generate a key and upload it to a keyserver is a basic level. You key can be graded based on bits (1024 vs 2048 vs 4096) and algorithm chosen. Send an encrypted email awards more points. Send a signed message for more points. Receive an encrypted message (and respond with the unencrypted text) is more points. Receive 3 emails and reply to the one that is properly signed for more points.
At some point in your journey you can start socializing. Advertise on your blog/github/keybase/social media that you are participating in a gpg contact contest. People can send you signed messages, you can send to them. You both sign and forward the message to keybase, who uses the signature to validate both of you exchanged messages with gpg. Keybase could even provide uuid/tokens to hand out (encrypted) and further validate. The more gpg contacts you accumulate, the higher your score. The "worked all states" from ham radio could be an achievement in gpg contesting as well.
I've been looking at truly peer to peer communication systems to use on an amateur radio mesh network with no internet access. The best solutions have encryption baked in. I would have to get a major project going to rip the encryption aspect out in order to use them on amateur frequencies/amateur power levels.
Should I add a small thumbnail photo of myself in my key? Or is that generally frowned upon?
Finally, are there good sources on how I would create a 4096 bit master key, and then add a 2048 bit subkeys for signing and encryption that I can add to my smart card which only allows for keys up to 2048? Would generating 2048 subkeys allow me to still decrypt gpg encrypted emails sent to me encrypted with my 4096 bit master key?
Still trying to figure this all out after picking up some YubiKeys
The photo question is an interesting one - some people frown on it, some people like it. Personally, I lean towards not adding them, just because the number of times I've actually checked it is so low (maybe once, ever.) That being said, I don't think people feel so strongly that they'd refuse to use or sign your key over it; they might just not sign that particular uid. (The photo is stored the same way an alternate email is, basically.)
Properly setting up an offline subkey involves some rather archaic incantations; even more so when you are burning them into a smart card. Specifically, I would probably use some combination of the above instructions (to get my gpg.conf into the correct state), and then something like this guide: https://gist.github.com/abeluck/3383449
Specifically, I would look for a guide that instructs you to have a master key that is valid only for certification. I have a personal dislike for allowing your "master" key to be used for encryption, because it incentivizes you to do things that are not best-practice: specifically, using it. In the ideal world, your master key is kept, encrypted, on one (or more) USB drives that are all kept in various safes, and are never plugged into a computer that has an internet connection. Bonus points if the computer isn't used for anything else either. This is because your master key is the Thing That Must Not Be Compromised -- or you need to revoke the entire key and can never use it again. If a "working" subkey gets compromised, you can revoke it without losing all of the certification effort you've put into validating your identity in the web of trust.
I don't consider myself an expert, and the guide is compiled from synthesizing several other guides. If anyone has tips on how to improve the guide, or spots any errors, please do let me know so I can update it.
If you can use Thunderbird I see no reason why you can't use GPG
(I loved EnigMail, back when I was using it)
If you want secure email then use an email client that doesn't suck at it?
(That said, the key management part of GPG doesn't become easier just because you use Thunderbird)
Only because of some irrational dislike in the Open Source community do we even have this discussion. Self-signed X.509 certificates would have done more for the cause of "secure email" than all GnuPG advocacy ever did.
Uh, nope, nope, nope. You can't even revoke those things AFAIK. Also I'm not sure how those are any easier than using PGP.
Mail clients should automatically query keyservers for all of the addresses on the TO: line and automatically import the keys they find. Instead they assume you're going to pass keys around on USB sticks or some such nonsense and import them into GPG by hand using some arcane syntax. It's ridiculous.
I dream of a day when secure communications is simple and usable by all.
If you want the masses using encrypted email the key distribution needs to be as seamless as possible. Right now it is the opposite of that. Key management in GPG is a straight up nightmare of dozens of keystores and downloading text files and arcane commandlines. Public key distribution is the elephant in the room with encrypted email. Well, that and the fact that so many people use webmail now and all major webmail providers have completely given up on encryption. I've even seen arguments that since Javascript can never be fully trusted that webmail will never support encryption. Those arguments feel a bit like the "if it can't be perfect it is useless" argument you see a lot in crypto circles that keeps people using entirely unsafe technologies instead of safer partial solutions.
GPG requires a deep understanding of things it's based on: web of trust, public key, private key, revokation key, keys repository structure etc. And these things are really really hard.
It's not the easiest tool in the world, but it's not that much harder than, say, using a nonstandard compression tool.
Another issue common people don't think about: How do you backup your key and actually restore it in such a way that you can read your old mails again?
Oh, and how long was GpgOL not working for the current Outlook version? Another big stone that lies in your way.
And I wish tech-savvy people would just "allow" the workflow you described above.
I have encountered too many discussions where people got scared off, because "the web of trust is the only acceptable way", and "check your government-issued ID cards! Yes, even if he's your best friend since kindergarten and he gave you the key in person!".
Nerds love playing the key party game. They love calling some first-level support and asking to recite the key's fingerprint. They love showing how goddamn smart they are. And that puts everyone else off.
It's another expression of the "security is binary" mindset that also hinders opportunistic encryption. Because there is something better we must not use this.
Lose the web of trust (and "marginal trust" is something only techies can come up with...), have a nice UI with only four or five buttons, make it work with all Outlook versions and make it work with webmail (at least GMail) and you may have a winner.
The last one is the big one and nearly impossible for anyone else, but Google seems to be working it (end-to-end for Chrome).
Which is actually two issues. One, the interface; there's a GPG thingy for GMail, but it's kind of junk. Two, and no less important: how do I search my archive?
(Did you just say "download it"? You lose. Did you just say "don't use webmail"? You lose again.)
This is a community thing. You need to give to get them to give. And you're not giving.
The workflow you described is easy and usually good enough and can be achieved with thunderbird + enigmail alone.
Why not have sane defaults instead of asking for all these parameters?
There are apps that use crypto which have a much nicer interface. Telegram and Schildbach Bitcoin Wallet come to mind. Even BitMessage is easier to use.
https://github.com/Spark-Innovations/SC4
Runs in a browser. Modern crypto (elliptic curves instead of RSA). Audited code. Open source.
See http://www.openkeychain.org/