Questions about "--group" for group encryptions.

[Zy Zylek]

Hello,

I have been wanting to respond to the replies, and am now finally able to.
:) First, thank you to those who replied and offered the input.

In response to your replies...

RE: Adding/removing individual keys to/from a group:
The --group (or group config line) feature makes better sense now. I
understand now that individual keys can be added to or removed from a group
but the group function applies to each individual key within it.

RE: "Group Key":
While --group has nothing to do with a "group key", it looks like I can
create a public/private key pair and designate it as a group key. There is a
reduced level of effectiveness using this approach, yet it appears to be the
only effective means of a true group-based (not several individual-keys
based) type of shared encryption/decryption of files, and in a way that
might allow for the addition of new members to the group. Though, I suspect
if someone is removed that a new "group key" pair might have to be created,
which (if it happens often) might be a bit tedious.

RE: --group option, and adding individuals' public keys:
That makes sense - that I'd have to add "--group" members' public keys to my
keyring before I can add them to the "--group" list.

RE: --trust-model always flag set and "lsign":
What are the pros/cons to using that flag? At the moment, my main
private/public keypair has not (yet) been verified by a proper trust-type
authority (via photo ID, etc., etc.). I almost had it verified a while back
but was unable to meet with the person.

RE: Additions/subtractions from "--group" encryption requiring *every*
individual managing the group list separately:
Does this basically mean that, although one individual might have the same
recurring list of individuals (not requiring change), that the "--group"
function is essentially a one-time-only every-time type of feature (if
another individual in that group ends up adding/removing someone)?

RE: "Group Key" again:
While it's possible to use a shared group key, which allows for everyone to
encrypt/decrypt with that group keypair, is it possible to increase the
security (at least a little) - to prevent just anyone from getting the group
keypair - by requiring one specific user (or one user's individual keypair)
to serve as a means of authentication for permitting a new person to receive
that shared group keypair?

RE: "I think I understand what you've described above as far as it goes, but
how about a little more detail?"

I think that my concept is perhaps the reverse of the "--group" gpg feature.
Rather than have a list of public keys of different individuals compiled as
a group, which also allows for any member of that group to alter who is
included/excluded, I'd like to have one single group keypair (or an
alternative to this, if one is available) with which only I can add/remove
which public keys of different individuals have access to either that group
keypair (or alternative).

RE: "Are you working with one file, or a lot of files?"

A lot of files.

RE: "Will the set of files be static, or at some future time might more
files be added to the list of things that the users will need to access?"

If you mean static similar to how one might compare static to dynamic, then
the files will be static, in the sense that they will not be edited in the
future. However, at some future time there will definitely be more (new)
files added to the list of things that users will need to access.

RE: "Will the users be given copies of the encrypted files?"

I'm not sure I understand your question. In the literal sense, yes. This
might help a little:

User A is group admin, she has file 1, she encrypts it for the group.
Any user with access to group-encrypted files can decrypt file 1.

User B has file 2, she encrypts it for the group.
Any user with access to group-encrypted files can decrypt file 2.

User C has file 3, she encrypts it for the group.
Any user with access to group-encrypted files can decrypt file 3.

User A removes User B from the group, "B" can no longer encrypt/decrypt.
User B has no access to group-encrypted files (old: 1, 2, 3, or new: 4+).

User A adds User D to the group, "D" has access to group-encrypted files.
User D has access to group-encrypted files (old: 1, 2, 3, or new: 4+).

User D has file 4, she encrypts it for the group.
Any user with access to group-encrypted files can decrypt file 4.

RE: "Is what you want a full many-to-many encryption/decryption
functionality with minimum keyage and non-static membership in "many"?"

I think my ABCD/1234 example above pretty much sums things up but let me see
if I understand what you're asking.

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

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).

RE: "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?"

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? I'm not sure I understand that
question.

RE: "And people can be added to "many" as you please?"

If I understand correctly, then yes, adding or removing individuals only by
the administrator of the group-key (or group-keypair).

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.

Here is your original explanation:
"...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."

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

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

I might be confusing what "many-to-many", "one-to-many", or "one-to-one"
mean). What do those terms mean?

This might not makes, mostly because I don't think I yet understand those 3
terms, but I would be interested in implemented a "layered" type of approach
if necessary, where potential low-security methods of one approach could be
remedied if that approach is "contained within" a higher-security method of
another approach. (I hope that didn't sound confusing.)

Thank you everybody for your responses!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20100224/fe527bf3/attachment-0001.htm>