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, ...)

Improve this question
$\endgroup$
4
  • $\begingroup$ en.wikipedia.org/wiki/Broadcast_encryption $\;$ $\endgroup$
    – user991
    Jun 18, 2015 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, 2015 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, 2015 at 20:45
  • $\begingroup$ What about revocation? $\endgroup$
    – cygnusv
    Jun 19, 2015 at 7:04

1 Answer 1

Reset to default
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.

Improve this answer
$\endgroup$
1
  • $\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, 2015 at 20:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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