From: paul@hawksbill.sprintmrn.com (Paul Ferguson)
Date: Fri, 13 May 94 05:54:08 PDT
To: cypherpunks@toad.com
Subject: (fwd) Announcement: Mac Crypto Interface Project
Message-ID: <9405131355.AA09889@hawksbill.sprintmrn.com>
MIME-Version: 1.0
Content-Type: text/plain



Forwarded message:

From: qwerty@netcom.com (-=Xenon=-)
Subject: Announcement: Mac Crypto Interface Project
Organization: PGP Info Clearinghouse.
Date: Thu, 12 May 1994 23:29:54 GMT

-----BEGIN PGP SIGNED MESSAGE-----

Mac programmers, hello from The Macintosh Cryptography Interface Project.
Included here are our "Statement of Purpose", and "Interface Design Sheet".

What's public key encryption? It means if anyone encrypts something with
your public key, not even they can read it again, only you, using your
secret key. Send mail to qwerty@netcom.com with Subject "Bomb me!" for Gary
Edstrom's PGP FAQ and -=Xenon=-'s "Here's How to MacPGP!" guides, which are
also available from ftp.netcom.com in /pub/qwerty.

                    -======Statement of Purpose======-

Phillip Zimmerman's vision of giving the common man a real encryptor, humbly
called Pretty Good Privacy (PGP), "Public Key Encryption for the Masses",
was an historical event. But while PGP exists for many platforms including
the Mac, it's still a command-line beast, and it shows. The current MacPGP
is a powerful tool, but unacceptably difficult to use for average Mac
users.

Welcome to The Macintosh Cryptography Interface Project.

MacPGP wont be a "program". It will be like the Trash or the Clipboard. It's
going to be part of the Mac itself. A tool to set programmers free, allowing
them to easily call upon any function of PGP from their software, and a tool
for Mac users to use within any program.

OUR GOALS:

The ability to use PGP with non-PGP fanatics! Right now this isn't possible.
Try it and see.

Our emphasis is on the Macintosh, not cryptography. PGP will be a Mac
routine, not a hacked port of the latest DOS PGP. The core PGP routines will
be incorporated into a "PGP Engine" with  minimal or no interface, easily
accessed from other programs via AppleEvents. The operation of this engine
will be quick and transparent so the privacy and security offered by PGP can
become an expectation, not an inconvenience.

A simple, user-friendly interface to this Engine will be designed: a smart
system-wide menu, which will know what to do. Selecting a file and choosing
"Encrypt" will encrypt the file to the user's own public key. No passwords.
In a word processor, "Decrypt" will return a selected block of encrypted
text to its original form (only with the proper pass phrase!). For e-mail,
"Encrypt to...", containing a sub-menu of public keys, will quickly protect
an outgoing message from viewing by anyone but its intended recipient. If
not in the Finder, the Clipboard will be used automatically. Simple and
easy. Eventually programs will incorporate PGP functions as internal,
automatic features, accessing the PGP engine directly.

The goal, quite simply, is to put strong, usable security into the hands of
every Mac user.

WHAT WE NEED:

You. Programmers, who turn ideas into code. Cryptography? The cryptographic
code exists; what we need now are serious Macintosh programmers.

We also need non-programmers to help design a user-friendly environment, to
help us find problems in our programs, and to contribute ideas that will
help us make the high standards of PGP-encryption universally available.
Just as we need the most sophisticated Macintosh programmers for this
project to fly, we also need the most frustrated and inexperienced users to
make sure that we have met our goals. If you wish to help, contact Xenon
<qwerty@netcom.com> or Jordyn A. Buchanan <jab3418@u.cc.utah.edu> as soon as
possible.

We have established an international mailing list for this Project, in which
no crypto code will flow. Work on the interface will be completely
independent of the crypto code, meaning no worry for our programmers.
Officially the Macintosh Cryptography Interface Project is not even linked
to PGP, though we intend to become the official interface for the licensed
MacPGP2.5, and the inevitable EuroMacPGP cryto engine. Early on, we will use
an unofficial version of MacPGP2.3 which accepts AppleEvents, as our
temporary model crypto engine.

