PGP 2.2 Application Note: Integrating PGP with mailers
Derek Atkins <warlord@MIT.EDU>
6-Mar-93
This document will try to describe how to create an
application around PGP version 2.2, in order to incorporate PGP into
mailers and news readers. There are a number of changes in 2.2 which
make it easier to write wrappers for PGP. In writing this, I may have
inadvertantly left out some functionality, some mailers, or some
machine types. I should warn readers now that I am a UNIX person, and
that most of this document will probably be in UNIX terms.
This document references scripts which are in the contrib
directory of PGP. Within the contrib area are scripts contributed to
the release. A lot of these scripts were written for PGP 2.1, so they
do not handle multiple recipients, or some of the new PGP features.
The first thing to remember is that PGP usually needs to have
a controlling TTY in order to gather information, like the password,
or for the user to answer questions, like to whether to add or sign
keys. This is useful for text-based mail agents. In fact, it is most
useful for agents which use files for messages, like MH.
One example for this is in the emacs directory. The e-lisp
pgp.el1 winds up saving the buffer to encrypt or decrypt to a file,
and then runs pgp on that file using the emacs interactive mode. It
looks the same as if you type "pgp filename" at the shell.
However, this is not very interesting. While it is easy to to
this, it means that there are extra files being created on the disk.
This can be a security risk, since wiping files off disk is not always
successful, and by having the plain-text go to a file means more time
for a possible attacker to get ahold of the plain-text of the message.
A better way to accomplish this is to use filter_mode, which is the -f
option. This tells PGP to read the message from stdin, and to put the
output onto stdout. Unfortunately, in this manner, the signature
information is output onto stderr, so you will either lose it, or it
and all other PGP output will be put in the same stream with the
message, but this depends on your piping ability.
An example of how to use this is the mailx script. This
script is supposed to run in place of the UNIX /bin/mail program. It
reads from stdin and will do the proper encryption and then execute
/bin/mail. This works by specifying a special user for the recipient
to encrypt and signature. This works by calling PGP with the
following arguments, and uses stdin and stdout for the mail input and
output. However, this script only is useful for sending mail, not
reading it.
To just sign the message, in clear-text mode:
pgp -fast +clearsig=on
or to sign and encrypt:
pgp -feast user1 user2 user3...
This works well when dealing with a command-line mailer, or a
mailer that is run in a terminal. There are problems, however, if you
do not have a TTY in which to get a password to decrypt or sign
messages. I'm not sure of a way around this, but then again, PEM is
going to have this same problem. (An example that I can think of is
integrating with xmh).
There is a way around this, however, in some cases. One way,
which is not recommended, but can be used, is to use the "-z" option
to set the passphrase. Again, this is *NOT* recommended, since some
operating systems will not allow the program to erase the process
table, and someone can retreive the pass phrase from there. A similar
way to get the pass phrase in is to use the PGPPASS environment
variable. Again, this has the same problems. An example of this
usage is:
pgp -sat +clearsig=on -z "This is my pass phrase" inputfile
There is a better way of doing this in PGP 2.2, which is an
environment variable called "PGPPASSFD". If this is set, it means
that the FIRST thing PGP will do is read the pass phrase from this
file descriptor. So, for example, one can set PGPPASSFD to "0"
(zero), and then PGP will read the pass phrase from stdin as the first
thing.
For example, an emacs utility could grab the block to be
encrypted (or decrypted), ask the user for the pass phrase in the
mini-buffer, and then do the equivalent of this shell script, using
something like:
(send-string PROCESS "PassPhrase")
(send-region PROCESS (point-min) (point-max))
---begin--#!/bin/sh
PGPPASSFD=0;export PGPPASSFD
(echo "PassPhraseHere"; cat ) | pgp -feast recipient1 recipient2...
---end--I must admit, this is a crude script, since it doesn't strip
out stderr, which included the bannerlines and error messages, but
that is not difficult to do out of band.
This is an example perl script that demonstrates the use of PGPPASSFD:
---begin--#!/usr/local/bin/perl
#
# perl example for PGPPASSFD,
# encrypts stream with password 'test'
#
pipe(READER,WRITER);
if (!fork) {
close(WRITER);
$ENV{'PGPPASSFD'}=fileno(READER);
# the $^F (Ctrl-F) variable controls close-on-exec of files
$ =fileno(READER);
exec "pgp -acf";
die "can't exec pgp\n";
}
close(READER);
syswrite(WRITER, "test\n", 5);
close(WRITER);
wait
---end--Another feature of 2.2 which can be utilized in mailer scripts
is the batchmode feature. This is used in the key-server software
(see key-server.doc), which is not included in the release to allow a
process to call PGP, and have it perform without prompting the user
for anything. It will take the default answer to most questions,
which may not be what the user wants. This is switched by adding
"+batchmode" to the command line.
One more mailer I should mention, and this is probably the
most important of all of them, is MIME compatibility. In order to use
MIME, a user needs to create a proper entry for PGP. Unfortunately
there hasn't, yet, been a standard MIME content-type created. One
possible mailcap entry would be:
application/x-pgp:
cat %s | pgp -f
although there are a lot of possibilities. There is another
suggestion given in the mime directory in the contrib area, which I
haven't tested.
I hope that this document has helped people understand some of
the work being done to integrate PGP with mailers. There is some work
going on already to integrate it even more. If you have a mailer for
which there is no PGP handler, and you want to write one, please let
me know, so that we don't duplicate work. In addition, if you have
written a mailer application, and its not included here in the
release, again let me know.
A second contact for this is Colin Plumb <colin@nyx.cs.du.edu>.
Have fun!
-derek
<warlord@MIT.EDU>