I’m currently reading Creating the perfect GPG keypair and it makes me want to cry. Keeping them master key on an encrypted USB stick. Where will I keep it? How will I make sure I won’t loose it over the next five years? Keeping a revocation certificate—somewhere else! How will I make sure I won’t loose *that*?
Creating the perfect GPG keypair
Perhaps it’s easier no to rely on all that. I’m sure there’s a different set of requirements out there that would fit me. A set of requirements that doesn’t require me to do all that. A set of requirements for ordinary people.
Consider this: If you’re my friend, how do you know that I’m the person I claim to be? We keep in contact. We exchange messages every now and then. Thus, if my keys expire every now and then, shouldn’t that work just the same? I will have to rebuild my web of trust, but to be honest, I don’t *have* a web of trust. If you want to make sure that I’m the person you think I am, you will have to verify this by other channels. Compare fingerprints on the phone, using a different *channel*.
alex@Megabombus:~$ gpg --search-key kensanata gpg: suche nach "kensanata" auf hkp-Server keys.gnupg.net (1) Alex Schroeder <alex@gnu.org> Alex Schroeder <kensanata@gmail.com> 8192 bit RSA key ACECFEAE, erzeugt: 2015-03-01 (2) Alex Schroeder <alex@gnu.org> Alex Schroeder <alex@emacswiki.org> Alex Schroeder <kensanata@gmail.org> Alex Schroeder <alex.schroeder@openlaw.ch> 1024 bit DSA key 89D0FBCC, erzeugt: 2006-06-26 (widerrufen) (3) Alex Schroeder <alex@gnu.org> Alex Schroeder <alex@emacswiki.org> Alex Schroeder <kensanata@gmail.com> 1024 bit DSA key 353AEFEF, erzeugt: 2002-07-10 (widerrufen) (4) Alex Schroeder (Kensanata) <alex@gnu.org> 1024 bit DSA key 23AAC850, erzeugt: 2001-04-12 Keys 1-4 of 4 for "kensanata". Eingabe von Nummern, Nächste (N) oder Abbrechen (Q) > q
You want #1. 😄
Note how I lost access to #4. No way to revoke it. Forgot to set an expiry date. *The sound of bleating goats!*
#Security
(Please contact me if you want to remove your comment.)
⁂
Moxie Marlinspike just did a similar blog post about this.
a similar blog post about this
I find GPG pretty painful to use in general, although the integration with Emacs is exceptional. I store a lot of .gpg files around and it’s very nice to have those automatically decrypted with emacs.
I like what Keybase.io is doing. I don’t store my private key with them but nowadays, I “trust” people online by their various social media accounts and I think keybase is leveraging that better than the web-of-trust.
– Josh 2015-03-01 18:24 UTC
---
So, what I did was revoke my old key, and then I opened my `~/.authinfo.gpg` file which is encrypted to my home key and to my work key. My revoked, old key, of course. No problem, provided the passphrase, decoded it. Made a change, tried to save. Ah, but gpg no longer wants to use the revoked, old key. I understand. But how to tell Emacs to use the new key? What a mess. Messing around with `epa-list-keys` and studying the keys available. Setting `epa-file-encrypt-to`. Trying it a few more times. Setting `epa-file-select-keys` to a different value, trying it a few *more* times. Seeing the a list of keys and not recognizing one of the keys. Finding the revoked key in the list. All in all it was totally not straight forward. In hindsight, I could explain the behavior. But when it happened, I was confused. Gah!
Thanks for the link to the Moxie Marlinspike blog post. He makes a good point! 😄
And thank you for the Keybase.io link. I didn’t know about it and it sounds like the sort of web of trust replacement I’m thinking of!
– Alex Schroeder 2015-03-01 22:38 UTC
---
Here’s an interesting post about using git and gpg to maintain a secure developing environment. Security is definitely hard. A Git Horror Story: Repository Integrity With Signed Commits by Mike Gerwitz.
A Git Horror Story: Repository Integrity With Signed Commits
– Alex Schroeder 2015-03-02 07:23 UTC
---
Here’s an article talking about the problem of usability and that even when fighting the Apartheid, people were careless. The Usability of Anti-Apartheid Encryption.
The Usability of Anti-Apartheid Encryption
– Alex Schroeder 2015-03-03 13:31 UTC
---
Now that I want to add a new identity to my key, I find that I cannot.
Using my super USB stick:
$ gpg --import public-ACECFEAE.asc secret-ACECFEAE.asc gpg: key ACECFEAE: "Alex Schroeder <alex@gnu.org>" not changed gpg: key ACECFEAE: already in secret keyring gpg: Total number processed: 2 gpg: unchanged: 1 gpg: secret keys read: 1 gpg: secret keys unchanged: 1
And it still says “sec#”:
$ gpg --list-secret-keys /Users/alex/.gnupg/secring.gpg ------------------------------ [...] sec# 8192R/ACECFEAE 2015-03-01 [verfällt: 2019-02-28] uid Alex Schroeder <alex@gnu.org> uid Alex Schroeder <kensanata@gmail.com> ssb 8192R/4529A45C 2015-03-01 ssb 4096R/F6881931 2015-03-01
“The pound sign means the signing subkey is not in the keypair located in the keyring”, according to Alex Cabal.
OK, that looks like an inconvenience.
It turns out that I have to *delete* the secret key before importing it again!?
$ gpg --delete-secret-keys ACECFEAE sec 8192R/ACECFEAE 2015-03-01 Alex Schroeder <alex@gnu.org> Delete this key from the keyring? (y/N) y This is a secret key! - really delete? (y/N) y $ gpg --import secret-ACECFEAE.asc gpg: key ACECFEAE: secret key imported gpg: key ACECFEAE: "Alex Schroeder <alex@gnu.org>" not changed gpg: Total number processed: 1 gpg: unchanged: 1 gpg: secret keys read: 1 gpg: secret keys imported: 1 $ gpg -K /Users/alex/.gnupg/secring.gpg ------------------------------ [...] sec 8192R/ACECFEAE 2015-03-01 [verfällt: 2019-02-28] uid Alex Schroeder <alex@gnu.org> uid Alex Schroeder <kensanata@gmail.com> ssb 8192R/4529A45C 2015-03-01 ssb 4096R/F6881931 2015-03-01
And now I can finally edit the key and add another user ID.
– Alex Schroeder 2015-06-02 21:26 UTC