We need PGP2.5 to be converted into an AppleEvents engine, as an independent
project; anyone within the US interested in working on this should also
contact us. People in Europe etc. need to create their own AppleEvents
MacPGP cryto engine.


                     -======The MCIP Design Sheet======-

Two prototype models for this interface have been built, which are available
from ftp.netcom.com in /pub/qwerty/MCIP, or by e-mail from -=Xenon=-
<qwerty@netcom.com>. One is based on J. W. Walker's OtherMenu, which is also
available there.

We have a mailing list, where there will be no crypto code. This will free
programmers from worries about legal hassles involving crypto politics.

If you are a Mac programmer, contact Jordyn Buchanan <jab3418@u.cc.utah.edu>
or -=Xenon=- <qwerty@netcom.com> and we will sign you up and try to agree an
a sub-project and specific design. We are also interested in helpful
criticism of our design, and its implementation. The OtherMenu paradigm
versus our own System Extension is not cast in stone, and needs input from
experienced programmers as well as some experience with OtherMenu.

Definitions: PlainText is Mac TEXT file or text on the Clipboard. PlainFile
means any Mac file, be it a word processor document or a GIF file.
CypherText is a text-format PGP message. CypherFile is a binary PGP message,
a MacPGP file.

The Engine: A dumb PGP cryto engine which accepts AppleEvents, and acts on
files or the Clipboard. In the end it should have no interface of its own.
This will be created independently of the interface, in both US and non-US
versions.

The Interface: A system-wide menu next to Balloon Help, making PGP functions
available from any application, including the Finder.

 -=Items in the PGP Menu=-

1) Encrypt/decrypt -- for all types of decryption and for immediate
encryption of personal files with the user's public key. Just select a file
in the Finder and this command will either decrypt it, asking for a
passphrase, or encrypt it with your public key, no questions asked. If the
user isn't in the Finder the Clipboard will automatically be used. PGP will
figure out if a file is already encrypted or not, and take appropriate
action upon it. Additionally, if the option key is held down during
passphrase confirmation, decrypted PlainText from the Clipboard will be
presented in a window of PGP's text editor (see below). If on decrypting a
file on the Clipboard, the output is not PlainText, a Mac binary file will
be output to the Desktop, automatically. Within the Finder, holding down the
option key while confirming pass phrase entry will launch the decrypted
file. On encrypting a personal file, the original plaintext will be securely
wiped out. On decrypting a personal file, the original will be deleted.

2) Encrypt to... -- this has a submenu containing the keys on your Public
Keyring. If you are not in the Finder, the contents of the Clipboard will be
encrypted with the person's public key you select from this menu. If you are
in the Finder, the selected file will be encrypted to that person, with a
quick dialog box appearing asking for Clipboard or Desktop (and CypherText
or CypherFile) output. A TEXT file in the Finder will be treated as text
input to PGP, but any other file will be treated as a binary Mac file. At
the top of this menu will be Group... which will allow fast single-clicking
of multiple recipients from a list. Aliases of single or multiple recipients
will also be easy to define, and will appear in a group at the top of this
menu.

3) Sign -- If not in the Finder, this will clearsign the contents of the
Clipboard (after cutting it to <80 characters per line). If in the Finder,
the selected file will be "armored" with a dialog asking for Clipboard
(CypherText) or Desktop (and CypherFile or CypherText) output.

4) Keys... -- Dialog box(s) which handles all key management, including a
quick button for adding a public key from the Clipboard, or extracting your
public key to the Clipboard. The rest is standard, but for the ability to
create Aliases for groups of people, the name of the alias then appearing at
the top of the Encrypt to... submenu.

