-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathuser.doc
387 lines (295 loc) · 16 KB
/
user.doc
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
Using Privtool
Most operations in Privtool are identical to the Sun mailtool, with the
exception that attachments are not supported, some buttons don't work
and some menu items are grayed out, and there is currently no graphical
properties window (all .privrc changes currently have to be made by
hand with a text editor). This file will simply describe the new
features.
1. Displaying messages
----------------------
When the scrolling list of messages is displayed in the Privtool window,
additional flags will appear on the left side. As well as the use of
'N' for a new message and 'U' for an unread message, the following are
used :
Second column:
's' - message is signed, but unverified.
'?' - message may or may not be signed.
'S' - message is signed, and has been succesfully verified.
'X' - message is signed, but has a bad signature.
Third column:
'E' - message is encrypted.
'D' - message has been successfully decrypted.
'P' - pseudonymous message from a nymserver.
When you double click on a message, it will be displayed in the display
window. Unlike the mailtool, the subject will be placed in the window
title, and the header will not be displayed. If the message is signed, then
signature information will be displayed in the small window at the foot
of the main display window.
If the message is encrypted, then Privtool will need your passphrase in
order to decrypt it. It may or may not actually ask you for it depending
on the security level chosen (see later for a description of security
levels).
To display the message header, press the 'header' button, and a seperate
header window will appear. The 'add key' button will be activated when
you receive a message that contains a PGP key, however at the moment it
does not do anything. In the final release it will automatically scan the
message for new keys and add them to your pubring file.
We provide limited support for uuencoded attachments. If the message is
a uuencoded file, then a 'Save Attachment' button will appear on the
display window. Pressing this button will save the file in the current
directory. This will normally be your home directory, but using some of
the Xview window menus can cause the program to change directory in a
manner over which we have no control. If the message contains multiple
attachments then only the first will be saved. I hope to one day provide
real attachment support, but Linux does not currently support Xview
drag-and-drop correctly.
2. Sending messages
-------------------
Five new check-boxes appear on the compose window. These are in turn,
'Sign' - to sign the outgoing message, 'Encrypt' - to encrypt the
outgoing message, 'Log' - to log the outgoing message (in encrypted
form if encrypted), 'Remail' - to send messages through the cypherpunks
anonymous remailers, and 'Raw' - to log outgoing encrypted or signed
messages in raw ASCII form. You can set the defaults for these in the
.privrc file.
When signing, Privtool may have to ask you for your passphrase, depending
on the security level chosen.
If you select the 'Remail' box, then Privtool will run the Mixmaster
anonymous remailer client program, randomly selecting up to six
remailers to send the message through (this can be increased by changing
the MAXMIX definition in gui.c). For this to work, you must have a
copy of Mixmaster, and have set up the Makefile appropriately when
compiling Privtool. Privtool selects the remailers from the type2.list
file, and only uses the first one hundred if more that one hundred
are available.
Optionally you may give Privtool reliability information for the
remailers, in which case it will only use remailers which are at
least 75% reliable and will preferentially use the more reliable
remailers (remailers not included on this list are assumed to be
90% reliable). To do this you will need to save a copy of Raph's mixmaster
reliability page to MIXPATH/reliability. A simple way to do this is to
use your Web browser to go to:
http://kiwi.cs.berkeley.edu/mixmaster-list.html
and save this page. You do not need to strip out the HTML or headers and
footers. Future versions of Privtool will extract this information
automatically.
3. Security Levels
------------------
Privtool supports four security levels :
Level 1 - read passphrase from PGPPASS
Level 2 - ask for passphrase when first required and store it in
memory until it is cleared either by time delay or user
selection.
Level 3 - ask for passphrase every time it is needed and destroy
it as soon as possible.
Level 4 - currently identical to level 3, in the final release it
will delete the decrypted text of each message when you
close the display window.
4. Privrc options
-----------------
A whole bunch of new options have been added to the .privrc file. A sample
is given in the file 'Privrc.test', which may explain the system better
than I have here.
In order to retain compatibility with mail and mailtool, all Privtool-specific
options are given as comments in the .privrc file, prior to the 'PLEASE MAKE
ALL CHANGES ABOVE THESE 2 LINES' line inserted by mailtool. Privtool
understands most of the mailtool options (specifically alias, etc), and
its options are given by lines starting with '#@'.
#@pgpkey
This allows you to specify a mapping from a mail address to a pgp key. You
MUST specify such a mapping for your own id in order to make signatures and
encrypted logging work.
#@killu
This specifies a user id to ignore mail from. The mail from this user will
be added to the deleted message list, and can be undeleted.
@#kills
This specifies part or all of a subject line to ignore. Any mail whose
subject line contains the specified string (case-sensitive) will be
deleted and added to the end of the deleted message list.
#@testinterval
If retrieveinterval is set to specify the time periods at which Privtool will
check for new mail in your mailbox, then you can also set testinterval to
a time in seconds. Each time Privtool checks for mail, it will also check that
a message has been displayed in the previous 'testinterval' seconds. If not,
then it will destroy your passphrase, regardless of the security level you
are running at.
#@security
This specifies the security level to use (see above). Level 2 or Level 3 are
recommended.
#@cfeed
This allows you to specify an address from which you may receive an encrypted
mailing list feed. Each time an encypted message from this address is
decrypted, Privtool will scan the decrypted message to see if it begins with a
valid mail header (Received: from, etc). If so, then the original message will
be junked, and the decrypted message will be put into the list in its
place. Privtool will then decrypt/verify the new message if that is
appropriate.
And yes, this *does* work with the encrypted Cypherpunks mailing list
feed.
#@pseudonym
This allows you to specify an additional identity that you wish to use
when using Privtool. The list of identities will appear on the Nym
menu, and can be selected from the menu. After the selection, if you
use the compose window then messages will be sent as if they came from
that pseudonym (e.g. signed with the nym's key). If you use any pseudonym
other than your real user id, then the compose window will default to
sending messages through remailers.
#@defnym
This allows you to specify the default pseudonym to use, otherwise
Privtool will default to your real identity.
There are also a number of options that can be specified using the
'set' command in the .privrc file.
set defaultusefrom
This will default to using the from: line rather than the reply-to: line
in the mail header if one is specified. Otherwise Privtool will pop up
a panel to ask you to specify which address to use. This option takes
precedence over defaultusereplyto if both are specified.
set defaultusereplyto
This will default to using the reply-to: line rather than the from: line
in the mail header if one is specified. Otherwise Privtool will pop up
a panel to ask you to specify which address to use.
set folder='directory'
This will use the specified directory as the root of your mail files
tree. If you specify a mail file with '+name', then it will look for
the file in 'directory/name', and the mail files menu will always look
in the specified directory. If the path given begins with a / it is
assumed to be an absolute pathname, otherwise it is assumed to be
relative to $HOME.
set log-raw
This will enable raw logging as the default when sending messages.
set nobeepbadsig
Don't beep if the signature is bad.
set nodefaultencrypt
This will disable the default PGP-encryption of messages. You will have to
check the 'Encrypt' box manually to encrypt outgoing messages.
set nodefaultremail
This will disable the default remailing of messages sent by anything other
than the default pseudonym. You will have to check the 'Remail' box manually
to remail outgoing messages.
set nodefaultsign
This will disable the default PGP-signing of messages. You will have to
check the 'Sign' box manually to sign outgoing messages.
set domain='domainname'
If the domain name of the machine you are using is different to the
domain name for your email address, then you can specify the correct
domain name to use in outgoing messages.
set replyto='reply-address'
You may also specify the reply-address to use in the Reply-To: line of
outgoing messages. Most mail programs will detect this line and use it
as the destination for replies.
set sigfile='sig-file'
This specifies the name of the signature file to use. If specified then the
file will be appended to every message that you send. The filename is assumed
to be relative to the user's home directory unless it begins with a '/'.
set organization='organization'
This specifies the organization name to include in the header of outgoing
messages, if any.
5. Keyring access
-----------------
Normally privtool will read the public keys to use out of PGP's pubring.pgp
file, however if it is compiled with PGP Tools then it will first look for
the file $PGPPATH/smallring.pgp, and if this exists it will search for the
key in this file before checking the main one. If you have a large pubring.pgp
file, then you can store commonly used keys in smallring.pgp to reduce
the time required to access them.
Currently there is a limited support for retaining secret keys on a floppy
disk as a 'physical token'. This works on SunOS and Linux, with some
limitations. In particular it requires global read access to /dev/fd0, which
you may prefer to avoid; this will also allow other users on your machine
to read the secret key file from the disk.
If you would like to try it, take the following steps:
1. Find a blank floppy disk.
2. Low-level format the disk, using 'fdformat /dev/fd0'
3. Copy your secret keyring onto the disk, using 'cp secring.pgp
/dev/fd0'
You now have your secret key on the disk. Whenever Privtool requires the
key it will open the disk device and read from the disk rather than the
normal PGP secret key file. If you remove the disk then noone else will
be able to use your secret key even if you accidentally leave your desk
and forget to erase your passphrase. On machines with software eject you
will find a new 'Eject Floppy' option on the Edit button menu.
The problem at the moment is that PGP keyring files do not include an
'end of file' marker. Consequently if Privtool is looking for a key
which does not exist in the secret key file it will scan the entire
floppy disk before aborting. This can take a long time!
6. ToDo
-------
Features to be added :
Hopefully a Motif or Xt replacement for x.c.
Improved security in general.
Create color icon.
See README.1ST for other information on current bugs and intended fixes.
7. Security concerns
--------------------
I'm not sure how good the random number generation is at the moment, it
essentially keeps an array of user interface interaction times and
passes it to the PGP Tools random number functions (the old array will
be stored as 'privseed.bin' in your $PGPPATH). When the contents of
privseed.bin are loaded, they are first IDEA-encrypted using a key
based on the current time and process id. It will then be XOR-ed with
the contents of PGP's randseed.bin file if you have one available.
Optionally, if you have an audio device with no microphone, it can
be used as a source of physical random data. Privtool will read 16
512-byte blocks from /dev/audio, and take the MD5 of each. These will
then be concatenated into a 256-byte block and XOR-ed with the data
read from, or written to, the privseed.bin file. On Linux we also read
the contents of various system files such as /proc/interrupts and XOR
in the MD5 of these files.
This guarantees that there is at least a small amount of randomness
in generated keys, even if an attacker has a copy of your privseed.bin
file (of course, the amount of randomness depends on whether the attacker
can access your machine to find the process id or startup time). After
this, each time a user interface event occurs (e.g. pressing a button),
the low-order byte of the time in seconds and the high-order byte of
the time in milliseconds are XOR-ed together, and then XOR-ed into the
privseed array, along with other sources of non-deterministic data such
as MD5 hashes of messages read.
This should ensure that the privseed array is soon filled with
non-deterministically random data, which is used to generate a random
128-bit key for encryption. In addition, this key is XOR-ed with the
MD5 hash of the message you are sending before it is used, and as a
result an attacker would need to know the internal state of the
random number routine, the contents of the privseed array, *and*
the MD5 of the message in order to crack the key. Clearly, if the
attacker knows the MD5 of the message, they probably know the message
itself and don't need the key.
If you have a /dev/random random number generator and compile in
support then the generated key will be XOR-ed with 128 bits read from
/dev/random. Otherwise it will be XOR-ed with 128 bits from the stack, which
may or may not give another couple of random bits. IDEA has some weak keys,
and although they are very rare we check for them and create a new key if
we find one.
Finally, on exit the privseed array is again IDEA-encrypted to prevent
state information leaking, and XOR-ed with the old contents of the
privseed.bin file. The modification time of the file is reset to zero
in order to prevent an attacker using it to determine the key that was
used to encrypt the data prior to the XOR. Even if they could do this
it would not neccesarily make it possible to recreate the random number
sequence, as the internal state of PGP Tools' random number generator
is not saved.
I suspect that this is pretty secure, however I'd appreciate any
comments from people who have analysed the code and found weaknesses.
Another major concern is that if you mail out an encrypted message to
several people it will be encrypted to all those people rather than
encrypted to each individually, hence any recipient will be able to
get the entire list of recipients by looking at the PGP headers. In
addition, when you encrypt a message to send and also log it in
'cooked' (i.e. non-raw) fashion, the message that is sent and logged
will also be encrypted to you, so any recipient will be able to determine
that you are the sender. This is not so much of a problem when you
are not using remailers, but will be fixed for the PGP Tools version
of Privtool in the final release.
Currently there is a bug in Mixmaster's handling of stdin that forces
Privtool to save messages to a temporary file in the Mixmaster directory
before it sends them out. This can be disabled by defining MIXMASTER_STDIN
when compiling, if you aquire a later version of Mixmaster which handles
stdin correctly.
Finally, the XView toolkit has a tendency to dump displayed messages in
ASCII files in /tmp where other people may be able to read them. There
doesn't appear to be much I can do about this without rewriting XView.
8. Other
--------
This should be all you need to know, if you have any other questions,
bug reports, bug fixes, suggestions for new features, etc, please mail
them to [email protected].
Mark