Mailing List Archive

Sen Nagata <sen_ml@eccosys.com> writes:

> can gpg be used in library form? if so, i take it there isn't
> much documentation (bseides the source) :-)

I don't like the idea of putting everything into a library.
GNUPG is a Unix program and the philosophy behind Unix is
KISS (Keep it Small and Simple); Probably we will have a GNU
Cryptography Library sometime but this will not be a complete
GNUPG implementation.

> i am also curious whether there is some mode of operation to
> support decryption followed by encryption in a single process

Of cource I could do so, but it is more easier (and not so error prone)
to make a shell script (or a simple C program) which calls multiple
instances of GNUPG and connects them in a pipeline. Pipelines are
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.

If you really need a very high performance utility, some stuff can be
done to make the initial start up of the program faster. An option you
may like could be a mode which encrypts a message with the key for
every specified user and outputs a complete messages for every user,
where the message is encrypted with the same session key:

plaintext
|
| perform symmetric encryption with a session key
|
sym-encrypted-message
|
|------------------------------+------------------------+-- ...
| encrypt session key | |
| for user A and build |
| a mail for him. |
| |
encrypted-message-for-A encrypted-message-for-B
| |
| send via sendmail to A | send via sendmail to A
| |
mail-to-A mail-to-B


This scheme has the advantage, that you only need one session-key
and symmetric encryption - which is perfectly okay, because the
message is the same for every recipient.

Anyway, I don't think that this is really needed: messages in
a ML are quite short and the symmetric encryption is in that case
much faster than the public-key encrytion for a user.


Werner

On Fri, 17 Apr 1998, Werner Koch wrote:

> Sen Nagata <sen_ml@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@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.

Anand.