Gentoo Archives: gentoo-dev

From: "Robin H. Johnson" <robbat2@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Signing everything, for fun and for profit
Date: Fri, 19 May 2006 04:32:19
In Reply to: [gentoo-dev] Signing everything, for fun and for profit by Patrick Lauer
1 This email is a discussion on why we need to care about more than the simple
2 key parameters, and why - this includes things like changing the validity of an
3 existing key. We also need to consider: location of key (primary key vs.
4 subkey), expiry policies (expiries are only one element of key validity), key
5 signatures, and revoking elements in a key.
7 I've tried very hard to ensure absolutely all of the following is
8 completely fact, and that I have not entered any of my opinions into it,
9 except where I've explictly marked it as such.
11 On Thu, May 18, 2006 at 11:45:17PM +0200, Patrick Lauer wrote:
12 > Key policies
13 > ============
14 > To make signing relevant and verifiable all devs should use the same
15 > parameters - key length, key type, validity.
16 No, the simple parameters of the have little bearing on how they are used.
17 While we do care about them in terms of managing file signatures, some
18 understanding is needed first.
20 Introduction
21 ------------
22 The following is an introduction into some of the OpenPGP standard, with a
23 focus on how it affects file signing, key signing, management of keys (for
24 the complex style listed), and revocation.
26 It's important as to what attacks against a key can lead to what results.
28 Breakdown of what is a 'key' is
29 -------------------------------
30 A 'key' under PGP/GnuPG (OpenPGP) consists of several important entities:
31 1. *actual cryptographic primary keys and secondary keys (subkeys) [pub/sub]
32 2. *user ids - one uid per email address [uid]
33 3. signatures, each attached to one uid [sig]
34 4. revocations of any of the above items [rev]
35 I've included the packet type name in the [] at the end.
36 The first two items marked with a * are the core entities, and items are
37 associated with only one element of them.
38 There are a few more packet types, but they aren't important to our
39 discussion.
41 After this point, I will use the term 'cryptokey' to refer to the actual
42 cryptographic keys, and the generic term 'key' to refer to the collection of
43 above items.
45 To see the various elements of the above, try this:
46 "gpg --list-sig SOMEDEV@g.o"
47 If you look at my key, it goes on for a few pages (but isn't quite as
48 long as the Paludis thread).
50 The first column has the information type, and you'll see the types I
51 mentioned above.
53 Now let's focus on a single key for a moment:
55 # gpg --edit-key robbat@g.o
56 ...
57 pub 1024D/34884E85 created: 2002-08-27 expires: 2008-03-09 usage: CS
58 trust: ultimate validity: ultimate
59 sub 2048g/CA05A397 created: 2002-08-27 expires: 2008-03-09 usage: E
60 sub 2048g/67592A1F created: 2003-04-12 expires: 2008-03-09 usage: E
61 This key was revoked on 2004-09-09 by DSA key 34884E85 Robin Hugh Johnson <robbat2@××××××××××××××.net>
62 sub 1024D/FB33B3A4 created: 2002-08-27 revoked: 2004-09-09 usage: SA
63 This key was revoked on 2004-09-09 by DSA key 34884E85 Robin Hugh Johnson <robbat2@××××××××××××××.net>
64 sub 2048g/CC772FC3 created: 2002-08-27 revoked: 2004-09-09 usage: E
65 sub 1024D/3233C22C created: 2004-08-29 expires: 2008-03-09 usage: S
66 [ultimate] (1). Robin Hugh Johnson <robbat2@××××××××××××××.net>
67 [ revoked] (2) Robin Hugh Johnson <rjohnsob@×××.ca>
68 [ultimate] (3) Robin Hugh Johnson <robbat2@×××××××××××××××××.net>
69 [ultimate] (4) Robin Hugh Johnson <robbat2@g.o>
70 [ revoked] (5) Robin Hugh Johnson <rhj@×××.ca>
71 [ revoked] (6) Robin Hugh Johnson <robbat2@×××.ca>
72 [ revoked] (7) Robin Hugh Johnson <robbat2@×××××××.com>
73 [ revoked] (8) Robin Hugh Johnson <robin@×××××××.com>
74 [ revoked] (9) Robin Hugh Johnson <robbat2@×××××××××.com>
76 The important bit here is the 'usage:' bit at the end of the cryptokeys.
77 There are 4 letters that will appear here:
78 C - Certify
79 S - Sign
80 E - Encrypt
81 A - Authenticate
83 We are interested in two of these only: Certify and Sign.
84 We aren't dealing with encrypted data at the moment, and usage of authenticate
85 is not implemented in gpg-1.4.
87 'Certify' is the terminology used for signing uids.
88 'Sign' is the terminology used for digitally signing files/data.
90 If you attend a keysigning event, you are certifying that a uid does indeed
91 belong to a person (more on this in a moment, in how we can gain from it).
93 From this point forward, I will use 'certify' to indicate signing of a
94 key, and signing to indicate other data signing.
96 Only the primary cryptokey [pub] will ever be marked with Certify.
97 The primary cryptokey is used for all uid signatures made with your key.
98 It also protects your key itself from some modifications by attackers.
100 Having multiple UIDs allows a person to go over several email addresses
101 over time, without having to invalidate old correspondence, or identify
102 themselves to any given third party more than once.
104 Choice of Length/Type:
105 ----------------------
106 Any of the cryptokeys marked with Sign will be used in signing Manifest/digest
107 data.
108 We have a few choices for these - I'm limiting this to what is implemented in
109 upstream GnuPG, and not anything added by external patches.
110 CryptoKey types: DSA, RSA.
111 CryptoKey lengths:
112 - DSA provides a length of 1024 bits only (gnupg does not allow you to chose
113 anything else without special options, and that is only weaker keys).
114 - RSA lengths between 1024 and 4096 bits available.
116 The following is a small speed comparison produced with 'openssl bench rsa
117 dsa', run single-threaded, and excluding the variants (DSA512, DSA2048) not
118 available in GnuPG.
120 32-bit x86 (Athlon XP)
121 sign/s verify/s
122 DSA1024 592.2 501.3
123 RSA1024 264.7 5581.9
124 RSA2048 48.0 1763.5
125 RSA4096 7.6 510.1
127 Apple G5, Quad:
128 sign/s verify/s
129 DSA1024 2125.7 1735.8
130 RSA1024 1032.4 18829.6
131 RSA2048 171.0 5988.2
132 RSA4096 26.3 1754.4
134 Not reflected in this is generation time for keys as that is a one time
135 occurrence, the time it takes is mostly irrelevant, but for the record, RSA is
136 several times slower for equivalent key lengths.
138 Note: these speeds would not be affected by the size of the data - as GnuPG
139 signs a hash of the data only.
141 There are 11k packages in the tree now, and if we assume 2 signatures per
142 package for the moment, that's ~40 seconds to verify the entire tree (assuming
143 no other bottlenecks, which is completely unreasonable) with RSA4096 on a
144 slower machine.
146 For the question of key length - I ask the security folk - what do you consider
147 reasonable without being paranoid?
149 <opinion>
150 It's pretty obvious in this, that RSA is slow for signing, but fast for
151 verifying. Unless we have a specific need for high speed signing, I'd suggest
152 we go with RSA.
153 </opinion>
155 Location of the cryptokey:
156 --------------------------
157 If we require that a Gentoo developer has a primary key for that is used for
158 signing, we lose the ability to add web of trust to our system later.
160 Additionally, if the developer uses the singular primary key for a lot of
161 stuff, it is more vulnerable to attack.
163 <opinion>
164 Instead, the developer should create a subkey that is used for signing Gentoo
165 work only. They should not sign anything else with this, including their Gentoo
166 email.
168 They may have an additional subkey for signing their Gentoo email if they wish.
169 </opinion>
171 Q: What are the potential downsides to this?
172 A: There are some older keyservers out there that do not correctly deal with
173 subkeys - but this should not affect us as we are intending to distribute
174 public cryptokeys ourselves.
176 Choosing cryptokey expiry times:
177 --------------------------------
178 GnuPG and the OpenPGP standard in general allow you to change the expiry date
179 on a cryptokey, after it is created. With that in mind, what does it having an
180 expired cryptokey imply:
181 1. GnuPG will not use that cryptokey for new creation actions (sign/encrypt/certify).
182 2. GnuPG will correctly validate/decrypt anything signed/encrypted by that
183 cryptokey, provided that the data timestamp is older than the key expiry
184 timestamp.
186 #1 is a logical behavior.
187 #2 protects us when data hasn't changed for a long time - but we have to be
188 careful about accurate timestamps (evil can get in here).
190 Q: What do we actually gain from expiry times in encryption setups?
191 A: It would indicate to others which key to use.
193 Q: What do we actually gain from expiry times in data signing setups?
194 A: Marginal protection against attacks from large datasets that might allow
195 compromise of the key, but only by encouraging us to have multiple keys over
196 time. Is this really a concern? No, we aren't signing large amounts of data.
198 Q: Is there anything else we gain from expiry times?
199 A: Yes. If a practice of using medium-term expiry times, and updating them
200 regularly is undertaken, the keys provide an indication of who is still paying
201 attention.
203 <opinion>
204 For the last reason alone, expiry times are worthwhile, and I would like to
205 suggest that a period of 6 months is used.
206 </opinion>
208 Revocating of cryptokeys also has the same implications as an expired
209 cryptokey, with the exception that you cannot under a revocation.
211 Other validity elements:
212 ------------------------
213 Now we lead into some more complex areas. Beyond cryptokey expiry dates, there
214 are several other methods for key validity. Of primary importance to us are uid
215 signatures.
217 UID signatures:
218 ---------------
219 As I wrote last year, these may take several forms.
220 We are concerned with several properties that they may have:
222 Expiry dates of signatures:
223 Unlike expiry dates of cryptokeys, these may not be changed - by default, they
224 take on the expiry date of the certifying cryptokey, although a lower value may be
225 set. If you have an existing signature that has expired, you need to get your
226 uid signed again.
228 Revocation of signatures:
229 A signature may be revoked by the certifying cryptokey only.
230 (TODO: need to check that the same rules of validity apply here).
232 Trust markings:
233 This is not of immediate concern, but instead offers future options for the
234 very paranoid portion of our userbase. They can implement things like only
235 trusting a specific web-of-trust of developers.
237 Using UID signatures:
238 ---------------------
239 Q: How can we use signatures to our advantage, for the hybrid or complex schemes?
240 1. Take the master key as defined by the 'Simple' proposal.
241 2. Use it to create uid signatures to each trusted developer key.
242 3. In verifying, designate said master key as the top level of trust (this is
243 the same as the simple scheme), and verify all file signatures by developers
244 as you go along.
246 This schema is extensible to N master keys, by telling GnuPG that it
247 needs signatures from M masters before data is considered trusted.
249 Revoking keys:
250 --------------
251 <opinion>
252 When a developer leaves Gentoo, he should not revoke the subkey used to
253 sign (indeed, he may not be able to, think being hit by a bus).
254 Instead, any signatures made by a valid master key should be revoked.
255 This ensure control remains in the hands of the keymasters (infra, devrel,
256 whoever).
257 </opinion>
259 Summary:
260 -----------
261 This is a brief summary of the suggestions and choices above.
262 This summary outline is assuming a model such as the hybrid or complex
263 models.
265 - Each developer shall have a GnuPG key.
266 - Each developer key shall contain at least one uid, with name and Gentoo email
267 address of the developer.
268 - Each developer must create a secondary cryptokey with the following
269 parameters (designated as their Gentoo signing cryptokey):
270 Key Type: RSA
271 Key Length: 2048 or 4096
272 Expiry time: Set at 6 months out
273 Usage: Marked as signing only.
274 - Each developer shall regularly update the expiry time (GnuPG enforces
275 this) of the cryptokey, keeping it no further than 6 months ahead of
276 the present date, except where otherwise decided.
277 - Each developer should have a revocation certificate for their key, and
278 store two copies in a secure offline location (I suggest two CD-RWs,
279 of different brands, stored in separate locations, refreshed every 6
280 months, but floppy disks would work as well).
281 - Each developer will sign all of their commits with their Gentoo
282 signing cryptokey only. They should not sign anything else, nor use
283 other cryptokeys for signing Gentoo commits.
284 - (Optional, for those creating new keys only) a best practice would be
285 to have a primary key that is marked as certifying only.
287 (This part here needs more discussion, which may end up that N=1 is
288 valid).
289 - There will be N master keys.
290 - A master key will have a secondary cryptokey conforming to the same
291 requirements as the developer Gentoo signing cryptokey.
292 - A master key will certify all Gentoo developer keys on a regular
293 basis. This can be done on 4 month intervals safely, with once-off
294 events to sign keys of incoming developers, or other special cases.
295 - When a developer leaves, the certification on their key shall be
296 revoked.
297 - Both infra and the council should hold the revocation control for a
298 master key in some way so that cooperation is needed to actually revoke
299 a master key.
301 (For future stuff:)
302 For performing releases of Gentoo (releng), a designated key be used,
303 and be certified by the master key.
305 Outstanding points:
306 -------------------
307 - Discussion of how the keymaster(s) should operate to maintain the
308 keyring.
310 --
311 Robin Hugh Johnson
312 E-Mail : robbat2@g.o
313 GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85