1
$\begingroup$

My problem is the following:

I have an organization with many members. When someone from the outside communicates with this organization, I want any member to be able to decrypt the communication.

On solution I found would be to use CP-ABE: the organization has a master key and a public key related to it. The owner(s) of the organization can then issue secret keys for all members with a dummy policy that always evaluates to true. That way, an outsider won't have to know anything about the internal structure of the organization or its members; he will just have to encrypt using the organization's public key and any on its members will automatically be able to decrypt using his secret key.

The thing is that I really don't need all the attribute policy part of the CP-ABE so this seems overkill to me. I was wondering if there were any key derivation schemes that would allow me to do so, but I couldn't find any.

I remind my constraints:

  • the encryption should be done with a single public key for the whole organization
  • each member should have a different derived secret key

If there is such a scheme, how can we enforce key revocation ?

Improve this question
$\endgroup$
0

1 Answer 1

Reset to default
2
$\begingroup$

If key revocation is a requirement, that is, if Alice no longer works for BigCorp, her keys no longer is able to decrypt email to BigCorp, then it either becomes impractical or easy.

That is, you will need to do one of two things:

  • Either you need to update the master public key when Alice leaves. This is likely to be impractical.

  • You require Alice to work with some central body to do the decryption; the central body would verify Alice's employment as a part of the decryption process.

In the latter case, where we can assume a trusted central body, it becomes easy; have the central body hold the private key; it would either decrypt the message for Alice, or alternatively (for example, with RSA or IES), the central body could do a blinded decryption (and so the entity won't be able to track the message)

Improve this answer
$\endgroup$
3
  • $\begingroup$ In the second case, the scheme is useless indeed. But in my situation, I want Alice to be able to decrypt without any action from the holder of the authority (the holder of the master key). In that case, I'll have to either update the master key (and all secret keys) upon revocation, or maybe use some date attributes in the Ciphertext Policy to have expiration, and I'd still have to update all secret keys anyway $\endgroup$
    – bejito
    Commented May 24, 2018 at 15:37
  • $\begingroup$ @bejito: I'm not sure how a date attribute would work; if Alice needs to insert the date into the decryption process, she could just lie about the current date if she had been fired; if the decryption process gets the date from some trusted source, it's not clear how that would work (without getting into a centralized server, which you wanted to avoid) $\endgroup$
    – poncho
    Commented May 24, 2018 at 15:49
  • $\begingroup$ It's actually the authority that issues the secret key who issue it given a set of attributes - e.g. the expiry date. Then the encryptor encrypts using "current_date < expiry_date" in the policy, as he has incentive into not cheating (otherwise he could directly disclose the message to alice) $\endgroup$
    – bejito
    Commented May 24, 2018 at 16:21

Your Answer

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

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