5) "Editor..." -- A simple <80 character wide window for typing out (then
encrypting) quick e-mail or viewing normal decrypted e-mail. This is for
users of simple VT100 terminal emulators, which includes most people using
e-mail via modem. The user can choose a font and size, and resize the window
vertically. If the window for this editor is active, the PGP menu will act
upon text selected in it, or all of the text if no selection has been made.
Our goal is to actually have people use this editor for their e-mail
drafting and reading. It will also be able to save or append it's contents
to a text file, for those of us who keep e-mail logs.

6) "Options..." -- If the user has multiple key-pairs, they can select the
one for use in signing things, and for personal encryption. They can select
whether to sign things when using "Encrypt to...". They can select the File
Type Creator for output text files in the Finder. Any other options will be
set here, and be kept in a Preferences file in the Preferences folder
(duh).

That's it! One menu. No options to choose during the most commonly used
operations. Just immediate action after a single menu selection. To
demonstrate and elaborate on this interface, here now are presented various
actions a user may do. I will use my girlfriend as an example.

 -=User Actions, Outlined=-

1) Encrypt her diary, which she just wrote using Microsoft Word: She saves
the file, selects it in the Finder, and encrypts it with her public key with
a single PGP menu selection ("Encrypt/decrypt"). Done.

2) Adds a day's writing to her diary: double clicks her encrypted diary,
types her passphase into a dialog box, and hits the return key, to have the
CypherFile replaced by a PlainFile. And, since she held down the option key
when she hit the return key (OK button), PGP sent an AppleEvent to open that
file, so she's already typing new stuff in Microsoft Word.

3) Decrypt the e-mail I sent her: She copies it to the Clipboard, since it's
only a couple pages of CypherText. Without leaving her VT102 modem program,
she selects "Encrypt/decrypt", is prompted for her pass phrase, and since
she holds down the option key when she hits the return key, the PlainText is
presented to her in PGP's editor window. I did have to show her how to use
Unix "mail" instead of PINE though, since PINE would require saving and then
downloading the file, it only being able to show one small block of text at
a time in a non-scrollable window.

4) Respond to my e-mail above: She just types away, using the editor's
convenient features. She selects her text and simply chooses my name from
the PGP "Encrypt to..." submenu. It ends up in the Clipboard, automatically.
She's still in her modem program, so she just pastes the CypherText into e-
mail.

5) Post a clearsigned announcement to Usenet: "Editor" lets her type it out,
then simple selecting "Sign" places the clearsigned message onto the
Clipboard. If she is responding to someone else's post, she must copy the
original then paste it into the editor.

6) Check a signature from Usenet: Copy the message to the Clipboard and
select "Encrypt/decrypt". An alert appears telling her the signature is good
or bad. The message is placed on the Clipboard, free of signature.

7) Send a huge Mac file to me, encrypted: She selects it in the Finder,
chooses my name from the "Encrypt to" submenu and hits the "PlainText /
Desktop" button. She has her modem software autotype the file into e-mail,
or uploads it. If it's not too large she can instead hit the "Clipboard"
button and just paste it into e-mail.

8) Decrypt a huge CypherText file I sent her in e-mail: she saves it and
downloads it, selects it in the Finder and selects "Encrypt/decrypt", and
after she types her pass phrase the CypherText is replaced by a PlainFile.

9) Encrypt the message "Meet at midnight, at Nell's, tomorrow!" to a group
of people who she is working on a project with. She brings up PGP's editor,
types the message, and selects the "Babes" alias, which she earlier defined,
from the "Encrypt to" submenu. Her message is automatically encrypted to
that group of people, the result being placed on the Clipboard for pasting
into e-mail.

 -=Comments=-

1) PGP is a public key encryptor. No "conventional encryption" is needed in
our basic interface, since encrypting a file in your public key is so much
easier than having to very carefully type a pass phrase for the encryption
step. If someone wants IDEA-only encryption they can use Will Kinney's Curve
Encrypt, which does drag-and-drop, they can use the old MacPGP, or they can
create their own "Conventionally encrypt" feature to add to our modular
interface.

