Question regarding group management of documents

[Jeffrey Kay]

I'm not familiar with the PGP APIs, but it seems that you don't need to
go through the extra "armor" layers to do this.

File encryption consists of two encryption steps (typically) --
encryption of the file with a symmetric key and then encryption of that
symmetric key with the public key from the key pair.  That means that an
encrypted file will contain a list of encrypted keys, each identifying
which public key was used to encrypt it, viz.

P1(K)
P2(K)
P3(K)
...
Pn(K)
K(M)

where K is the symmetric key, Pn is a public key and M is the contents
of the file.  To remove a user of the file, just delete one of the Pn(K)
records.  Since K can be retrieved by applying a private key Rn to a
Pn(K), adding a member to the file is done by retrieving K and then
adding a new Pn(K) record.  This means that only someone who can open
the file can add a new "member".

This has the obvious downside that if I can access the entire file in
its encrypted state, then I can get K and preserve it for posterity.
However, if I can get the file contents while a member of the group and
copy it off somewhere, then it really doesn't matter whether I can get
the key for one file, does it?  K will be different for every file, so
it doesn't matter -- all files newer than when I was expelled from the
group will be unreadable to me.  Similarly, anytime a file changed,
you'd want to generate a new K and rebuild your list of keys to access
it.

Does this make sense for your application?  This is a pretty easy thing
to build using OpenSSL (which I'm familiar with) and is probably pretty
easy to do with PGP (which I haven't developed against).  I'd suspect
that PGP does this already with their basic file encryption tools.  

jeffrey kay 
personal weblog <www.k2.com>
pgp key <www.k2.com/keys.htm>

"first get your facts, then you can distort them at your leisure" --
mark twain 
"if the person in the next lane at the stoplight rolls up the window and
locks the door, support their view of life by snarling at them" -- a
biker's guide to life
"if A equals success, then the formula is A equals X plus Y plus Z. X is
work. Y is play. Z is keep your mouth shut." -- albert einstein


> -----Original Message-----
> From: owner-cryptography at wasabisystems.com 
> [mailto:owner-cryptography at wasabisystems.com] On Behalf Of 
> Adam Shostack
> Sent: Thursday, January 16, 2003 10:56 AM
> To: Birger Toedtmann
> Cc: cryptography at wasabisystems.com
> Subject: Re: Question regarding group management of documents
> 
> 
> Groove does this; they have a 30ish page white paper on security of
> document management.  I have a few quibbles with their design (way too
> many crypto algorithms, and its not clear why, or if they might
> interact badly, and perhaps cert verification in a corporate
> environment could be better, but overall it looks very solid.)
> 
> http://www.groove.net/products/workspace/security.html
> 
> Now if only they had a Mac client!
> 
> Adam
> 
> 
> On Thu, Jan 16, 2003 at 09:38:04AM +0100, Birger Toedtmann wrote:
> | 
> | Hi,
> | 
> | can anyone pinpoint me to some papers on this - the Net did 
> not show 
> | up anything useful (and I hope it's not my lacking 
> competence in using
> | Google).
> | 
> | 
> | I'd like to use a server to share documents between users.  
> The users
> | are grouped, i.e. a user of group A should not be able to read the
> | docs of group B (if not a member of it).  There are conceptually two
> | possible ways to design this:
> | 
> |  * use an "out-band-process" (an operating system watching over
> |    file permissions, a web service verifying user credentials etc.)
> | 
> |  * use in-band crypto on the document itself, i.e. the "permissions"
> |    are inherently tied to the bits it consists of
> | 
> | I wanted to use the latter with a critical constraint: ease 
> of deploy-
> | ment (at least in a sense) which basically means that we don't want
> | to write a new client but use freely available ones.  So my first 
> | guess was to PGP-encrypt the files on the server using the public 
> | keys of the group-members.  The server obviously should not 
> have the 
> | secret keys of them.  I further assume that (a) a 
> member-no-more takes 
> | his secret key with him and (b) the server may be hacked 
> but the hacker 
> | should not be able to read the documents (but may 
> corrupt/delete them).
> | 
> | So far, so good.  Now a user leaves a group.  As the server is not
> | able to decrypt files and we don't want someone to decrypt 
> 1000 files
> | of a group and re-encrypt them again with the members left, it would
> | be possible to just encrypt the already-crypted file again with the
> | "new" group of the remaining members (adding sort of a 
> second armor).
> | Despite this being quite stressing for users if a file has some-20
> | armors, I did not come up with an idea for adding *new* members to a
> | group....
> | 
> | 
> | Well, maybe I'm already on the wrong track for this issue, so I 
> | appreciate any suggestions or hints to sites/papers 
> discussing these 
> | problems.
> | 
> | 
> | Regards,
> | 
> | Birger Tödtmann
> | 
> | 
> ---------------------------------------------------------------------
> | The Cryptography Mailing List
> | Unsubscribe by sending "unsubscribe cryptography" to 
> majordomo at wasabisystems.com
> 
> -- 
> "It is seldom that liberty of any kind is lost all at once."
> 					               -Hume
> 
> 
> 
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to 
> majordomo at wasabisystems.com
> 


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com