Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Announcement: Mac Crypto Interface Project

16 views
Skip to first unread message

-=Xenon=-

unread,
May 12, 1994, 7:29:54 PM5/12/94
to
-----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 qwe...@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
<qwe...@netcom.com> or Jordyn A. Buchanan <jab...@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=-
<qwe...@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 <jab...@u.cc.utah.edu>
or -=Xenon=- <qwe...@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 <jab...@u.cc.utah.edu>
-=Xenon=- <qwe...@netcom.com>


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

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

Jon Wätte

unread,
May 13, 1994, 6:10:23 AM5/13/94
to
In <qwertyCp...@netcom.com> qwe...@netcom.com (-=Xenon=-) writes:

>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

Apple already has a system-level API for encryption, signatures, and
verification; it's part of AOCE (Apple Open Collaboration Environment)

I suggest you add PGP as AOCE services, to reap the benefits of
all applications that already today can handle authentification.

Cheers,

/ h+
--
-- Jon W{tte, h...@nada.kth.se, Mac Hacker Deluxe (on a Swedish scale) --

Clearly, most humans are not rational beings; they are rationalizing beings.
-- Mel Walker

David Sternlight

unread,
May 13, 1994, 2:07:48 PM5/13/94
to
In article <2qvjmf$3...@news.kth.se>,

Jon Wätte <d88...@dront.nada.kth.se> wrote:
>In <qwertyCp...@netcom.com> qwe...@netcom.com (-=Xenon=-) writes:
>
>>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
>
>Apple already has a system-level API for encryption, signatures, and
>verification; it's part of AOCE (Apple Open Collaboration Environment)
>
>I suggest you add PGP as AOCE services, to reap the benefits of
>all applications that already today can handle authentification.

This is going to be bit tricky, though the suggestion is an excellent one
which I support.

The reason is that AOCE's key generation is through the "Digisign Utility".
at present it generates keys and certificate requests consistent with the
PEM Certification Heirarchy, and the certificate reequest must be sent to
RSADSI's Certification Service in order to get the key validated. Then one
reads the certificate back into the Digisign Utility which activates one's
key pair.

Thus PGP will either have to be modified to conform to the PEM Certification
heirarchy, Apple will have to add web-of-trust provisions to Digisign and
the core system utilities, or PGP Mac users will have to generate their key
pairs for PGP separately and use them separately from their certified AOCE
key pair used to sign and authenticate.

For now, the easiest path is the one RIPEM Mac has chosen--it will import
Digisign certificates and then use the same key pair for encryption and
decryption. But all its own activities are isolated from the AOCE system
routines and the API for same.

Ripem may shortly be adding the new "web-of-trust" addendum to the RFC on
PEM certificates. Whether Apple will do so or not remains to be seen.

The big gap right now in AOCE is built-in message encryption and decryption.
If a way could be found for either RIPEM Mac or PGP 2.5 to integrate with
message composition and mail sending and receiving facilities, it would be a
big step forward.

Right now there's only one Mac mailer that includes PEM--Techmail-PEM. It is
not integrated with AOCE, and doesn't even import AOCE key pairs (yet), but
for the rest it works fine. Hopefully it will be enhanced (it's still in
beta) to take AOCE key pairs and also to use Triple DES and IDEA. Since Jeff
Schiller is involved in both Techmail-PEM, and PGP 2.5, there's pretty good
hope, one would think, for Mac users. Maybe the next version of Techmail-PEM
will also have a PGP option and be the "universal solvent" we've been
searching for which will read PEM headers and deal transparently with either
PGP-type encryption or Ripem/PEMDEV type.

Then the next step would be a version of Techmail-PEM which would work
without a SLIP/TCP/IP connection for those of us with terminal accounts. One
would launch it without having to be connected to anything, for message
composition, reading, and management (including encryption/decryption). One
would invoke it while connected on one's terminal account, and it would pass
its outbox properly to a mail handler, and get one's incoming mail. One
would then disconnect to use it off-line.

One lives in hope. Given MIT students' workloads, if we see anything like
this, it probably won't be until September, unless someone can persuade a
faculty advisor to let him make it a thesis project, or the comp center
takes it on as a paid project.

Jeff?
Ray?

David

Leonard Rosenthol

unread,
May 13, 1994, 3:42:38 PM5/13/94
to
In article <2qvjmf$3...@news.kth.se>, d88...@dront.nada.kth.se (Jon Wätte)
wrote:

> In <qwertyCp...@netcom.com> qwe...@netcom.com (-=Xenon=-) writes:
>
> >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
>
> Apple already has a system-level API for encryption, signatures, and
> verification; it's part of AOCE (Apple Open Collaboration Environment)
>
> I suggest you add PGP as AOCE services, to reap the benefits of
> all applications that already today can handle authentification.
>

Are you suggesting that he "replace" the existing DigSig mechanism with
a set of hooks to the "PGP Engine" so that documents would be signed with
PGP Sigs instead of AOCE/RSA sigs? If so, then as cool an idea as it is,
it would require COMPLETELY patching out the ENTIRE DigSig Manager since
there are no hooks to replace this stuff (for reasonably obvious
reasons). However, that doesn't mean that it isn't possible.

Also remember that AOCE does NOT provide for encryption of arbitrary
data, only for authentication of data via signatures.


Leonard
--------------------------------------------------------------------------
Leonard Rosenthol Internet: leon...@netcom.com
Director of Advanced Technology AppleLink: MACgician
Aladdin Systems, Inc. GEnie: MACgician

Leonard Rosenthol

unread,
May 13, 1994, 3:42:43 PM5/13/94
to
In article <2qvjmf$3...@news.kth.se>, d88...@dront.nada.kth.se (Jon Wätte)
wrote:

> In <qwertyCp...@netcom.com> qwe...@netcom.com (-=Xenon=-) writes:


>
> >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
>
> Apple already has a system-level API for encryption, signatures, and
> verification; it's part of AOCE (Apple Open Collaboration Environment)
>
> I suggest you add PGP as AOCE services, to reap the benefits of
> all applications that already today can handle authentification.
>

Stephan Somogyi

unread,
May 14, 1994, 10:30:36 PM5/14/94
to
In article <2qvjmf$3...@news.kth.se>, d88...@dront.nada.kth.se (Jon Wdtte)
wrote:

> I suggest you add PGP as AOCE services, to reap the benefits of
> all applications that already today can handle authentification.

There are no public APIs to replace or augment PowerTalk's encryption and
authentication services; this is supposedly one of the requirements that
Apple had to meet for NSA/DOD/State Dept/DOC (I forget who's in charge of
the licenses these days) to allow PowerTalk's export.

____________________________________________________________________________
Stephan Somogyi Vorsprung durch Technik Digital Media

David Sternlight

unread,
May 15, 1994, 2:22:35 AM5/15/94
to
In article <somogyi-1405...@lre1.macuser.ziff.com>,

Stephan Somogyi <som...@ziff.com> wrote:
>In article <2qvjmf$3...@news.kth.se>, d88...@dront.nada.kth.se (Jon Wdtte)
>wrote:
>
>> I suggest you add PGP as AOCE services, to reap the benefits of
>> all applications that already today can handle authentification.
>
>There are no public APIs to replace or augment PowerTalk's encryption and
>authentication services; this is supposedly one of the requirements that
>Apple had to meet for NSA/DOD/State Dept/DOC (I forget who's in charge of
>the licenses these days) to allow PowerTalk's export.

If this is true it explains Apple's repeated refusal to describe how one can
modify the PRFS resource of the Digisign utility for longer authentication
keys. I've been getting the royal run-around from Developer Services, the
AOCE programming team, the marketing folks, and even RSADSI on this for the
past several weeks. Given the RSA-129 factoring, I certainly wouldn't trust
anything really valuable to a 512k bit key.

There's probably a pretty good news story in this.

David

Black Unicorn

unread,
May 15, 1994, 6:41:35 AM5/15/94
to
In article <strnlghtC...@netcom.com>,

I have been consistantly skeptical and wary of the AOCE design from its
rumored development to this day.

It's very static, has little room for flexability, and probably isn't
secure or going to be backwards compatible when the key lengths are made
to be longer.

A third party adaptation of PGP or MacRipem to easy finder like use is
a far better goal IMHO.

Stay away from the thick morass that is AOCE, it's not needed if the new
MacInterface Project people do their job well.


>
>There's probably a pretty good news story in this.

About Apple's backwards compatability woes? The ever increasing size of
the system software for no real gain?

>David

-uni- (Dark)


--
Heute ist Mirroccoli Tag - Find me Sick, Dark and Twisted, and I'm happy.
073BB885A786F666 6E6D4506F6EDBC17 - One if by land, two if by sea.

David Sternlight

unread,
May 15, 1994, 2:09:41 PM5/15/94
to
In article <2r4u8v$c...@access1.digex.net>,
Black Unicorn <uni...@access1.digex.net> wrote:

>>
>>If this is true it explains Apple's repeated refusal to describe how one can
>>modify the PRFS resource of the Digisign utility for longer authentication
>>keys. I've been getting the royal run-around from Developer Services, the
>>AOCE programming team, the marketing folks, and even RSADSI on this for the
>>past several weeks. Given the RSA-129 factoring, I certainly wouldn't trust
>>anything really valuable to a 512k bit key.
>
>I have been consistantly skeptical and wary of the AOCE design from its
>rumored development to this day.
>
>It's very static, has little room for flexability, and probably isn't
>secure or going to be backwards compatible when the key lengths are made
>to be longer.

THAT part they did comment on. IF you get DIGISIGN to generate longer keys,
the rest of the system handles them just fine--unmodified AOCE will
authenticate such files and messages; RSADSI will certify them, etc.

I also established by trial and error that if one changes the one value in
the PRFS resource to a larger value, for example by moving the significant
digit one place to the left, one does get larger keys. But I don't like to
grope around in the dark.

David

Owen M. Hartnett

unread,
May 15, 1994, 4:36:42 PM5/15/94
to

This is definitely true, as it was announced that it was so at a WWDC
conference. The AOCE designers didn't want the trouble of going through a
rigorous export licensing procedure (which might have delayed AOCE) and
opted to restrict AOCE's encryption technologies in order to comply with
what the government would smile upon. I believe they would have liked to
have made it stronger, but any beefs are with the government, not with Apple.

Also realize that Apple is in a pretty pickle with this. Not only can they
not provide good crypto capacity themselves, but helping you to do so in
any way, shape or form may cause them to run afoul of their agreements with
the government, something nobody wants to happen. (i.e. if they've just
assured the government that it can't be used in this way, then giving you
the means by which to do it, could land them in hot water.)

-Owen


--
Owen Hartnett o...@cs.brown.edu
"FAITH, n. Belief without evidence in what is told by one who speaks
without knowledge, of things without parallel."
-Ambrose Bierce - The Devil's Dictionary

David Sternlight

unread,
May 16, 1994, 4:43:09 AM5/16/94
to
In article <1994May15.2...@cs.brown.edu>,

Owen M. Hartnett <o...@cs.brown.edu> wrote:
>
>This is definitely true, as it was announced that it was so at a WWDC
>conference. The AOCE designers didn't want the trouble of going through a
>rigorous export licensing procedure (which might have delayed AOCE) and
>opted to restrict AOCE's encryption technologies in order to comply with
>what the government would smile upon. I believe they would have liked to
>have made it stronger, but any beefs are with the government, not with Apple.
>
>Also realize that Apple is in a pretty pickle with this. Not only can they
>not provide good crypto capacity themselves, but helping you to do so in
>any way, shape or form may cause them to run afoul of their agreements with
>the government, something nobody wants to happen. (i.e. if they've just
>assured the government that it can't be used in this way, then giving you
>the means by which to do it, could land them in hot water.)

The government does not prevent export of authentication as long as it
cannot be used for encryption. The government does not care what key length
is used for authentication.

The information I've been seeking will not give AOCE encryption
capabilities. It will simply generate longer authentication key pairs than
512 bits.

David

Matthew Holiday

unread,
May 16, 1994, 11:31:10 AM5/16/94
to
In article <2qvjmf$3...@news.kth.se>, d88...@dront.nada.kth.se (Jon Wätte) writes:
-> In <qwertyCp...@netcom.com> qwe...@netcom.com (-=Xenon=-) writes:
->
-> >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
->
-> Apple already has a system-level API for encryption, signatures, and
-> verification; it's part of AOCE (Apple Open Collaboration Environment)
->
-> I suggest you add PGP as AOCE services, to reap the benefits of
-> all applications that already today can handle authentification.

I agree. PGP would be best integrated with AOCE/Powertalk since it already sup-
ports RSA keys. It would be useful to have PGP use the AOCE keyring (perhaps in
addition to its own). Note that Powertalk will be standard system software with
the release of Mac System 7.5.

--
Matt Holiday #include <std/disclaimer>
hol...@bnr.ca
BNR Richardson, TX "Proud owner of an unregistered computer"

David HM Spector

unread,
May 17, 1994, 8:21:28 PM5/17/94
to
> o...@cs.brown.edu (Owen M. Hartnett) writes:
> Also realize that Apple is in a pretty pickle with this. Not only
> can they not provide good crypto capacity themselves, but helping
> you to do so in >any way, shape or form may cause them to run afoul
> of their agreements with the government, something nobody wants to
> happen. (i.e. if they've just assured the government that it can't
> be used in this way, then giving you >the means by which to do it,
> could land them in hot water.)


Fortunately, Apple gave developers almost all the info needed to add
ANY kind of functionality to Apple's Systems software, including AOCE.

As a Mac developer for more than 10 years, if I were developing such
extensions, I would read up on:

The Component Manager, which is the fundamental building block for
both QuickTime, AOCE and its associated technologies..

The Apple Shared Library Manager which is a similar (but newer) part
of the system

With these two software constructs, on can add ANY kind of
functionality to a Macintosh and make it as transparent as the ROM
toolbox..... in fact, on could even make it so that AOCE has hooked
through a theoretical MacPGP component. After that one might write
apps that use these new "mangers"...

In fact the hard part ISN'T getting it into the system, rather its
getting a version of PGP that has never met the standard I/O of UNIX
and/or DOS.... cause ripping PGP apart to make this happen is just
about as hard as rewriting it from scratch. (PGPTools comes close,
BTW, but I don't know how authoritative a version of the code that
is....)

just one programmer's ramblings....

regards,
DHMS

0 new messages