linux at codehelp.co.uk
Mon Apr 26 22:32:00 CEST 2004
On Monday 26 April 2004 7:04, Jerry Windrel wrote:
To clarify: Personally, I don't see the point of a group key for a mailing
list - it's generally unworkable, more than a little pointless and
unnecessarily exclusive. Lists are meant to be open and openly archived.
However, the question of a group key is wider than just a list. There have
been discussions about corporate keys on this list before, a group key is a
> imagining you mean is that a key pair is generated and assosicated, not
> with a person as is customery, but rather with a group. The private key
> (and any passphrase) would then be distributed to all members of the group
> (which would be quite an unorthodox practice, in terms of PGP). Then, all
> messages to the group would be encrypted to that "group key".
Or, more simply, a single database would keep a tally of current keyids and
encrypt all messages to a vast list of keys using the same session key. Not
surprising that this doesn't sound good. At least it removes the need for a
distributed private key AND it allows for user additions and removals. You
would be able to exclude old keys from decrypting old messages and allow new
keys to decrypt old messages, however, re-encrypting archived messages to the
amended group would be too burdensome, (being recursive and all).
This would, in effect, simply be a group of keys (or key group), not a group
key. GnuPG can already do this and has group functionality in place. I don't
think the group was ever considered to be of sufficient size for an entire
> The ramifications of this would be: the group private key would be only as
> secure as the weakest practices of any of the group members; you would be
As has been discussed elsewhere on this list today, encrypting to more than
one person/key always renders the entire chain vulnerable to the weakest link
- it has always been this way, no matter what tool is used to create any
> able to add but not remove members (unless you generated a new group key).
> Please clarify and correct as necessary
The problems and limitations of a group key are not technological but
practical and social. It echoes other comments about using a key on a server
to sign or decrypt messages automatically - the passphrase is either entirely
absent or stored in a file on the server. Neither are particularly appealing
because you substitute the security of GnuPG for the security of the server
alone instead of adding. (If anyone can crack the server, they can obtain the
private key + passphrase, if any.)
More feasible were ideas around corporate keys that had a single main key that
had a private key only accessible to a named high-up bod. That key would sign
subordinate keys and revoke signatures if the subordinate left the company.
At no time would more than one individual ever have access to more than one
private key in the corporate keyring and no one private key would ever
available to more than one person. This is workable but is it worthwhile? The
problem remains of controlling the signatures and what happens when the
underlings get together and sign each other's keys thereby becoming trusted
without the boss' signature? That's a procedural / management / policy issue.
It also didn't address the issue of encrypting to everyone, just trusting the
signatures / keys. Encryption would still use some form of key group - which
leaves it right back at square 1.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Url : /pipermail/attachments/20040426/38d6dd09/attachment.bin
More information about the Gnupg-users