Questions about "--group" for group encryptions.

[reynt0]

On Fri, 19 Feb 2010, Zy Zylek wrote:

> I'm looking for a way to include a group of people in gpg file
> encryption/decryption (not email-based, just gpg encrypted files) without
> having to incorporate individual names, yet also such that more people can
> be added to the group in the future and that they will be able to access
> previously encrypted files because they joined the group after the old files
> were encrypted.
  . . .

I hope the following isn't just a waste of bandwidth, but:

Stepping back from the details (omitted from my quote of your
post) of your original question, and trying to clarify just
your first statement (quoted above):  Is what you want a full
many-to-many encryption/decryption functionality with minimum
keyage and non-static membership in "many"?

With public key encryption a basic practice is that encryption
(speaking only of encryption here, not authentication) is done
using public key, and decryption is done using private key.
By that model maybe what you describe is some PuK which "many"
knows and can encrypt with, and an associated PrK which "many"
also knows and can decrypt with?  And people can be added to 
"many" as you please?

Otherwise than this many-to-many, it might sound like what
you want is expandable/deflatable set of "ones" for mass 
one-to-one, which would involve the complexity and time to
manage encryption to a different PuK for each "one" in the
set, including each "one" in a currrent set would need to
know the PuK of every other "one" in that set.  And when a
new "one" were added to the set, in order to give them access
to past encrypted files somehow all previously encrypted
files would have to be reencrypted to the new "one"'s PuK so
the new "one" too could read the old files.

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

The many-to-many might be considered a low-security plan
since any member of "many" could reveal the group PrK and
thereby make all future as well as past files insecure.
In the mass one-to-one, any "one" (one person, not one group,
since the real trust locus is person, not key) also could
break security by revealing the PrK used by that "one" for
the group, but they would have also to reveal individual
files as encrypted to their PuK in order for their PrK to
be used to decrypt.  And files encrypted after the revealer
left the group would not have been encrypted to the
revealer's PuK.

Related issues include how keys are communicated, and
where the files might be including to what extent files
might be communicated as distinct from being stored.