2) Our design is in flux, and flexible. However our singular goal is this:
that we can send MacPGP on a floppy to any non-sophisticated Mac user and
have them send us a public key within an hour, then start using PGP for e-
mail the next day. There will be little in the way of a manual other than as
a brief intro on exactly how to quickly set up and use PGP, Balloon Help
being enough for most operations.

3) Our interface is a separate project from the cryptography engine. Early
on we will use MacPGP2.3aV1.1 which does accept AppleEvents. This will allow
us to get started now, as well as have MacPGP2.3aV1.1 take care of features
we have not built into the interface yet, such as full key management.

4) Initially we will spool the Clipboard to disk files, then delete them
after we have the crypto engine act on them. Later the cryto engine will
have an AppleEvent option for using the Clipboard. In the end this will
likely have no interface of its own at all, and become a background-only
application.

5) We intend to be the official interface for MacPGP2.5, and hope to see
PGP2.5 quickly ported to the Mac as an AppleEvents cryptography engine, for
use by our interface and any other program such as Mac e-mail programs.

6) J. W. Walker's OtherMenu shareware ($10) may be looked at as a system-
wide menu tool kit, to which we can add our routines as CODE resources,
placed in the OtherMenu Folder in the System Folder. This will allow us to
start getting things done immediately, without any worry about building our
own System Extension. OtherMenu is actively maintained by Mr. Walker, who
has also been personable in e-mail. We can remove all the extensions that
come with OtherMenu, leaving only our own menu items! We can even place our
own icon atop our menu. This is a clean solution. CODE resources are
trivially made using Think C. Anything that we could do with an application
we can do easier with an OtherMenu CODE resource file, and our menu ends up
in the system-wide OtherMenu next to Balloon Help. OtherMenu will send any
AppleEvent we create for us, as well. There is an OtherMenu Developer Kit
available for free, though really such CODE resources are just like any Mac
program. These can be had from ftp.netcom.com in /pub/qwerty/MCIP. We may
think of OtherMenu as a part of the Mac operating system, which allows us to
add any feature to a system-wide menu.

As further persuasion, imagine that we had created a system-wide menu for
this project, by writing our own System Extension. Further, unbelievably,
imagine that we made this Extension able to accept modular plug-in PGP
features as simple CODE resources, thus creating a framework for breaking
our project into smaller independent projects. Now imagine this is true, and
thus take a look at OtherMenu, with a MacPGP icon slapped onto it. Sure it's
$10, but it's shareware, and it saves us untold development time and effort.
Later, if anyone wishes to assemble our CODE resources into a dedicated
System Extension, they are free to do so, though I don't think it will be
worth the ten bucks.

7) The interface will be somewhat inflexible in how it does things, which is
needed in order to make it very simple. Extraneous features and options will
be weeded out unmercifully until the interface is a model of simplicity.
Art, if you will. Cryptography fanatics are free to design their own
interface to the PGP Engine.

8) We want security of left-over PlainText on the user's hard disk to be
handled by PGP, automatically. On encrypting a file for personal use with
"Encrypt/decrypt", the original WILL be wiped clean from the hard disk. We
should include in our distribution FlameFile by Josh Goldfoot for wiping out
Finder files, or all unused hard disk space. In fact, FlameFile can be
operated via AppleEvents as well.

9) Since we are developing free software with limited resources and limited
time for making an impact, certain compromises have been made compared to a
perfect design. OtherMenu is one pleasant compromise. Using MacPGP2.3aV1.1
is not very happy, but will have to do for now. It has the same layout as
MacPGP2.3, but is debugged and will accept AppleEvents, in some detail. It
will not so far however allow selection of the Clipboard for input/output.
The source code for MacPGP2.3aV1.1 is also not yet available, though we will
indeed put a large effort into getting it.

