api for gpg?

Anand Kumria wildfire at progsoc.uts.edu.au
Tue Apr 28 03:58:33 CEST 1998

On Fri, 17 Apr 1998, Werner Koch wrote:

> Sen Nagata <sen_ml at eccosys.com> writes:
> the reason which makes the power of a Unix OS - there is only a small
> (if at all) performace penalty.  
> > then re-encrypt the result using multiple keys w/o having to pipe from 
> By the way, it is possible to encrypt a message for more than one
> recipient - not very much tested, but it should work.

Hi Werner,

I think Sen was thinking of something different. Perhaps Sen was thinking
of group crypto. Where one person could send to a group of people and they
could only decrypt something when they had reached a certain threshold.

Hmm, I'm not making much sense, let me see if I can explain what I mean
more clearly:

When you communicate there are four different modes you can communicate
in.  Single Sender, Single Receiver (SS); Single Sender, Multiple
Receivers (SM); Multiple Senders, Single Receiver (MS) and Multiple
Senders, Multiple Receivers (MM). 

Current crypto products (PGP, CTC, GPG, etc.) handle the single
sender/receiver case easily. I think you can also argue that the multiple
sender/receiver case breaks down into two seperate communications one of
which is SM and the other MS.

I can see some immediate uses for Single Sender/Mltiple Receiver crypto;
one would be in the Debian group. new-maintainer at debian.org actually goes
to a number of people, in order to send a crypted message to them I need
to know who those people are, what their current correct public keys are
then I need to encrypt multiple times so that all of them can read my
message. It is a hassle.

I can see some potential uses for MS (e.g. returning votes, ballots,
acknowledgment, etc.) especially when the number of parties you are
communicating with is unknown before you start.

I can see some initial problems: key generation, secret sharing, secret
recombination/splitting, manipulating group membership, etc. No doubt
there are many others that I doubt see.

Anyway, I am just airing some of my thoughts - if I ever find some free
time I'll try my hand at implementing some of these.


More information about the Gnupg-devel mailing list