Add gpg transition post

2 files changed, 209 insertions, 0 deletions

diff --git a/content/blog/gpg-transition.markdown b/content/blog/gpg-transition.markdown
new file mode 100644
index 0000000..9331122
--- /dev/null
+++ b/content/blog/gpg-transition.markdown
@@ -0,0 +1,174 @@
+---
+title: "GPG Key Transition"
+description: ""
+tags:
+  - GPG
+  - GNUPG
+  - Smartcards
+  - yubikeys
+date: "2017-08-23"
+slug: "gpg-key-transition"
+---
+
+Today I'm announcing my [GPG][6] transition from my old, and now
+expired, [GPG][6] key: [DAEE96513758BF6337F71E491066BA71A5F56C58][0]
+and [8FCAF4F0CBB0BB9C590C8ED11CFA8A9CD949D956][1] to a new master
+key [932F3E8E1C0F4A9895D7B8B8B0CAA28A02958308][2].  The old key will
+remain vaild for a little while longer, but I prefer all future
+correspondence to be addressed to my new key.
+
+This transition document is signed by both 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 ##
+
+Specifically, the old keys were:
+
+    pub   rsa4096 2014-06-12 [expired: 2017-06-27]
+    DAEE 9651 3758 BF63 37F7 1E49 1066 BA71 A5F5 6C58
+
+and,
+
+    pub   rsa4096 2015-01-30 [expires: 2018-01-30]
+    8FCA F4F0 CBB0 BB9C 590C 8ED1 1CFA 8A9C D949 D956
+
+The new key is:
+
+    pub   rsa4096 2017-06-27 [expires: 2022-06-26]
+    932F 3E8E 1C0F 4A98 95D7 B8B8 B0CA A28A 0295 8308
+
+To fetch my new key from a key server, use the following:
+
+    gpg --keyserver pool.sks-keyservers.net --recv-key 0xB0CAA28A02958308
+
+Or, if you prefer, you may also download the new key
+from [this blog][this]:
+
+    curl -fsL https://kennyballou.com/kballou.asc -O
+
+The new key can be verified with the old key:
+
+    gpg --check-sigs 0xB0CAA28A02958308
+
+If you do not have the old key, or would like to double check, the
+fingerprint can be verified against the one above:
+
+    gpg --fingerprint 0xB0CAA28A02958308
+
+If you have both keys, this document can be verified to be signed by
+both keys:
+
+    gpg --verify gpg-transition.markdown.asc
+
+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:
+
+    gpg --sign-key 0xB0CAA28A02958308
+
+Finally, if you could upload these signatures, I would appreciate it.
+You can either upload the signatures to a public key server directly:
+
+    gpg --keyserver pool.sks-keyservers.net \
+        --send-key 0xB0CAA28A02958308
+
+Or you can send me an email with the new signatures:
+
+    gpg --armor --export 0xB0CAA28A02958308
+
+## New GPG Setup ##
+
+The new key/transition is brought about by a number of months of
+thinking about the [GPG][6] and a set of small problems I've been facing
+with [GPG][6].  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 [GPG][6] 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 ###
+
+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 [many][0] [guides][1] [already][2] for that purpose.
+
+To solve the multiple device problem, I purchased a [Yubikey Neo][3]
+to contain the sub keys.  I'm currently, as of this writing, only
+using the [smartcard][5] 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 ###
+
+[GPG][6] 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_ [Yubikey][3], 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 ###
+
+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][4] such that I can recover the
+key even if _all_ of the USB keys fail.
+
+### Future Work ###
+
+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][4] 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.
+
+[this]: https://kennyballou.com/kballou.pub.asc
+
+[0]: https://www.chameth.com/2016/08/11/offline-gnupg-master-yubikey-subkeys/
+
+[1]: https://www.void.gr/kargig/blog/2013/12/02/creating-a-new-gpg-key-with-subkeys/
+
+[2]: https://gist.github.com/abeluck/3383449
+
+[3]: https://www.yubico.com/products/yubikey-hardware/yubikey-neo/
+
+[4]: http://www.jabberwocky.com/software/paperkey/
+
+[5]: https://en.wikipedia.org/wiki/Smart_card
+
+[6]: https://gnupg.org/
+
+[7]: http://blogs.fsfe.org/drdanz/?p=782
diff --git a/content/blog/gpg-transition.markdown.asc b/content/blog/gpg-transition.markdown.asc
new file mode 100644
index 0000000..7e82967
--- /dev/null
+++ b/content/blog/gpg-transition.markdown.asc
@@ -0,0 +1,35 @@
+-----BEGIN PGP SIGNATURE-----
+
+iQIzBAABCAAdFiEEj8r08Muwu5xZDI7RHPqKnNlJ2VYFAlmdIzEACgkQHPqKnNlJ
+2VbU1g/+I4s/PfS3Z7KfHltMxQtIhFYHg1XD2/O9BQmnLqYCbdu799nmfem7fxfC
+scBrvWwCzMilQg3Os2CK8ZxOBAuPjWlJZw1p8do2gB7zZFQlN33v6wcCQPPS5Vwd
+ca72WiP+MH/QdmgzTvg7AgSuM8HrBzUzmz9Xo2ND0KgA9Cz3kgRaYC9XyVUD9SQ7
++BwM3Jqm62HAyHNhB07zcsGbBH569Fa9gS2MG9e+upsEYXNOLQGPxyMruOznyYbA
+C0P7acAmcN8gL3UE98aDwdCtibDe8Mwk+68wZu+wHSIh20If+rQqSMOscERVdRez
+Txh68LeHbg+6D6Syl61qDd7whdf6A26Alr4339RTkFQoZkTdX+BhHalnaNYVKeVA
+/qTHJQ2NmBjwULMWxiBWxnaB4ZIw+Z8kNWFYZ33FHAXfvFp6uNigK4foP9M4IC1m
+5/rc+h14bj+WaIgF0QIyM5AQU2QrZ0GjfIXRPOeUTsRpG0i1Fr6xKbXdzsdv3Vtf
+1P0zAMXbisfNudZbcympLCWPpcDzy9cNDqB6XXKqvE48aUUce9BA5i3fTkdIMl8y
+pXFmOvT6ntGO5DTReO5m6/7T98qxEkUUbu8nD0qR5b8q7QC3TqcQ+WJhJH8evVZS
+xzpZivvq3bFZ2+7eZUNxTvLXfsf43iJCkcVe7RePIa5OI5h3MNSJAjMEAAEIAB0W
+IQTa7pZRN1i/Yzf3HkkQZrpxpfVsWAUCWZ0jMQAKCRAQZrpxpfVsWJbgD/9YtZr2
+OAzEzEGolLn4g4vJOpkSqry3oYVZArRvXJPxWqLHe3Nv0sxKYEnVFviESQlNTGH/
+puHWzHhyT07EItpCNRc9AdGrIRf3A0rEuGXOLOmpDM/rmmoCLGiO+GZpI8Qe76re
+p90smPHgcCk/XBA0upHW8EJI1yH2Q1X2bhc8xItOq2MrLWnbfsiFf3zc7qsJztL6
+YMdfm1EpJynBAjdMM+8gg73BSLYoZVU2GhrKOIMdWF5FOIzqf1WbCE3qnelCy0As
+/bL4jwDN9e1TnELVwvqCmeCVo2SzyFx+iu/R06QiF6eb1qX4j221Gp4FvPAf9x8f
+sscoeES9MnaN9R1J4tGbV+g/HKZbxsE9HFc2FIBy8OMawmXFYLZrA4ByxMFxS2NQ
+0XbRNeS90Ku7EMdGI+AV5cfrByvMknbzNF/p2Ep44y+yDWDikFaFtp0lZmG0GS2O
+hHUVUVNaazdALTZ8yAKuAtRtKtqAQgNBz2ODpe9BnN5j/VkJVJIao/8vq/epPyQQ
+2K+rpYBwqt8CSTMs7Fr9n38HRGmrY7lkYvcebNSxqxHTcERG0IRQLnJrVkoxGkZL
+eV0SwO9LOD0h4nUXGnyLWsfr6iYFfIqZ6ay7JrDj4NrFTwj/COGW4buZhpI6tcK4
+f6jIf811vbTVQFR/aJ/oP3Snvgk7ab/DyseLRokBMwQAAQgAHRYhBOHS4Af04GxI
+WZD+1v4UeXzm9h/yBQJZnSMxAAoJEP4UeXzm9h/yrVAH/AmXh0CQrW1trYqMv4FN
+p8qLFMV1YQytI874ix7xNHZC9gmjhzTzWgbk8f0mlvO0eWpPZyIoJuiDPPgYKwee
+FFeBBwLl+iilo3DJnnPEGyXgkR3EnvWKsQFPu2ncDrpz3hhegaHplJMNfYxLbftE
+xfycL0WYvUEgpsm/pINlAYUcjBsovOHkHj9GtA4iotFMNBNIkiIFqK4fUXpZ523f
+Y6YBzSTSv/8Y+F2JvNoJ+GWfSAOSmXu2NC4zYP40xPp1/uZOzAQgfYc9s9KPahWi
+tO22AxSGmDrcRAUhRH816XE7vbowuJvNaULRgDde6KK88JIJFztNCNjUwqQ2DD2m
+pMk=
+=mrZk
+-----END PGP SIGNATURE-----