Another possibility is to write some of our routines as AppleScript
applications with Apple's Script Editor, and place them in the OtherMenu
folder so they will appear as normal menu items. This would be a temporary
quick fix at best. For instance (using "Jon's Commands" for the Finder
selection part) the following does work to encrypt a file(s) selected in the
Finder to my public key, then wipe the plaintext.

tell application "MacPGP"
        encrypt (finder selection) to "Xenon"
        quit
end tell

tell application "FlameFile"
        open (finder selection)
        quit
end tell

10) Jordyn, -=Xenon=-, as well as others, do have connections with the core
PGP development community, for what it's worth. Our main interest is
becoming the interface for the next MacPGP. We need our dumb AppleEvents
crypto engine to be built from PGP2.5 by a few Mac programmers. If you
hadn't suspected it, former MacPGP development is dead, for rather boring
reasons. We will help people interested in working on the MacPGP engine in
any way we can. There should be two compatible versions, US and
international. Since MacPGP development is no longer happening, we need a
new group of dedicated people to tackle this, independently of our interface
project.

11) An encrypted file will have its name altered, as well as its icon (its
type changed to CRYPT too, so a double click will trigger PGP). There are
selection dialog boxes and hierarchical menus which show only names, so
changing an icon isn't enough. I suggest just *, appended directly to the
end of the name, which PGP will not use in any way except as a sign to the
user that file is CypherText.

12) No, this interface is not incorporation of PGP into e-mail programs so
to make it's operation transparent. The reason for this is the good old
VT102 emulator, which so many people use, since that's what came with their
modem. People using Macintosh based e-mail programs, will indeed have it
easier, once someone links those programs to PGP, so outgoing mail is
automatically encrypted, and incoming decrypted. Such uses will still have
use for our Finder-based commands however, and their e-mail programs will
use the same PGP cryto engine, via AppleEvents.

13) For this project to fly, strong leadership is required. This interface
design sheet will be maintained by -=Xenon=-, with equal contribution by
Jordyn Buchanan, and SHOULD be followed. Changes to this sheet are easy
though: tell us your story of woe, need, or ambition, and we will make
changes and issue an update. Alternatively, draft your own sheet ;-). Or get
us interested enough in your ideas that we let you take over. This sheet
will become very detailed. Given the modularity of this interface, more than
one answer to a given problem can be created, with the user choosing
favorites. Wherever a conflict in design philosophy arises, the MacPGP
USERS, not the programmers will have the greater say. That said, we are
looking for creative ideas and damming criticism so we know we are thinking
straight.

14) PGP will be free. Why are we doing this? Because ViaCrypt isn't doing
it. Unless their MacPGP is System software, free, with source code, we have
little interest in ViaCrypt as the answer to how to be able to get our
friends to use PGP with us, today. We simply want PGP to become something we
no longer think about, so we can get on with our lives instead of struggling
with the problem of getting others to use it with us. That shall remain our
goal and only purpose.

15) This project is in its infancy. Jordyn and -=Xenon=- are not yet skilled
Mac programmers, which in fact gives us an advantage in designing an
interface. We are here to reflect what the needs of users are, and to
provide organization and resources for this project. We are here by default,
there being no competition. However, and especially since this interface
project is free from legal and political hassles, we need strongly motivated
and highly skilled Mac fanatics to take our design and make it real.

16) The modularity of this interface will allow addition of special-purpose
features to PGP, such as Stealth PGP which strips PGP messages down so far
you can't tell them from noise, steganography, Magic Money functions
(Pr0duct Cypher's PGP-based money system), or anonymous remailer chaining.
In fact, without easy to use interfaces for these systems being available
for the Mac (and Windows), steganography, digital cash, and chaining of
encrypted anonymous remailers will remain obscure toys.

17) The PGP cryto engine, though not mentioned in detail herein, will become
a plaything for programmers who wish to create their own PGP-based
applications such as for sending credit card orders via e-mail, creating
local encrypted networks, making PGP encryption a transparent feature of
steganographs, or transparent incorporation of PGP into Mac-based e-mail
readers. We need to know what such programmers want out of the engine, since
our needs are simple. The engine is not slave to our interface design, and
should be pursued for its own sake. We simply hope to show that it should be
kept simple, perhaps with no interface of its own and run only by
AppleEvents (and thus AppleScript etc. if desired). A separate design effort
will be needed, mainly to simply define the required AppleEvent structures
that will negate the need for its own interface.

