Gnupg good for big groups?

[David Smith]

Snaky Love wrote:
> Hi, 
> 
> thank you very much for the interesting discussion. 
> 
> About GSWoT - does this cover my described use-case? I don´t quite get
> it from a first glance on the website...

Well, I've only just learned about it by reading the website, but...

Not really.

>From what I can tell, GSWoT doesn't really add anything "technically" to
GnuPG and the "normal" WoT.

I think that the idea behind "GSWoT" is to create a number of "more
trusted" people that will actively go out and sign keys, and adhere to a
specified code of conduct when doing so.  They are hoping that, due to
their affiliation with the GSWoT organisation, that you will put more
trust in their ability to sign keys than you would in "Joe Public".  By
doing this, they hope that people who choose to increase their trust
level of GSWoT "introducers" will therefore be able to validate many
more keys than someone with standard trust settings.

However, it does not solve your problem.

IMHO, GnuPG is the wrong tool (overall) to solve your problem.  There
are ways in which you could shoe-horn it to force it to work, but it's
really not the appropriate tool.

The "mailing list" problem is solved relatively easily with GnuPG - as
others have said, the originator of each message sends his/her message
to the list server encrypted with the server's key; the server then
decrypts the message and forwards the mail to each list member encrypted
with each member's key individually; alternatively the server could send
the message to every member at the same time encrypted with everyone's
key, although that might have some privacy and bandwidth issues (since
you can tell who is on the list, and if there are many users, the
overhead of including the session key so many times might become
prohibitive.

The main problem is with the archive; in particular, revoking access.

One way you could do it:

   Every document is encrypted using symmetric encryption with the same,
   randomly-generated session key. That key is then encrypted using each
   list member's key, and sent to every member.

   If a new member arrives, they are given the current session key
   encrypted with their key.

   Now, this is where it becomes nasty.  When a member is removed, the
   entire database must be decrypted and then re-encrypted with a new,
   randomly-generated session key which is then re-distributed amongst
   the remaining members.

Another way:

   The system automatically encrypts every document with every user's
   key, plus one key for the administrator.

   When a user is added, the administrator decrypts and then re-encrypts
   every single document using the new user's key

   When a user is removed, the administrator decrypts and then
   re-encrypts every single document without the removed user's key.

Neither of these solutions solve the problem where a user takes a copy
of the whole encrypted database before they are removed.

Both of these solutions are rather painful.  As others have suggested, a
much better way of doing this sort of system would be a client-server
architecture where the user is required to log in to the server, which
decides (based on the user's credentials) whether to provide the
document.  Obviously you now have to make sure that the server mechanism
itself is secure and cannot be successfully attacked.

You could use GnuPG to encrypt communication between the client and
server, but as you've already mentioned, we already have SSL/TLS for
this sort of thing.

I'd propose that your requirements are likely to be served by:

 o A web server running either a forum or a Wiki, which requires user
   logins.  An audit may need to be done to check the security of the
   forum.

 o Enforcing the use of HTTPS to connect to the server

 o If mailed notifications are required, use a forum/Wiki which is able
   to mail out postings/changes, and modify the mailing back-end to
   encrypt all messages to the intended users.  You could use one of the
   encrypted mailing list servers available as your back-end.

 o Depending on your threat model, you may want to encrypt the back-end
   storage; in the worst case this could be on-the-fly encryption of
   each file as it's written to disk using the server's key (although
   this does introduce the problem of keeping the server's key secure),
   or it could just be an encrypted disk partition using (e.g.) LUKS.

Note that there are no solutions that will prevent a user keeping a
decrypted copy of a previously-downloaded document, unless you use your
own custom-written browser and document viewer.