Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I believe it's possible to meet these requirements only if a third party is involved in a manual process. For example:

  • Each user is given the same public key
  • The private key resides offline at a third party
  • Alice creates a document. When she wants to share it, she sends it to the third party who signs the document and uploads the document to the central server.
  • If Bob wants to view it, he verifies the document's signature with the shared public key

I'd like to eliminate the third party from the process. However, I haven't come up with a way to do so. Everyone in the account would need the same public/private key installed. Documents signed by Alice and the private key could be verified by all other users since they also have the same key pair.

The problem: new users can be added at anytime so the public/private keys would need to stored at a central location so these new users can obtain the keys. If that location was compromised, a hacker could upload new documents and sign them with the compromised private key.

In a nutshell, storing the private key on a central server seems similar to storing plain text passwords.

So, is there way to securely share centrally-stored documents among a changing set of users?

share|improve this question
Hi @Derek, welcome to the site! A bit more info wrt what you're looking for, when you say "secure" - do you mean protect confidentiality (i.e. no one else can see it)? Integrity - no one should be able to change it? Or, it sounds like you're more interested in Authenticity - ensuring the identity of whoever wrote the document? –  AviD Jun 18 '11 at 20:56

2 Answers 2

As @AviD points out, "secure" is a wide term, and there are several properties which can thus be called. Here, I will concentrate on confidentiality.

So you want some people to share some documents, which must remain unreadable for people out of that group, and such that you could afterwards add or remove some people to the group. One point to note is that, conceptually, you cannot force people to become amnesiac; hence, if a member of the group could read a document at some point, then he perfectly could have kept a copy somewhere. Therefore, revoking access of a user is about not making new documents readable by that user; for old documents, this is "too late". Given that point, a possible solution looks like this:

  • Every document is encrypted symmetrically with a random key K (a new key for each document).

  • Each user has his own public and private key pair, suitable for asymmetric encryption (e.g. a RSA or El-Gamal key pair).

  • Every document has a header which contains the encryption of K with the public key of each user who is deemed authorized to read the document.

  • To revoke a user, simply stops encrypting the K of new documents with the public key of that user.

  • To add a user retroactively, compute the encryption of K with the public key of that user, for each old document to which access must be granted; this can be done, of course, only by another user who can access the said documents (i.e. obtain K).

The system above is precisely what OpenPGP describes (see GnuPG for an opensource implementation). This was meant for secure emailing, but it works regardless of the actual transport medium, which could be a shared storage area.

There are drawbacks in the scheme described above:

  • Whoever produces the document must know the list of who should be able to access the document. This is not an absolute requirement; we could imagine a setup where the document is propagated from user to user, each user adding the encrypted K for the next user.

  • Each document has a header which grows linearly in the number of users in the system; for reasonably secure RSA encryption (2048-bit RSA keys), that's 256 extra bytes per user. Depending on the context, the overhead can range from the utterly negligible to the ludicrously unbearable.

  • The list of users who can access the document can be deduced by anybody, by looking at the header of the encrypted document.

  • Users have public keys, which implies the usual problem of distributing public keys in a secure way -- i.e. while avoiding usurpers. If there are many users, the solution involves a Public Key Infrastructure (PKI); OpenPGP uses the kind of decentralized PKI known as "Web Of Trust". X.509 is another PKI standard, with a pyramidal, centralized structure. Both are good at managing easy cases, and bad at scaling up.

Another, very different scheme for secure document sharing, is what is done with Blu-ray discs, with the AACS copy-protection. The security model is that there is a kind of central authority, but offline; each user (a Blu-ray player) has its own symmetric key, that the central authority also knows. When the authority publishes a new document (say, a new movie), the document is symmetrically encrypted with its own symmetric key K, and that key K is made available to all players through broadcast encryption. The authority want to distribute K to N users, where N is big, while using relatively little bandwidth (N can be in the order of hundreds of millions, but there is not that much free space on a disc), being able to add new users retroactively without requiring any document-specific transmission (you cannot patch discs once they have been built and distributed), and still having the possibility to revoke specific users. The mathematical beauty of the broadcast encryption used in AACS is that it requires size only O(log N) on each disc, plus O(R) where R is the number of revoked users. New users can be added at will. The idea is that a "user" will be revoked only if it appears that a player key has been disclosed and began to be widely copied in rogue players; hopefully (that is, the Blu-ray consortium hopes it), the individual player-breaking cost will remain sufficiently high that no more than a few dozens of such keys will have to be revoked.

Broadcast encryption uses a structure of double-nested trees which would be a bit too long to describe here. See this article for details.

There apparently is some existing research on the topic of broadcast asymmetric encryption, which avoids the need for a central authority which knows all the keys. I do not know whether good, secure schemes to that effect are currently known.

share|improve this answer

Yes there is such a scheme. It has been implemented by ownCloud which is an opensource cloud document storage product. It's encryption security model is described here. To summarise:

  1. Each user has a public/private key pair
  2. Each document is given a unique symmetric key with which the document is encrypted and uploaded into the backing storage container. This is called the file-key.
  3. Whenever a user is granted access to the file the file-key is encrypted with the users public key.

The ownCloud scheme does not require a trusted third party. It can be done entirely with client side cryptography. All needs is a central store. We could use an FTP server and command line GPG tools:

  1. Put all our public keys in one top level folder
  2. Use a folder per document
  3. The file creator generates a random file-key and encrypts the document with it
  4. For each person she wants to share the document with she encrypts the file-key with their public key and uploads that into the document folder.

Trust is then the standard GPG model. The document creator then both encrypts and signs the document. Readers can check the fingerprints of the public keys and confirm them over the telephone.

As per Thomas's answer revoking access to a document cannot wipe it from the readers mind nor any copies they have taken. In the simple case outline above if we wanted to lock out some people previously granted access to the document from future edits we would have to make a copy of the file and encrypt that with a fresh file-key. We could actually do better than that if we only modify a file by uploading patch format deltas to the document we are editing. These delta files can either be encrypted with the original file-key to keep the same visibility else with fresh file key if we want to reduce the set of readers.

We don't actually need a folder per document. If we take the approach of making each version immutable by only uploading patch format delta to the file we can use an append only file format to write to the back of the file. The file-keys encrypted with the readers public keys can also be appended to the file. Better yet one could adapt a concurrent editing document format such as treedoc by both encrypting and signing the user edits with a file-key stored within the treedoc format.

share|improve this answer
I am very troubled to read this post goo.gl/rjLRXq where a person has developed a system which uses an approach like ownCloud and they are looking to weaken it as they believe they are required to provide access to any encrypted data they host. That would suggest that the laws in come countries don't allow the person asking the question to have the level of security they are seeking :-( –  simbo1905 Jan 11 at 9:27

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.