11–20 of 40 posts
I can see a subtle problem with that scheme - the attacker will be able to read also all of your future communication.
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.
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.
And the length of this is exactly the reason why Johnny still can't encrypt and doesn't want to know how. Getting things right, including disaster recovery, should be done correctly and silently by default.
Not everyone has the same threat model, not everyone needs all of that. Johnny can encrypt. https://twitter.com/AlecMuffett/status/608006725040365568
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.
Earlier quoted context omitted.
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.
Anyway, I think it's very risky to rely on single physical item for your private key storage.
And the length of this is exactly the reason why Johnny still can't encrypt and doesn't want to know how. Getting things right, including disaster recovery, should be done correctly and silently by default.
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).
And the length of this is exactly the reason why Johnny still can't encrypt and doesn't want to know how. Getting things right, including disaster recovery, should be done correctly and silently by default.
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.
And the length of this is exactly the reason why Johnny still can't encrypt and doesn't want to know how. Getting things right, including disaster recovery, should be done correctly and silently by default.
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.
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).
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.
[1] - https://en.wikipedia.org/wiki/Steganography
[2] - https://en.wikipedia.org/wiki/Traffic_analysis
[3] - due to traffic analysis, or if there's some indication (such as signatures or headers) of who sent it or to whom
[4] - not necessarily through any fault of yours (see "Three Felonies a Day")
[5] - depending on your legal jurisdiction and how sympathetic the judge is