1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
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.
|
