0
$\begingroup$

I thought a problem and want to ask if there's a more elegant solution.

The scenario:
A company with a fileserver, which hosts encrypted documents.
The files need to be accessible by about a dozen employees.
Now the condition is, that each employee has different key material but all the employees can still access the file (even though they have different materials).

The most naive approach would be to give everyone the symmetric key that's it. This violates the condition.
The next way would be to store the file's key in a header, which is encrypted with each employee's symmetric key. The problem with this is, that everyone none can create new files without knowing the keys of the others.

The most optimal solution I'm aware of is to use asymmetric encryption to encrypt the file's key in a header for each employee using his corresponding key. This would enable everyone to create new files for the group and it would let everyone have different keying material (which can even be stored on a smartcard).

Now my question:
Is there a way to solve the above problem, without the overhead for the additional headers (maybe using some more esoteric protocol or algorithm)?

I'd prefer an answer which doesn't only give a name for the class of algorithms, but also instantiations, which are considered secure (based on blockciphers, asymmetric encryption schemes, ...)

$\endgroup$
  • $\begingroup$ en.wikipedia.org/wiki/Broadcast_encryption $\;$ $\endgroup$ – user991 Jun 18 '15 at 19:37
  • $\begingroup$ @RickyDemer, I'm not sure if this solves all the above problems. Can a "simple recipient" "broadcast" just like the "regular" broadcaster can? $\endgroup$ – SEJPM Jun 18 '15 at 20:35
  • $\begingroup$ Even if such schemes don't ordinarily allow that, one could let the "key material"s be tuples whose entries are reception keys and a broadcasting key. $\;$ $\endgroup$ – user991 Jun 18 '15 at 20:45
  • $\begingroup$ What about revocation? $\endgroup$ – cygnusv Jun 19 '15 at 7:04
1
$\begingroup$

Now the condition is, that each employee has different key material

solve the above problem, without the overhead for the additional headers

Based on your requirements - you must have the different key material for each user... which obviously has to be stored somewhere. You don't want it in headers ... so it either needs to be in a different file / database, or in the meta-data.

We had a similar problem which we solved using Extended File Attributes instead of additional headers. The symmetric file key was encrypted for each authorized recipient using the recipients RSA Public Key and the result was stored in the file meta-data.

https://en.wikipedia.org/wiki/Extended_file_attributes

Some filesystems have default limits on the amount of meta-data you can store. You may need to configure those.

$\endgroup$
  • $\begingroup$ +1 well, this approach is at least "creative". However nice finding that the header can be "outsourced" into the meta-data. $\endgroup$ – SEJPM Jun 19 '15 at 20:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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