]>
Commit | Line | Data |
---|---|---|
dbfe3c19 DK |
1 | /* |
2 | * Copyright (c) 2008, Dave Korn. | |
3 | * | |
4 | * This program is free software; you can redistribute it and/or modify | |
5 | * it under the terms of the GNU General Public License as published by | |
6 | * the Free Software Foundation; either version 2 of the License, or | |
7 | * (at your option) any later version. | |
8 | * | |
9 | * A copy of the GNU General Public License can be found at | |
10 | * http://www.gnu.org/ | |
11 | * | |
12 | * Written by Dave Korn <dave.korn.cygwin@gmail.com> | |
13 | * | |
14 | */ | |
15 | ||
16 | #ifndef SETUP_CRYPTO_H | |
17 | #define SETUP_CRYPTO_H | |
18 | ||
19 | /* This module uses libgcrypt functionality to verify signatures | |
20 | * on downloaded setup.ini or setup.bz2 files. | |
21 | */ | |
22 | ||
23 | /* for HWND */ | |
24 | #include "win32.h" | |
25 | class io_stream; | |
26 | ||
27 | /* This is currently the only public API exported by the module; it | |
28 | takes the contents of setup.ini or setup.bz2 in one (memory-based, | |
29 | for preference) io_stream, and the contents of the related signature | |
30 | file in another. It is called from ini.cc/do_remote_ini() and returns | |
31 | true if the signature verified OK; if it returns false, you MUST NOT | |
32 | use the failed ini file - doubly so if it's a compressed stream! */ | |
33 | extern bool verify_ini_file_sig (io_stream *ini_file, io_stream *ini_sig_file, HWND owner); | |
34 | ||
35 | /* | |
36 | 5.2.2. Version 3 Signature Packet Format | |
37 | ||
38 | The body of a version 3 Signature Packet contains: | |
39 | ||
40 | - One-octet version number (3). | |
41 | ||
42 | - One-octet length of following hashed material. MUST be 5. | |
43 | ||
44 | - One-octet signature type. | |
45 | ||
46 | - Four-octet creation time. | |
47 | ||
48 | - Eight-octet Key ID of signer. | |
49 | ||
50 | - One-octet public-key algorithm. | |
51 | ||
52 | - One-octet hash algorithm. | |
53 | ||
54 | - Two-octet field holding left 16 bits of signed hash value. | |
55 | ||
56 | - One or more multiprecision integers comprising the signature. | |
57 | This portion is algorithm specific, as described below. | |
58 | ||
59 | The concatenation of the data to be signed, the signature type, and | |
60 | creation time from the Signature packet (5 additional octets) is | |
61 | hashed. The resulting hash value is used in the signature algorithm. | |
62 | The high 16 bits (first two octets) of the hash are included in the | |
63 | Signature packet to provide a quick test to reject some invalid | |
64 | signatures. | |
65 | ||
66 | Algorithm-Specific Fields for RSA signatures: | |
67 | ||
68 | - multiprecision integer (MPI) of RSA signature value m**d mod n. | |
69 | ||
70 | Algorithm-Specific Fields for DSA signatures: | |
71 | ||
72 | - MPI of DSA value r. | |
73 | ||
74 | - MPI of DSA value s. | |
75 | ||
76 | The signature calculation is based on a hash of the signed data, as | |
77 | described above. The details of the calculation are different for | |
78 | DSA signatures than for RSA signatures. | |
79 | ||
80 | With RSA signatures, the hash value is encoded using PKCS#1 encoding | |
81 | type EMSA-PKCS1-v1_5 as described in Section 9.2 of RFC 3447. This | |
82 | requires inserting the hash value as an octet string into an ASN.1 | |
83 | structure. The object identifier for the type of hash being used is | |
84 | included in the structure. The hexadecimal representations for the | |
85 | currently defined hash algorithms are as follows: | |
86 | ||
87 | - MD5: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05 | |
88 | ||
89 | - RIPEMD-160: 0x2B, 0x24, 0x03, 0x02, 0x01 | |
90 | ||
91 | - SHA-1: 0x2B, 0x0E, 0x03, 0x02, 0x1A | |
92 | ||
93 | - SHA224: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04 | |
94 | ||
95 | - SHA256: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01 | |
96 | ||
97 | - SHA384: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02 | |
98 | ||
99 | - SHA512: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03 | |
100 | ||
101 | The ASN.1 Object Identifiers (OIDs) are as follows: | |
102 | ||
103 | - MD5: 1.2.840.113549.2.5 | |
104 | ||
105 | - RIPEMD-160: 1.3.36.3.2.1 | |
106 | ||
107 | - SHA-1: 1.3.14.3.2.26 | |
108 | ||
109 | - SHA224: 2.16.840.1.101.3.4.2.4 | |
110 | ||
111 | - SHA256: 2.16.840.1.101.3.4.2.1 | |
112 | ||
113 | - SHA384: 2.16.840.1.101.3.4.2.2 | |
114 | ||
115 | - SHA512: 2.16.840.1.101.3.4.2.3 | |
116 | ||
117 | The full hash prefixes for these are as follows: | |
118 | ||
119 | MD5: 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86, | |
120 | 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, 0x05, 0x00, | |
121 | 0x04, 0x10 | |
122 | ||
123 | RIPEMD-160: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x24, | |
124 | 0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14 | |
125 | ||
126 | SHA-1: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0E, | |
127 | 0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14 | |
128 | ||
129 | SHA224: 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, | |
130 | 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04, 0x05, | |
131 | 0x00, 0x04, 0x1C | |
132 | ||
133 | SHA256: 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, | |
134 | 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05, | |
135 | 0x00, 0x04, 0x20 | |
136 | ||
137 | SHA384: 0x30, 0x41, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, | |
138 | 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, 0x05, | |
139 | 0x00, 0x04, 0x30 | |
140 | ||
141 | SHA512: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, | |
142 | 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, 0x05, | |
143 | 0x00, 0x04, 0x40 | |
144 | ||
145 | DSA signatures MUST use hashes that are equal in size to the number | |
146 | of bits of q, the group generated by the DSA key's generator value. | |
147 | ||
148 | If the output size of the chosen hash is larger than the number of | |
149 | bits of q, the hash result is truncated to fit by taking the number | |
150 | of leftmost bits equal to the number of bits of q. This (possibly | |
151 | truncated) hash function result is treated as a number and used | |
152 | directly in the DSA signature algorithm. | |
153 | ||
154 | ||
155 | 5.2.3. Version 4 Signature Packet Format | |
156 | ||
157 | The body of a version 4 Signature packet contains: | |
158 | ||
159 | - One-octet version number (4). | |
160 | ||
161 | - One-octet signature type. | |
162 | ||
163 | - One-octet public-key algorithm. | |
164 | ||
165 | - One-octet hash algorithm. | |
166 | ||
167 | - Two-octet scalar octet count for following hashed subpacket data. | |
168 | Note that this is the length in octets of all of the hashed | |
169 | subpackets; a pointer incremented by this number will skip over | |
170 | the hashed subpackets. | |
171 | ||
172 | - Hashed subpacket data set (zero or more subpackets). | |
173 | ||
174 | - Two-octet scalar octet count for the following unhashed subpacket | |
175 | data. Note that this is the length in octets of all of the | |
176 | unhashed subpackets; a pointer incremented by this number will | |
177 | skip over the unhashed subpackets. | |
178 | ||
179 | - Unhashed subpacket data set (zero or more subpackets). | |
180 | ||
181 | - Two-octet field holding the left 16 bits of the signed hash | |
182 | value. | |
183 | ||
184 | - One or more multiprecision integers comprising the signature. | |
185 | This portion is algorithm specific, as described above. | |
186 | ||
187 | The concatenation of the data being signed and the signature data | |
188 | from the version number through the hashed subpacket data (inclusive) | |
189 | is hashed. The resulting hash value is what is signed. The left 16 | |
190 | bits of the hash are included in the Signature packet to provide a | |
191 | quick test to reject some invalid signatures. | |
192 | ||
193 | There are two fields consisting of Signature subpackets. The first | |
194 | field is hashed with the rest of the signature data, while the second | |
195 | is unhashed. The second set of subpackets is not cryptographically | |
196 | protected by the signature and should include only advisory | |
197 | information. | |
198 | ||
199 | The algorithms for converting the hash function result to a signature | |
200 | are described in a section below. | |
201 | ||
202 | ||
203 | 5.2.4. Computing Signatures | |
204 | ||
205 | All signatures are formed by producing a hash over the signature | |
206 | data, and then using the resulting hash in the signature algorithm. | |
207 | ||
208 | For binary document signatures (type 0x00), the document data is | |
209 | hashed directly. For text document signatures (type 0x01), the | |
210 | document is canonicalized by converting line endings to <CR><LF>, | |
211 | and the resulting data is hashed. | |
212 | ||
213 | When a signature is made over a key, the hash data starts with the | |
214 | octet 0x99, [ ... ] | |
215 | ||
216 | A certification signature (type 0x10 through 0x13) [ ... ] | |
217 | ||
218 | When a signature is made over a Signature packet (type 0x50), [ ... ] | |
219 | ||
220 | Once the data body is hashed, then a trailer is hashed. A V3 | |
221 | signature hashes five octets of the packet body, starting from the | |
222 | signature type field. This data is the signature type, followed by | |
223 | the four-octet signature time. A V4 signature hashes the packet body | |
224 | starting from its first field, the version number, through the end | |
225 | of the hashed subpacket data. Thus, the fields hashed are the | |
226 | signature version, the signature type, the public-key algorithm, the | |
227 | hash algorithm, the hashed subpacket length, and the hashed | |
228 | subpacket body. | |
229 | ||
230 | V4 signatures also hash in a final trailer of six octets: the | |
231 | version of the Signature packet, i.e., 0x04; 0xFF; and a four-octet, | |
232 | big-endian number that is the length of the hashed data from the | |
233 | Signature packet (note that this number does not include these final | |
234 | six octets). | |
235 | ||
236 | After all this has been hashed in a single hash context, the | |
237 | resulting hash field is used in the signature algorithm and placed | |
238 | at the end of the Signature packet. | |
239 | ||
240 | */ | |
241 | ||
242 | #define RFC4880_SIGV3_HASHED_SIZE 5 | |
243 | #define RFC4880_SIGV4_HASHED_OVERHEAD 6 | |
244 | ||
245 | ||
246 | /* | |
247 | 5.5. Key Material Packet | |
248 | ||
249 | A key material packet contains all the information about a public or | |
250 | private key. There are four variants of this packet type, and two | |
251 | major versions. Consequently, this section is complex. | |
252 | ||
253 | 5.5.1. Key Packet Variants | |
254 | ||
255 | 5.5.1.1. Public-Key Packet (Tag 6) | |
256 | ||
257 | A Public-Key packet starts a series of packets that forms an OpenPGP | |
258 | key (sometimes called an OpenPGP certificate). | |
259 | ||
260 | 5.5.1.2. Public-Subkey Packet (Tag 14) | |
261 | 5.5.1.3. Secret-Key Packet (Tag 5) | |
262 | 5.5.1.4. Secret-Subkey Packet (Tag 7) | |
263 | ||
264 | 5.5.2. Public-Key Packet Formats | |
265 | ||
266 | The version 4 format is similar to the version 3 format except for | |
267 | the absence of a validity period. This has been moved to the | |
268 | Signature packet. In addition, fingerprints of version 4 keys are | |
269 | calculated differently from version 3 keys, as described in the | |
270 | section "Enhanced Key Formats". | |
271 | ||
272 | A version 4 packet contains: | |
273 | ||
274 | - A one-octet version number (4). | |
275 | ||
276 | - A four-octet number denoting the time that the key was created. | |
277 | ||
278 | - A one-octet number denoting the public-key algorithm of this key. | |
279 | ||
280 | - A series of multiprecision integers comprising the key material. | |
281 | This algorithm-specific portion is: | |
282 | ||
283 | Algorithm-Specific Fields for RSA public keys: | |
284 | ||
285 | - multiprecision integer (MPI) of RSA public modulus n; | |
286 | ||
287 | - MPI of RSA public encryption exponent e. | |
288 | ||
289 | Algorithm-Specific Fields for DSA public keys: | |
290 | ||
291 | - MPI of DSA prime p; | |
292 | ||
293 | - MPI of DSA group order q (q is a prime divisor of p-1); | |
294 | ||
295 | - MPI of DSA group generator g; | |
296 | ||
297 | - MPI of DSA public-key value y (= g**x mod p where x | |
298 | is secret). | |
299 | ||
300 | Algorithm-Specific Fields for Elgamal public keys: | |
301 | ||
302 | - MPI of Elgamal prime p; | |
303 | ||
304 | - MPI of Elgamal group generator g; | |
305 | ||
306 | - MPI of Elgamal public key value y (= g**x mod p where x | |
307 | is secret). | |
308 | ||
309 | */ | |
310 | ||
311 | // Big enough to dump the coefficients of a DSA | |
312 | // signing key of any reasonable size in ASCII | |
313 | // s-expr representation. | |
314 | #define GPG_KEY_SEXPR_BUF_SIZE (8192) | |
315 | ||
316 | // As long as you respect this maximum coefficient size. | |
317 | #define GPG_KEY_MAX_COEFF_SIZE (8192) | |
318 | ||
319 | #endif /* SETUP_CRYPTO_H */ |