Questions about "--group" for group encryptions.

[reynt0]

(responding to only the parts of ZZ's post which seem directed
to my prior post)

On Wed, 24 Feb 2010, Zy Zylek wrote:
  . . .

> By "full many-to-many encryption/decryption functionality",
> do you mean many people and many files? Basically yes (to that).

I apologize for being too brief.  By "many-to-many" I meant
like a graph theory analysis, where "many" refers to people,
and "many-to-many" means like a bunch of people each one
of which knows a shared public-private keypair, used to encrypt
or decrypt files to which each member of the "many" group
has access.  Ie with some single en/decrypt action using one
single keypair anyone of many people can accomplish en/decryption
to many other people.  A mass "one-to-one" alternative would be
each individual member of the group needing to know an individual
public-private keypair for each other member of the group.  Ie
group en/decryption would be more like a mass of individual,
one-to-one actions.

Similar questions exist about file maintenaance.  Would files
be kept in some single location where each member of the group
would freely deposit encrypted files and each member would freely
access the files (a many-to-many way of doing file maintenance)?
Or would each member of the group keep only files he/she had
created and each other member have to know of each files' 
individual existence and location and access them there (a
kind of one-to-one); or maybe each member of the group would
have to send a copy of each encrypted file he/she creates to
each other member of the group, so each could maintain a copy
of every file (a kind of mass one-to-one file maintenance)?

> By "minimum keyage", do you mean functionality with as few keys as possible?
> If that, then not necessarily. If it is possible to collaborate the
> advantages of having a different key per individual, and yet they all depend
> on one group keypair (that only User A administrates (adds/removes
> individuals' keys)) in order to encrypt/decrypt group files, then I do not
> want minimum keyage (if that's what that means).

I did mean as few keys as possible, thinking just of use for
your project.  But what you say, a "different key per individual"
and "one group keypair", sounds maybe like the following?  People
can in general have however many keypairs they want (which is
correct); and included among those keypairs would be a keypair 
that is issued by some administrator A and that is shared by
everyone to whom admin A gives it, and that is to be used just
for the group's files?  Yes, that is a possibility.

> . . .
> Referencing the model you mentioned - that is using public key to encrypt
> and private key to decrypt - it sounds like it might (or might not?) be
> possible (or useful?) to have a separate group public key and a separate
> group private key, yet to not have them actually function as a "pair"
> (together), or are you asking something else? . . .

A public-private key "pair" means they depend on each other
to work together.  That is the basic idea of having public
and private keys in the first place.

>  . . .
> RE: "...expandable/deflatable set of "ones" for mass one-to-one..."
>
> I don't understand that, sorry, could you paraphrase your "one" and "one"
> type description that you provided? It was somewhat confusing.

I apologize.  I just meant the number of people in the group
could increase or decrease.  In this case, each single member
joining the group has to be dealt with as an individual who has
to be told the public key of each other member (to be able to
encrypt files for those others to be able to decrypt); and has 
to be able to decrypt old files using his/her new-to-the-group
private key, so all old files would have to be freshly
encrypted to the new member's public key.  And when any person
leaves the group all other individual members have to be
notified to stop using that person's keypair.

> Does your explanation match my User A, B, C, D and file 1, 2, 3, 4 example?

I can not answer that simply, so I'll hope my answers
above help.

> RE: "Alternatively, if what you want is one-to-many, you can see how that
> could be arranged similar to either of the above."

One-to-many could be something like one administrator creating
all files and controlling access to them by many users, and
maybe the admin using a single keypair of which all members know
one part, which the members can use to decrypt the files; or
maybe the admin using a different keypair for each individual
group member.

HTH.