Some proposals to consider

[Miron Cuperman]

crunch at netcom.com (John Draper) writes:

>Greetings fellow cypherpunks:

>   I've been getting good support for my ideas on implementing machine
>independent modules or "Libraries" of PGP routines that don't include
>I/O portions,   but after looking at the code,   I see this is going to
>take a lot of work,   both in organizing the effort,   and in implementing
>the code.    Just how this is going to be done,  I'm not sure,   but this
>is what cypherpunks is all about.    To hash these things over,  flame on
>each other's ideas,  etc.

It would be very nice if PGP behaved better as a UNIX filter.  For
example, I'd like it to return an exit code if it fails.  I'd
also like it to have a flag that disables any access to the tty
for prompts.  For example, if I have an automatic  filter that
tries to decrypt all incoming messages, I don't want it to prompt
for a secret ring file when it can't decrypt something.

A very important addition to PGP would be multi-recipient encryption.
RIPEM implements this nicely, by having one private key (PGP has this
too - it uses IDEA) and encrypting this key with each recipient's key.

We could then run this list encrypted, in order to excercise PGP
and to see what user interface issues become important with heavy use.
(Not much security is afforded because of the public nature of the
list.)
-- 
	Miron Cuperman <miron at extropia.wimsey.com>   | NeXTmail/mime ok
		       <miron at cs.sfu.ca>	     | Public key avail
	AMIX: MCuperman				     |
immortalcybercomputinglaissezfaire		     |