Newsgroups: alt.security.pgp
Path: gmd.de!xlink.net!math.fu-berlin.de!news.rrz.uni-hamburg.de!
rzsun2.informatik.uni-hamburg.de!bontchev
From: bont...@news.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Suggestions for improvements of PGP
Message-ID: <CEw8Cx.MnD@informatik.uni-hamburg.de>
Sender: ne...@informatik.uni-hamburg.de (Mr. News)
Organization: University of Hamburg, Germany
X-Newsreader: TIN [version 1.1 PL9]
Date: Thu, 14 Oct 1993 15:29:18 GMT
Lines: 7
--
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN
< PGP 2.3 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bont...@fbihh.informatik.uni-hamburg.de 22527 Hamburg, Germany
Newsgroups: alt.security.pgp
Path: gmd.de!xlink.net!math.fu-berlin.de!news.dfn.de!news.dkrz.de!
rzsun2.informatik.uni-hamburg.de!bontchev
From: bont...@news.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Re: Suggestions for improvements of PGP
Message-ID: <CEwBuF.GG@informatik.uni-hamburg.de>
Sender: ne...@informatik.uni-hamburg.de (Mr. News)
Organization: University of Hamburg, Germany
X-Newsreader: TIN [version 1.1 PL9]
References: <CEw8Cx.MnD@informatik.uni-hamburg.de>
Date: Thu, 14 Oct 1993 16:44:37 GMT
Lines: 214
Hmm, I guess the mailer goofed up something. OK, second attempt.
Hello, everybody!
I have collected several suggestions to improve PGP, as well as some
bug reports. As far as I understand, a new version of PGP (3.0) is
under development, so I decided to post them here, in a hope that they
will be useful to the developers.
Several of the suggestions have been debated over - whether it is
really useful to include them. It is not my intention to restart the
debates - they are included here only for -consideration-. After all,
it is the developers who decide. I just tried to be helpful by
collecting in one place everything that has been proposed.
If you can think of other suggestions for improvements, please post.
However, if you intend to only post an objection or start a discussion
about some of the suggestions, please at least change the Subject:
line. Thanks for your cooperation and intelligence.
Regards,
Vesselin
A) Suggestions for improvements
1. PGP shouldn't make a copy (.bak) of the keyring, unless it is
certain that some modifications will be applied on it. For instance,
the copy should be made not directly after a positive reply to the
question whether I want to add new keys to the keyring, but only after
it is determined that there are new keys and the user has answered
positively to the question whther the first of them has to be added to
the keyring.
2. Add the capability to issue signature revokation certificates. A
signature revokation certificate should be issuable only by the person
who has issued the signature and should be valid only for a particular
key - the one that has been signed.
3. Add the capability to issue userID revokation certificates. Again,
this should be doable only by the user who has issued the particular
user ID.
4. If a key revokation certificate is added to a keyring, on the next
"pgp -kc" command, PGP should remove all signatures to other keys, if
those signatures have been generated by the revoked key.
5. It should be possible to extract a whole "web of trust" tree of
keys from a particular keyring. That is, there should be a way to
extract a particular public key, the public keys of all persons who
have signed this public key, the public keys of the people who have
signed their public keys and so on.
6. During encryption ("pgp -e") it should be possible to specify a
different public keyring from the command line (with a commant-line
option) - just as it is possible to do that during the key management
commands ("pgp -k").
7. Modify the signal() syscalls so that if they are ignored on entry,
pgp leaves them ignored. This allows pgp to run as a background
process under Unix without being interrupted if someone hits DEL from
the foreground. Here is how you do this; in file pgp.c:
970a971,973
> #ifdef UNIX
> if(signal(SIGINT, SIG_IGN) != SIG_IGN)
> #endif /* UNIX */
973,974c976,979
< signal(SIGHUP,breakHandler);
< signal(SIGQUIT,breakHandler);
---
> if(signal(SIGHUP, SIG_IGN) != SIG_IGN)
> signal(SIGHUP,breakHandler);
> if(signal(SIGQUIT, SIG_IGN) != SIG_IGN)
> signal(SIGQUIT,breakHandler);
8. It should be possible to enter more than one recepient when PGP
asks interactively for receient of the message.
9. Implement an "alias" feature. For instance, a file, called
ALIASES.PGP could contain definition of aliases and lists of userIDs
(or keyIDs) the alias replaces. For instance, if we have
mygroup=Joe User, smith*, 0x123456
then a command
pgp -seat message.txt mygroup
should be equivalent to the command
pgp -seat message.txt "joe user" smith 0x123456
10. Distribute the available language modules (ALL of them that are
mentioned in the documentation; not only the Spanish and French
modules) in a separate archive (i.e., one separate archive for
each of the following: sources, executables, documentation,
language modules).
11. When using -kv, the "<n> key(s) examined" phrase is misleading -
*all* the keys are examined, but only <n> key(s) have been found which
match. The message must be changed to "<x> key(s) examined, <y>
matching keys found".
12. When checking a detached signature, the phrase `Please enter
filename of text that signature applies to:' is also badly worded as
detached signatures are often used with executables or archives (PGP
itself is a case in point). I suggest that `of text' be removed.
13. Given that user IDs cannot be modified, only added or deleted
(and rightly so), then "Do you want to change your user ID (y/N)?"
should be "Do you want to add a new user ID (y/N)".
14. It should be possible to conceal the fact that some message is
PGP-encrypted. There should be an option, which causes the output to
be without the standard headers. If an attempt is made to decrypt the
message with the wrong key, it should decrypt to garbage.
15. When PGP is unable to decrypt the message, using the available
secret keys, it must just say so and not display the userID of the
user that will be able to decrypt the message.
16. If EncryptToSelf is set to ON, PGP should use the userID of the
first available key in the secret keyring, unless the MyName variable
is set in the config file.
17. Add the optional ability to use triple-DES for secret-key
encryption (instead of IDEA). IDEA should still be the default.
18. There should be a possibility to use uuencoding as an alternative
binary-to-ASCII encoding.
19. Update the programs in the contrib directory - many of them have newer
versions. (BTW, the latest versions that I have collected can be found
as ftp.informatik.uni-hamburg.de:/pub/virus/misc/contrib.zip.)
20. Add the ability to extract/delete/sign/etc. more than one key at once
in batch mode.
21. Add the ability to specify the input, output file and the public and
secret keyrings from the command line.
22. Add the ability to list the keys in the public keyring sorted by some
field(s) - user ID, key ID, size, date.
23. Include an IDEA assembler implementation for the MS-DOS version, I
mean, one that is compiled by the makefile; not just the unfinished
implementation in the contrib directory.
24. When wiping a file, don't use 0 or any other constant - use random
numbers, in order to solve the security problem with compressed disks.
25. Add a self-test of the random number generator, so that it can
detect if the compiler has broken it.
26. Make the built-in text viewer able to scroll back by a line and a page.
27. Add the capability to specify more than one recepients in
interactive mode (currently this is possible only in command-line mode
or within a wrapper script).
B) Bug reports
1. I have separate keyring, containing the public keys of a particular
group of people I correspond with. All the keys in this keyring are
certified by me. I want to add a new key to this keyring. This key is
already certified by me. When I execute the command
pgp -ka newkey.asc newring.pgp
PGP still asks me whether I want to certify some keys, regardless that
all keys are already certified by me. When I respond positively, it
lists the new key, says that there is a "questionable signature" by me
and offers me to certify it. If I agree, it says that it is already
certified.
2. The file 3B1_68000.s needs to be renamed 3B1_68010.s to match the
makefile. In fact, it is even better to rename it to 3b168000.s (and
to introduce the appropriate changes in the makefile), in order to
comply with the 8.3 restriction in MS-DOS.
3. The program md5sum (from the contrib directory) needs a makefile,
to indicate which files have to be used from the src directory.
4. The file pgp2x.md5 needs to be updated to take care of the modified
files in the directory src.
5. The program md5sum should work correctly, regardless whether the
files in the directory src are in MS-DOS or Unix format.
6. In the makefile, change add "-DMAX_NAMELEN=14" to the CFLAGS line
in the 3b1_asm area. This is required to compile fileio.c on some
systems.
7. Edit random.c and comment out the "#include <sys/time.h>" line.
8. In sign-only mode ("pgp -sa message") PGP doesn't compress the
message. This should be fixed.
9. The documentation files in the archives PGP2x.ZIP and PGP2xSRC.ZIP
have slightly different contents and even different names
(extensions). This should be fixed.
10. If a file is encrypted "for your eyes only" (pgp -em), then it can
still be saved on the disk, if PGP is used as a filter:
pgp -f < message.asc > message.txt
This should be fixed - if stdout is redirected, such messages should
be sent to stderr.
--
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN
< PGP 2.3 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bont...@fbihh.informatik.uni-hamburg.de 22527 Hamburg, Germany