diff options
Diffstat (limited to 'posts/gpg-transition.org')
| -rw-r--r-- | posts/gpg-transition.org | 207 |
1 files changed, 207 insertions, 0 deletions
diff --git a/posts/gpg-transition.org b/posts/gpg-transition.org new file mode 100644 index 0000000..99f889d --- /dev/null +++ b/posts/gpg-transition.org @@ -0,0 +1,207 @@ +#+TITLE: GPG Key Transition +#+DESCRIPTION: Key transition statement and verification steps +#+TAGS: GPG +#+TAGS: GNUPG +#+TAGS: Smartcards +#+TAGS: Yubikeys +#+DATE: 2017-08-23 +#+SLUG: gpg-key-transition +#+LINK: gpg-transition-document https://kennyballou.com/blog/2017/08/gpg-key-transition/gpg-transition.org.asc +#+LINK: gpg-public-key https://kennyballou.com/kballou.pub.asc +#+LINK: chameth-offline-master-key-subkeys https://www.chameth.com/2016/08/11/offline-gnupg-master-yubikey-subkeys/ +#+LINK: void-kargig-new-key-with-subkeys https://www.void.gr/kargig/blog/2013/12/02/creating-a-new-gpg-key-with-subkeys/ +#+LINK: gist-338449 https://gist.github.com/abeluck/3383449 +#+LINK: yubico-neo https://www.yubico.com/products/yubikey-hardware/yubikey-neo/ +#+LINK: paperkey http://www.jabberwocky.com/software/paperkey/ +#+LINK: wiki-smart-cards https://en.wikipedia.org/wiki/Smart_card +#+LINK: gnupg https://gnupg.org/ +#+LINK: fsfe-drdanz-782 http://blogs.fsfe.org/drdanz/?p=782 +#+LINK: key-1066BA71A5F56C58 https://pgp.mit.edu/pks/lookup?op=get&search=0x1066BA71A5F56C58 +#+LINK: key-1CFA8A9CD949D956 https://pgp.mit.edu/pks/lookup?op=get&search=0x1CFA8A9CD949D956 +#+LINK: key-B0CAA28A02958308 https://pgp.mit.edu/pks/lookup?op=get&search=0xB0CAA28A02958308 + +#+BEGIN_PREVIEW +Today I'm announcing my [[gnupg][GPG]] transition from my old, and now expired, +[[gnupg][GPG]] key: +[[key-1066BA71A5F56C58][DAEE96513758BF6337F71E491066BA71A5F56C58]] and +[[key-1CFA8A9CD949D956][8FCAF4F0CBB0BB9C590C8ED11CFA8A9CD949D956]] to a new master +key [[key-B0CAA28A02958308][932F3E8E1C0F4A9895D7B8B8B0CAA28A02958308]]. The old +key will remain vaild for a little while longer, but I prefer all future +correspondence to be addressed to my new key. +#+END_PREVIEW + +This transition document is signed by all three keys to validate the +transition. + +If you have signed my old key, I would appreciate new signatures on my new key +as well, provided that your signing policy permits that without +re-authenticating me. + +** Key Verification + :PROPERTIES: + :CUSTOM_ID: key-verification + :END: + +Specifically, the old keys were: + +#+BEGIN_EXAMPLE + pub rsa4096 2014-06-12 [expired: 2017-06-27] + DAEE 9651 3758 BF63 37F7 1E49 1066 BA71 A5F5 6C58 +#+END_EXAMPLE + +and, + +#+BEGIN_EXAMPLE + pub rsa4096 2015-01-30 [expires: 2018-01-30] + 8FCA F4F0 CBB0 BB9C 590C 8ED1 1CFA 8A9C D949 D956 +#+END_EXAMPLE + +The new key is: + +#+BEGIN_EXAMPLE + pub rsa4096 2017-06-27 [expires: 2022-06-26] + 932F 3E8E 1C0F 4A98 95D7 B8B8 B0CA A28A 0295 8308 +#+END_EXAMPLE + +To fetch my new key from a key server, use the following: + +#+BEGIN_EXAMPLE + gpg --keyserver pool.sks-keyservers.net --recv-key 0xB0CAA28A02958308 +#+END_EXAMPLE + +Or, if you prefer, you may also download the new key from +[[gpg-public-key][this blog]]: + +#+BEGIN_EXAMPLE + curl -fsL https://kennyballou.com/kballou.asc -O +#+END_EXAMPLE + +The new key can be verified with the old key: + +#+BEGIN_EXAMPLE + gpg --check-sigs 0xB0CAA28A02958308 +#+END_EXAMPLE + +If you do not have the old key, or would like to double check, the fingerprint +can be verified against the one above: + +#+BEGIN_EXAMPLE + gpg --fingerprint 0xB0CAA28A02958308 +#+END_EXAMPLE + +If you have all of the keys, [[gpg-transition-document][this document]] can be +verified to be signed by all keys: + +#+BEGIN_EXAMPLE + gpg --verify gpg-transition.org.asc +#+END_EXAMPLE + +If you are satisfied that you have the correct key and the UID's match, and if +it's compatible with your key signing policy, I would greatly appreciate it if +you would sign my key: + +#+BEGIN_EXAMPLE + gpg --sign-key 0xB0CAA28A02958308 +#+END_EXAMPLE + +Finally, if you could upload these signatures, I would appreciate it. You can +either upload the signatures to a public key server directly: + +#+BEGIN_EXAMPLE + gpg --keyserver pool.sks-keyservers.net \ + --send-key 0xB0CAA28A02958308 +#+END_EXAMPLE + +Or you can send me an email with the new signatures: + +#+BEGIN_EXAMPLE + gpg --armor --export 0xB0CAA28A02958308 +#+END_EXAMPLE + +** New GPG Setup + :PROPERTIES: + :CUSTOM_ID: new-gpg-setup + :END: + +The new key/transition is brought about by a number of months of thinking about +[[gnupg][GPG]] and a set of small problems I've been facing with +[[gnupg][GPG]]. Mainly, sharing keys between the number of different computers +I use through the day makes me sad and worrisome. Similarly, there isn't a +good backup/recovery solution to the previous setup, something the transition +aims to fix. Finally, multiple keys per identity was more bothersome than I +had originally anticipated. + +My knowledge of [[gnupg][GPG]] was young and it was time to level up my +knowledge. To that end, I will, briefly, describe how my current setup works. + +*** Key Generation and Storage + :PROPERTIES: + :CUSTOM_ID: key-generation-and-storage + :END: + +This new setup follows the basic "master-key with sub-keys" approach. I have +an encrypted USB drive (several, actually), that contains the master key and +the sub keys. The master key is used for signing and self-certification, but +has no other purpose. The sub keys are created for the other purposes, e.g., +encryption, signing, and authentication. I will not go over the specifics of +generating the keys or creating this setup, there are +[[chameth-offline-master-key-subkeys][many]] +[[void-kargig-new-key-with-subkeys][guides]] [[gist-338449][already]] for that +purpose. + +To solve the multiple device problem, I purchased a [[yubico-neo][Yubikey Neo]] +to contain the sub keys. I'm currently, as of this writing, only using the +[[wiki-smart-cards][smartcard]] functionality of the Yubikey, thus, I cannot +speak to its other uses. However, something to note, the current Yubikey +(series 4) cannot hold keys bigger than 3072 bits, thus, all of my sub keys are +2048 bits. This turns out to be an acceptable trade off, as 2048 keys are +really, really similar in strength to 4096 keys. I don't have enough +cryptographic knowledge to sink into the Elliptic-Curve based key algorithms, +but they seem to show great strengths against the larger RSA algorithm without +as many weaknesses. + +*** Multiple Identities + :PROPERTIES: + :CUSTOM_ID: multiple-identities + :END: + +[[gnupg][GPG]] keys can have multiple UID's associated with them, eliminating +the need for a mapping of keys to email addresses, (unless of course, a key not +associated with your identity is desired). However, I took a bit of a +pragmatic approach here: I did not want "work" keys tightly integrated with my +own identity. It will be likely I will still generate a separate key for work +related activities. This way, deleting passwords and other secrets is as +simple as deleting the key, I do not actually have to worry about the +possibility of still being able to decrypt the passwords and encrypted data. + +The one drawback to this approach of having a separate key pair for personal +and work related activities is that it either necessitates /another/ +[[yubico-neo][Yubikey]], or I'm back to where I was with the previous setup and +the multi-device headaches that are associated with it. However, I feel this +is acceptable, because /usually/ I only have one "work" device, but multiple +personal devices. + +*** Backups + :PROPERTIES: + :CUSTOM_ID: backups + :END: + +I've created numerous copies of the encrypted USB drive, and they will be +scattered to a number of locations, to make sure that I can still access at +least /a/ copy of the keys, it might not be the most up to date key, but it +will get me started in getting back online. + +Furthermore, because flash memory isn't perfect, I've also created a number of +printouts using [[paperkey][paperkey]] such that I can recover the key even if +/all/ of the USB keys fail. + +*** Future Work + :PROPERTIES: + :CUSTOM_ID: future-work + :END: + +One aspect of the system I would like to improve at some point is that instead +of creating exact duplicates of the flash drives or the [[paperkey][paperkey]] +printouts, I would like to be able to create \(n\) by \(m\) chunks of the key +data. That is, create a backup of \(n\) pieces that only require \(m\) copies +to be recoverable. |