One thing I'd love is the ability to define a "safe" folder, the contents of
which would be encrypted, always, unless they were open. Then my diary could
sit in there, and get encrypted as soon as I was done writing and saved it
from my word processor. This could be a System Extension, always watching
that folder. With the PGP crypto engine, the writer of such an Extension
would not have to worry about any crypto code.

18) It's time to stop waiting for PGP3.0 to be released, since our interface
relies only on the most simple of concepts for AppleEvents it will send, and
altering AppleEvents is easy. If and when PGP3.0 arrives, our interface will
be ready, and porting PGP3.0 to the Mac will thus be much easier.


 -=Critical Path=-

Anyone can take it upon themself to work on these.

1) Get source code for MacPGP2.3aV1.1 and alter it to accept the Clipboard
as an input/output option, which it already can do, if operated manually.
Till then we will spool the Clipboard to disk and have MacPGP2.3aV1.1 act
only on files. MacPGP2.3aV1.1 was recently released in Germany, and will act
as our temporary model crypto engine.

2) Recruit native Macintosh programmers, and do a job of inspiring them
about what this project is about, and why it is important. Also find some
frustrated MacPGP users to tell us what they need, though explanations of
what e-mail programs they use, and how they would like to interface it with
PGP. We should get our literature posted on AOL and Compuserve as well,
where many "isolated" programmers live.

3) Learn the ins and outs of J. W. Walker's OtherMenu and write up a
tutorial on how to program the Mac this way, then create our interface in
independent pieces as CODE resource files. A CODE resource is just a Mac
application stripped down a bit, so they are in fact easier than building an
application. The modularity of our interface will give people small yet
fully functional projects to work on.

4) Independently of our MCIP mailing list, port PGP2.5 to the Mac as a
background-only cryto engine, which accepts detailed AppleEvents. Create a
Developer's Kit so any Mac programmer can incorporate PGP into their
software.

5) Copyright our Interface, which is really just a few externals for
OtherMenu, rendering it free.

 -=Questions=-

1) How will we handle pass phrase recycling during a long but busy e-mail
session? We could do without it completely, as an option.

2) Might we allow selection of Macintosh folders full of stuff, then create
an archive of the folder to send to PGP? Or should we just encrypt all the
files within a selected folder? That's easier.

3) Though this would require some tricks, might we have PGP use the
Clipboard indirectly, by automatically copying any selected text from a text
editing window of any application to the Clipboard? Or selecting all of the
text in a text editing area, if no selection has been made by the user? The
could be termed "magic", for it would be like an added feature to that
program that you use it in. Just select text then go to the PGP menu.

4) How can we handle a progress dialog box during long operations? The
crypto engine itself shouldn't in the end have any interface. So how do we
make a legitimate progress indicator?

5) How do we get the name of the file(s) selected when the user is in the
Finder? [If we cannot do this, we can substitute Finder activities with
drag-and-drop applications on the Desktop. There would be three of these,
one for each menu item, "Encrypt/decrypt", "Encrypt to...", and "Sign".]
"Jon's Commands", and AppleScript addition is able to get this info, though
the author said he had to delve into undocumented data structures to find
it. He seemed willing to help, or we could just use his addition.

