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
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
|
\A{ppk} PPK file format
This appendix documents the file format used by PuTTY to store private
keys.
In this appendix, binary data structures are described using data type
representations such as \cq{uint32}, \cq{string} and \cq{mpint} as
used in the SSH protocol standards themselves. These are defined
authoritatively by
\W{https://www.rfc-editor.org/rfc/rfc4251#section-5}{RFC 4251 section 5},
\q{Data Type Representations Used in the SSH Protocols}.
\H{ppk-overview} Overview
A PPK file stores a private key, and the corresponding public key.
Both are contained in the same file.
The file format can be completely unencrypted, or it can encrypt the
private key. The \e{public} key is stored in cleartext in both cases.
(This enables PuTTY to send the public key to an SSH server to see
whether it will accept it, and not bother prompting for the passphrase
unless the server says yes.)
When the key file is encrypted, the encryption key is derived from a
passphrase. An encrypted PPK file is also tamper-proofed using a MAC
(authentication code), also derived from the same passphrase. The MAC
protects the encrypted private key data, but it also covers the
cleartext parts of the file. So you can't edit the public half of the
key without invalidating the MAC and causing the key file as a whole
to become useless.
This MAC protects the key file against active cryptographic attacks in
which the public half of a key pair is modified in a controlled way
that allows an attacker to deduce information about the private half
from the resulting corrupted signatures. Any attempt to do that to a
PPK file should be reliably caught by the MAC failing to validate.
(Such an attack would only be useful if the key file was stored in a
location where the attacker could modify it without also having full
access to the process that you type passphrases into. But that's not
impossible; for example, if your home directory was on a network file
server, then the file server's administrator could access the key file
but not processes on the client machine.)
The MAC also covers the \e{comment} on the key. This stops an attacker
from swapping keys with each other and editing the comments to
disguise the fact. As a consequence, PuTTYgen cannot edit the comment
on a key unless you decrypt the key with your passphrase first.
(The circumstances in which \e{that} attack would be useful are even
more restricted. One example might be that the different keys trigger
specific actions on the server you're connecting to and one of those
actions is more useful to the attacker than the other. But once you
have a MAC at all, it's no extra effort to make it cover as much as
possible, and usually sensible.)
\H{ppk-outer} Outer layer
The outer layer of a PPK file is text-based. The PuTTY tools will
always use LF line termination when writing PPK files, but will
tolerate CR+LF and CR-only on input.
The first few lines identify it as a PPK, and give some initial data
about what's stored in it and how. They look like this:
\c PuTTY-User-Key-File-version: algorithm-name
\e bbbbbbb bbbbbbbbbbbbbb
\c Encryption: encryption-type
\e bbbbbbbbbbbbbbb
\c Comment: key-comment-string
\e bbbbbbbbbbbbbbbbbb
\s{version} is a decimal number giving the version number of the file
format itself. The current file format version is 3.
\s{algorithm-name} is the SSH protocol identifier for the public key
algorithm that this key is used for (such as \cq{ssh-dss} or
\cq{ecdsa-sha2-nistp384}).
\s{encryption-type} indicates whether this key is stored encrypted,
and if so, by what method. Currently the only supported encryption
types are \cq{aes256-cbc} and \cq{none}.
\s{key-comment-string} is a free text field giving the comment. This
can contain any byte values other than 13 and 10 (CR and LF).
The next part of the file gives the public key. This is stored
unencrypted but base64-encoded
(\W{https://www.rfc-editor.org/rfc/rfc4648}{RFC 4648}), and is preceded
by a header line saying how many lines of base64 data are shown,
looking like this:
\c Public-Lines: number-of-lines
\e bbbbbbbbbbbbbbb
\c that many lines of base64 data
\e bbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
The base64-encoded data in this blob is formatted in exactly the same
way as an SSH public key sent over the wire in the SSH protocol
itself. That is also the same format as the base64 data stored in
OpenSSH's \c{authorized_keys} file, except that in a PPK file the
base64 data is split across multiple lines. But if you remove the
newlines from the middle of this section, the resulting base64 blob is
in the right format to go in an \c{authorized_keys} line.
If the key is encrypted (i.e. \s{encryption-type} is not \cq{none}),
then the next thing that appears is a sequence of lines specifying how
the keys for encrypting the file are to be derived from the
passphrase:
\c Key-Derivation: argon2-flavour
\e bbbbbbbbbbbbbb
\c Argon2-Memory: decimal-integer
\e bbbbbbbbbbbbbbb
\c Argon2-Passes: decimal-integer
\e bbbbbbbbbbbbbbb
\c Argon2-Parallelism: decimal-integer
\e bbbbbbbbbbbbbbb
\c Argon2-Salt: hex-string
\e bbbbbbbbbb
\s{argon2-flavour} is one of the identifiers \cq{Argon2d},
\cq{Argon2i} or \cq{Argon2id}, all describing variants of the Argon2
password-hashing function.
The three integer values are used as parameters for Argon2, which
allows you to configure the amount of memory used (in Kbyte), the number
of passes of the algorithm to run (to tune its running time), and the
degree of parallelism required by the hash function. The salt is
decoded into a sequence of binary bytes and used as an additional
input to Argon2. (It is chosen randomly when the key file is written,
so that a guessing attack can't be mounted in parallel against
multiple key files.)
The next part of the file gives the private key. This is
base64-encoded in the same way:
\c Private-Lines: number-of-lines
\e bbbbbbbbbbbbbbb
\c that many lines of base64 data
\e bbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
The binary data represented in this base64 blob may be encrypted,
depending on the \e{encryption-type} field in the key file header
shown above:
\b If \s{encryption-type} is \cq{none}, then this data is stored in
plain text.
\b If \s{encryption-type} is \cq{aes256-cbc}, then this data is
encrypted using AES, with a 256-bit key length, in the CBC cipher
mode. The key and initialisation vector are derived from the
passphrase: see \k{ppk-keys}.
\lcont{
In order to encrypt the private key data with AES, it must be a
multiple of 16 bytes (the AES cipher block length). This is achieved
by appending random padding to the data before encrypting it. When
decoding it after decryption, the random data can be ignored: the
internal structure of the data is enough to tell you when you've
reached the end of the meaningful part.
}
Unlike public keys, the binary encoding of private keys is not
specified at all in the SSH standards. See \k{ppk-privkeys} for
details of the private key format for each key type supported by
PuTTY.
The final thing in the key file is the MAC:
\c Private-MAC: hex-mac-data
\e bbbbbbbbbbbb
\s{hex-mac-data} is a hexadecimal-encoded value, 64 digits long (i.e.
32 bytes), generated using the HMAC-SHA-256 algorithm with the
following binary data as input:
\b \cw{string}: the \s{algorithm-name} header field.
\b \cw{string}: the \s{encryption-type} header field.
\b \cw{string}: the \s{key-comment-string} header field.
\b \cw{string}: the binary public key data, as decoded from the base64
lines after the \cq{Public-Lines} header.
\b \cw{string}: the plaintext of the binary private key data, as
decoded from the base64 lines after the \cq{Private-Lines} header. If
that data was stored encrypted, then the decrypted version of it is
used in this MAC preimage, \e{including} the random padding mentioned
above.
The MAC key is derived from the passphrase: see \k{ppk-keys}.
\H{ppk-privkeys} Private key encodings
This section describes the private key format for each key type
supported by PuTTY.
Because the PPK format also contains the public key (and both public
and private key are protected by the same MAC to ensure they can't be
made inconsistent), there is no need for the private key section of
the file to repeat data from the public section. So some of these
formats are very short.
In all cases, a decoding application can begin reading from the start
of the decrypted private key data, and know when it has read all that
it needs. This allows random padding after the meaningful data to be
safely ignored.
\S{ppk-privkey-rsa} RSA
RSA keys are stored using an \s{algorithm-name} of \cq{ssh-rsa}. (Keys
stored like this are also used by the updated RSA signature schemes
that use hashes other than SHA-1.)
The public key data has already provided the key modulus and the
public encoding exponent. The private data stores:
\b \cw{mpint}: the private decoding exponent of the key.
\b \cw{mpint}: one prime factor \e{p} of the key.
\b \cw{mpint}: the other prime factor \e{q} of the key. (RSA keys
stored in this format are expected to have exactly two prime factors.)
\b \cw{mpint}: the multiplicative inverse of \e{q} modulo \e{p}.
\S{ppk-privkey-dsa} DSA
DSA keys are stored using an \s{algorithm-name} of \cq{ssh-dss}.
The public key data has already provided the key parameters (the large
prime \e{p}, the small prime \e{q} and the group generator \e{g}), and
the public key \e{y}. The private key stores:
\b \cw{mpint}: the private key \e{x}, which is the discrete logarithm
of \e{y} in the group generated by \e{g} mod \e{p}.
\S{ppk-privkey-ecdsa} NIST elliptic-curve keys
\i{NIST} elliptic-curve keys are stored using one of the following
\s{algorithm-name} values, each corresponding to a different elliptic
curve and key size:
\b \cq{ecdsa-sha2-nistp256}
\b \cq{ecdsa-sha2-nistp384}
\b \cq{ecdsa-sha2-nistp521}
The public key data has already provided the public elliptic curve
point. The private key stores:
\b \cw{mpint}: the private exponent, which is the discrete log of the
public point.
\S{ppk-privkey-eddsa} EdDSA elliptic-curve keys (Ed25519 and Ed448)
EdDSA elliptic-curve keys are stored using one of the following
\s{algorithm-name} values, each corresponding to a different elliptic
curve and key size:
\b \cq{ssh-ed25519}
\b \cq{ssh-ed448}
The public key data has already provided the public elliptic curve
point. The private key stores:
\b \cw{mpint}: the private exponent, which is the discrete log of the
public point.
\H{ppk-keys} Key derivation
When a key file is encrypted, there are three pieces of key material
that need to be computed from the passphrase:
\b the key for the symmetric cipher used to encrypt the private key
\b the initialisation vector for that cipher encryption
\b the key for the MAC.
If \s{encryption-type} is \cq{aes256-cbc}, then the symmetric cipher
key is 32 bytes long, and the initialisation vector is 16 bytes (one
cipher block). The length of the MAC key is also chosen to be 32
bytes.
If \s{encryption-type} is \cq{none}, then all three of these pieces of
data have zero length. (The MAC is still generated and checked in the
key file format, but it has a zero-length key.)
If the amount of key material required is not zero, then the
passphrase is fed to the Argon2 key derivation function, in whichever
mode is described in the \cq{Key-Derivation} header in the key file,
with parameters derived from the various
\q{\cw{Argon2-}\e{Parameter}\cw{:}} headers.
(If the key is unencrypted, then all those headers are omitted, and
Argon2 is not run at all.)
Argon2 takes two extra string inputs in addition to the passphrase and
the salt: a secret key, and some \q{associated data}. In PPK's use of
Argon2, these are both set to the empty string.
The \q{tag length} parameter to Argon2 (i.e. the amount of data it is
asked to output) is set to the sum of the lengths of all of the data
items required, i.e. (cipher key length + IV length + MAC key length).
The output data is interpreted as the concatenation of the cipher key,
the IV and the MAC key, in that order.
So, for \cq{aes256-cbc}, the tag length will be 32+16+32\_=\_80 bytes;
of the 80 bytes of output data, the first 32 bytes are used as the
256-bit AES key, the next 16 as the CBC IV, and the final 32 bytes as
the HMAC-SHA-256 key.
\H{ppk-old} Older versions of the PPK format
\S{ppk-v2} Version 2
PPK version 2 was used by PuTTY 0.52 to 0.74 inclusive.
In PPK version 2, the MAC algorithm used was HMAC-SHA-1 (so the
\cw{Private-MAC} line contained only 40 hex digits).
The \cq{Key-Derivation:} header and all the
\q{\cw{Argon2-}\e{Parameter}\cw{:}} headers were absent. Instead of
using Argon2, the key material for encrypting the private blob was
derived from the passphrase in a totally different way, as follows.
The cipher key for \cq{aes256-cbc} was constructed by generating two
SHA-1 hashes, concatenating them, and taking the first 32 bytes of the
result. (So you'd get all 20 bytes of the first hash output, and the
first 12 of the second). Each hash preimage was as follows:
\b \cw{uint32}: a sequence number. This is 0 in the first hash, and 1
in the second. (The idea was to extend this mechanism to further
hashes by continuing to increment the sequence number, if future
changes required even longer keys.)
\b the passphrase, without any prefix length field.
In PPK v2, the CBC initialisation vector was all zeroes.
The MAC key was 20 bytes long, and was a single SHA-1 hash of the
following data:
\b the fixed string \cq{putty-private-key-file-mac-key}, without any
prefix length field.
\b the passphrase, without any prefix length field. (If the key is
stored unencrypted, the passphrase was taken to be the empty string
for these purposes.)
\S{ppk-v1} Version 1
PPK version 1 was a badly designed format, only used during initial
development, and not recommended for production use.
PPK version 1 was never used by a released version of PuTTY. It was
only emitted by some early development snapshots between version 0.51
(which did not support SSH-2 public keys at all) and 0.52 (which
already used version 2 of this file format). I \e{hope} there are no
PPK v1 files in use anywhere. But just in case, the old badly designed
format is documented here anyway.
In PPK version 1, the input to the MAC does not include any of the
header fields or the public key. It is simply the private key data
(still in plaintext and including random padding), all by itself
(without a wrapping \cw{string}).
PPK version 1 keys must therefore be rigorously validated after
loading, to ensure that the public and private parts of the key were
consistent with each other.
PPK version 1 only supported the RSA and DSA key types. For RSA, this
validation can be done using only the provided data (since the private
key blob contains enough information to reconstruct the public values
anyway). But for DSA, that isn't quite enough.
Hence, PPK version 1 DSA keys extended the private data so that
immediately after \e{x} was stored an extra value:
\b \cw{string}: a SHA-1 hash of the public key data, whose preimage
consists of
\lcont{
\b \cw{string}: the large prime \e{p}
\b \cw{string}: the small prime \e{q}
\b \cw{string}: the group generator \e{g}
}
The idea was that checking this hash would verify that the key
parameters had not been tampered with, and then the loading
application could directly verify that
\e{g}\cw{^}\e{x}\cw{\_=\_}\e{y}.
In an \e{unencrypted} version 1 key file, the MAC is replaced by a
plain SHA-1 hash of the private key data. This is indicated by the
\cq{Private-MAC:} header being replaced with \cq{Private-Hash:}
instead.
|