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
|
YAPET - Yet Another Password Encryption Tool 0.6
YAPET - Design
Rafael Ostertag
$Id: DESIGN.sgml.in 2904 2009-09-04 05:11:30Z rafi $
Copyright 2008, 2009 Rafael Ostertag <rafi@guengel.ch>
-------------------------------------------------------------------------------
Table of Contents
General
Master Password
Encryption Key
File Structure
Recognition String
Header
Password Records
Example
Security
References
General
YAPET stores passwords encrypted on disk. Passwords are kept in records with
additional information. A record is comprised by the following components:
Name
The name displayed in the Main Screen.
Host
The host on which the password is used.
Username
The user name the password is associated with.
Password
The password to protect.
Comment
A comment.
The encryption and hash functions used by YAPET are provided by the crypto(3)
library of ssl(3). YAPET does not provide them itself.
Master Password
YAPET uses a master password provided by the user to generate a key in order to
encrypt and decrypt the password records. The master password is not stored
permanently. It has to be entered when a file is opened or the screen is locked
in order to unlock it.
Encryption Key
The encryption key is generated by calculating a SHA1 hash of the master
password. MD5 is used to hash the SHA1 hash. Both hashes are concatenated.
Finally, RIPEMD-160 is used to generate a hash of the SHA1 and MD5 hashes. The
RIPEMD-160 hash is then appended to the SHA1 and MD5 hash, yielding a key of
448 bits. This key will be used for the Blowfish encryption algorithm in order
to encrypt and decrypt password records.
File Structure
A file created by YAPET has the following basic structure
1. Clear text recognition string
2. Clear text header length indicator (prefix)
3. Encrypted header
4. Clear text password record length indicator (prefix)
5. Encrypted password record
6. Clear text password record length indicator (prefix)
7. Encrypted password record
8. ?
The prefixes are stored in big endian order, regardless of the endianess of the
platform YAPET is running.
Recognition String
Each file created by YAPET starts with a unencrypted recognition string which
currently consists of the 8 bytes YAPET1.0 as depicted in Figure1,
?Recognition String?.
Figure1.Recognition String
+--------+--------+--------+--------+--------+--------+--------+--------+
| Y | A | P | E | T | 1 | . | 0 |
| 1 byte | 1 byte | 1 byte | 1 byte | 1 byte | 1 byte | 1 byte | 1 byte |
+--------+--------+--------+--------+--------+--------+--------+--------+
Header
After the recognition string a 4 byte unsigned integer which is stored in
big-endian order follows. This indicator is read to determine how many bytes to
read in order to get the encrypted header (Figure2, ?Encrypted Header?).
Figure2.Encrypted Header
+--------+--------+--------+--------+
| Length indicator in big-endian |
| order (4 bytes) |
+--------+--------+--------+--------+--...---+
| Encrypted header exactly as many bytes |
| indicated by the prefix |
+--------+--------+--------+--------+--...---+
Pre Version 0.6 Header
The decrypted header (Figure3, ?Pre Version 0.6 Decrypted Header?) is 25 bytes
in size. The first byte indicates the version of the file. The next 20 bytes
are used as control string. After decryption, the control string is compared to
the predefined clear text control string, in order to find out whether or not
the key used to decrypt was the same used to encrypt. The control string holds
all characters from A to Z.
Figure3.Pre Version 0.6 Decrypted Header
+--------+
|Version |
| 1 byte |
+--------+--------+--------+--...---+
| Control String |
| 20 bytes |
+--------+--------+--------+--...---+
| Time when the Password |
| was set (4 bytes) |
+--------+--------+--------+
The Version field holds the value 1 (YAPET::VERSION_1).
The length of the header is either 25 bytes on 32bit architectures, or 29 bytes
on 64bit architectures.
This is considered as design flaw, thus starting from YAPET 0.6, the version
0.6 header was introduced, providing a stable size across platforms (see the
section called ?Version 0.6 Header?).
Version 0.6 Header
The pre version 0.6 header was designed with the uneducated assumption that
time_t is always 4 bytes in size. This is not the case. Therefore, the version
0.6 header uses 64 bits for the password set field, regardless of the
architecture, as shown in Figure4, ?Version 0.6 Decrypted Header?. The Version
field will hold the value 2 (YAPET::VERSION_2).
Thus, the new header has always a size of 29 bytes, hence being stable across
platforms.
Figure4.Version 0.6 Decrypted Header
+--------+
|Version |
| 1 byte |
+--------+--------+--------+--------+--------+--------+--...---+
| Control String |
| 20 bytes |
+--------+--------+--------+--------+--------+--------+--...---+--------+
| Time when the Password was set (8 bytes) |
| |
+--------+--------+--------+--------+--------+--------+--------+--------+
YAPET 0.6 or later is still able to read pre version 0.6 headers in order to
maintain backwards compatibility with earlier releases. It will however write a
version 0.6 header upon password change.
YAPET 0.5 or earlier is able to read version 0.6 headers. If the master
password on a version 0.6 file is changed using YAPET 0.5 or earlier, it will
automatically become a pre version 0.6 file, and the restrictions for version
0.5 applies.
Table1, ?File Compatibility Matrix of YAPET 0.5 or earlier? lists the
compatibility between different processor architectures and YAPET 0.5.
The tests were conducted mainly on Linux boxes.
Table1.File Compatibility Matrix of YAPET 0.5 or earlier
+------------------------------------------------------------------------------+
| | File created |
| |-----------------------------------------------------|
| | Version 0.5 or earlier | Version 0.6 |
|YAPET running on |-------------------------+---------------------------|
| | Little | Big Endian |Little Endian| Big Endian |
| | Endian | | | |
| |------------+------------+-------------+-------------|
| |32bit|64bit |32bit|64bit |32bit |64bit |32bit |64bit |
|------------------------+-----+------+-----+------+------+------+------+------|
| | |ARM XScale | yes | yes | yes |yes^[a|yes^[a|yes^[a|yes^[a|yes^[a|
| | | | | | | ] | ] | ] | ] | ] |
| | |-----------+-----+------+-----+------+------+------+------+------|
| |32bit|i386 | yes | yes | yes |yes^[a|yes^[a|yes^[a|yes^[a|yes^[a|
| | | | | | | ] | ] | ] | ] | ] |
| | |-----------+-----+------+-----+------+------+------+------+------|
| | |MIPS | yes | yes | yes |yes^[a|yes^[a|yes^[a|yes^[a|yes^[a|
|Little| |Loongson | | | | ] | ] | ] | ] | ] |
| |-----+-----------+-----+------+-----+------+------+------+------+------|
|Endian| |AMD Opteron| no | yes | no |yes^[a|yes^[a|yes^[a|yes^[a|yes^[a|
| | | | | | | ] | ] | ] | ] | ] |
| | |-----------+-----+------+-----+------+------+------+------+------|
| |64bit|IA64 | no | yes | no |yes^[a|yes^[a|yes^[a|yes^[a|yes^[a|
| | | | | | | ] | ] | ] | ] | ] |
| | |-----------+-----+------+-----+------+------+------+------+------|
| | |Xeon | no | yes | no |yes^[a|yes^[a|yes^[a|yes^[a|yes^[a|
| | | | | | | ] | ] | ] | ] | ] |
|------+-----+-----------+-----+------+-----+------+------+------+------+------|
| | |PA-RISC | yes | yes | yes |yes^[a|yes^[a|yes^[a|yes^[a|yes^[a|
| | | | | | | ] | ] | ] | ] | ] |
| | |-----------+-----+------+-----+------+------+------+------+------|
| | |PowerPC G4 | yes | yes | yes |yes^[a|yes^[a|yes^[a|yes^[a|yes^[a|
| | | | | | | ] | ] | ] | ] | ] |
| |32bit|-----------+-----+------+-----+------+------+------+------+------|
| | |PowerPC G5 | yes | yes | yes |yes^[a|yes^[a|yes^[a|yes^[a|yes^[a|
|Big | | | | | | ] | ] | ] | ] | ] |
| | |-----------+-----+------+-----+------+------+------+------+------|
|Endian| |SPARC | yes | yes | yes |yes^[a|yes^[a|yes^[a|yes^[a|yes^[a|
| | | | | | | ] | ] | ] | ] | ] |
| |-----+-----------+-----+------+-----+------+------+------+------+------|
| | |PowerPC G5 | no |yes^[a| no | yes | yes | yes | yes | yes |
| | | | | ] | | | | | | |
| |64bit|-----------+-----+------+-----+------+------+------+------+------|
| | |SPARC | no |yes^[a| no | yes | yes | yes | yes | yes |
| | | | | ] | | | | | | |
|------------------------------------------------------------------------------|
|^[a] The password set field will be incorrectly read and displayed as Thu Jan |
|1 01:00:00 1970 in YAPET. |
+------------------------------------------------------------------------------+
Table1, ?File Compatibility Matrix of YAPET 0.5 or earlier? boils down to
Table2, ?Summary of File Compatibility Matrix of YAPET 0.5 or earlier?
Table2.Summary of File Compatibility Matrix of YAPET 0.5 or earlier
+-----------------------------------------------------------------------+
| | File created |
| |---------------------------------------------------|
| | Version 0.5 or earlier | Version 0.6 |
|YAPET running on |-------------------------+-------------------------|
| |Little Endian|Big Endian |Little Endian|Big Endian |
| |-------------+-----------+-------------+-----------|
| |32bit |64bit |32bit|64bit|32bit |64bit |32bit|64bit|
|-------------------+------+------+-----+-----+------+------+-----+-----|
|Little Endian 32bit| yes | yes | yes | yes | yes | yes | yes | yes |
|-------------------+------+------+-----+-----+------+------+-----+-----|
|Little Endian 64bit| no | yes | no | yes | yes | yes | yes | yes |
|-------------------+------+------+-----+-----+------+------+-----+-----|
|Big Endian 32bit | yes | yes | yes | yes | yes | yes | yes | yes |
|-------------------+------+------+-----+-----+------+------+-----+-----|
|Big Endian 64bit | no | yes | no | yes | yes | yes | yes | yes |
+-----------------------------------------------------------------------+
Password Records
Each encrypted password record is prefixed by a 4 byte unsigned integer which
is stored in big-endian order. That integer is used to indicate the length of
the following encrypted data chunk.
Figure5.Encrypted Password Record
+--------+--------+--------+--------+
| Length indicator in big-endian |
| order (4 bytes) |
+--------+--------+--------+--------+--...---+
| Encrypted password record of exactly as |
| many bytes as indicated by the prefix |
+--------+--------+--------+--------+--...---+
| Length indicator in big-endian |
| order (4 bytes) |
+--------+--------+--------+--------+--...---+
| Encrypted password record of exactly as |
| many bytes as indicated by the prefix |
+--------+--------+--------+--------+--...---+
[ . . . ]
Example
Putting this together, an encrypted file created by YAPET may look like this
Figure6.Encrypted File Example
+--------+--------+--------+--------+--------+--------+--------+--------+
| Y | A | P | E | T | 1 | . | 0 |
| 1 byte | 1 byte | 1 byte | 1 byte | 1 byte | 1 byte | 1 byte | 1 byte |
+--------+--------+--------+--------+--------+--------+--------+--------+
| Length indicator in big-endian |
| order (4 bytes) |
+--------+--------+--------+--------+--...---+
| Encrypted header exactly as many bytes |
| indicated by the prefix |
+--------+--------+--------+--------+--...---+
| Length indicator in big-endian |
| order (4 bytes) |
+--------+--------+--------+--------+--...---+
| Encrypted password record of exactly as |
| many bytes as indicated by the prefix |
+--------+--------+--------+--------+--...---+
| Length indicator in big-endian |
| order (4 bytes) |
+--------+--------+--------+--------+--...---+
| Encrypted password record of exactly as |
| many bytes as indicated by the prefix |
+--------+--------+--------+--------+--...---+
[ . . . ]
Security
Memory used for storing sensitive information is cleared by setting it to zero
upon de-allocation. This is default behavior of YAPET functions. However, YAPET
cannot alter the way functions provided by crypto(3) and curses(3X)
de-allocates memory. An attempt to make curses(3X) more secure is taken by
calling wclear(3X) before calling delwin(3X), in the hope that it clears the
memory associated with the curses window.
YAPET uses setrlimit(2) to suppress the creation of core dumps. It also sets up
signal handlers for SIGHUP, SIGINT, SIGQUIT, SIGTERM, and SIGKILL for doing a
proper cleanup and clearing of allocated memory.
Apart from memory clearing, YAPET locks the screen after ten minutes of
inactivity.
YAPET does not keep the password records decrypted in memory. It decrypts only
the name of the password record in order to show it to the user. Password
records are only decrypted for displaying and editing, when the user chooses to
open a record.
References
See also the code documentation that comes along with the source tarball of
YAPET.
|