6) What will happen if the user is in the Finder, but has selected nothing,
or has accidentally selected like their entire hard disk, which is quite
common to accidentally do? On the other hand, it wont be too uncommon for
someone to wish to encrypt the entire contents of a floppy, or even a hard
disk. A dialog box will be needed if the folder selected is a disk.
Obviously, there should be a responsive "Cancel" button/command-. option
while the encryption progress window is on the screen, which should return
all files to their original condition (that's what "Cancel" means). What if
they have nothing selected? A dialog box will appear saying they haven't
selected anything, with "Clipboard" being default, and "Cancel" as an
option.

 -=Comparison of MacPGP2.3 to the New MacPGP=-

1) To encrypt a file on my hard disk, that I just wrote with a word
processor:

OLD: 1) Start up MacPGP, and wait for it to fire up (~4 seconds), 2)
Command-key and wait for dialog (1 second), 3) Command-D to get to Desktop
and click-click click-click click-click click-click click-click click-click
click-click to dig up my file deep on my hard disk (~5 seconds), 4) select
my public key from the list and hit OK if I am not using "conventional
encryption" (which I am NOT since nobody, including myself, can stand typing
a damn pass phrase SUPER carefully for an ENCRYPTION step with risk of full
data loss on making a typo), (3 seconds), 5) gaze at a HUGE dialog box of 13
buttons and three text edit boxes, selecting "treat source as Macintosh
file", "wipe original", "don't sign" and gaze again to make sure I don't
have someone else's public key accidentally chosen, and finally hit "Do it"
(~4 seconds), 6) wait while staring at a UNIX/DOS screen scrolling text at
me instead of a normal Macintosh progress box, 7) quit MacPGP.

NEW: Click on the file from the Finder and select "Encrypt/decrypt" from the
PGP menu. Decryption is IDENTICAL, except for prompting for a pass phrase,
and the option of simply double-clicking on the encrypted file.

2) To encrypt a file to someone else:

OLD: SEE ABOVE 7 STEPS!

NEW: Place my message on the Clipboard with two standard keystrokes, select
the person's name in the PGP "Encrypt to" submenu, and paste it into e-
mail.

3) To send short quick e-mail:

OLD: 1) Start up a damn word processor and copy the message to the
Clipboard, then SEE ABOVE 7 STEPS.

NEW: 1) Call up PGP's little text editor in an instant, without leaving my
e-mail program, type my message and choose the person's name in the "Encrypt
to" menu of PGP. The editor shuts down and the encrypted message ends up in
the Clipboard, ready to paste into e-mail.

4) Decrypt short e-mail I just got:

OLD: Copy it to the Clipboard and then SEE ABOVE 7 STEPS, and then start up
a damn word processor and Paste the PlainText into a document so I can read
it!

NEW: Copy it to Clipboard and hit "Encrypt/decrypt", holding down the option
key so it appears in PGP's text editor window for my viewing pleasure.

5) Add a key to my public keyring.

OLD: Copy it to Clipboard, start up a word processor, save it as text-only.
Start up PGP, "Add keys...", click-click, click-click, then click-click,
click-click, click-click, click-click to find my pubring.pgp. Then say, no,
I don't want to certify the key myself.

NEW: Copy it to Clipboard, choose "Keys..." from the PGP menu without
leaving my e-mail software, click on a button that says "Add key from
Clipboard". Done, and I'm back in e-mail.

Jordyn Buchanan <jab3418@u.cc.utah.edu>
 -=Xenon=- <qwerty@netcom.com>


-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLdKCHQSzG6zrQn1RAQGrAQP+Mw9dJz4vIhnFb8s+CwL84QG3qo5rdYFE
78B4VlA/brOlWmXj6SApn0Yd+l+cLSmezZbLnnumOysk5ZXaTGbOVdv+gN6Ur4lZ
6Nk5pQ+UZNpoM3XBrsCu7k+b0opkMrEkgPv5IfMIQDTJuOOyRryispBjuaS9YuAT
QueTCgnbJWA=
=olym
-----END PGP SIGNATURE-----