3

This is a real-life encryption problem that came up today, and I haven't been able to determine a solution. In essence:

1. Alice can encrypt payloads using Carol's public* key.
2. Bob cannot encrypt or decrypt messages to/from Carol.
3. Alice cannot deliver messages to Carol without Bob's permission.
4. Bob only gives permission to Alice if he agrees with the content of the payload. 

* Carol's public key is given only to Alice, and is done so both offline and securely.

The goal is so that neither Alice or Bob can be malicious alone in this scenario. If they collaborate and are malicious to Carol, so be it. We can also add any extra encryption, as long as we don't bend the rules too much, especially with Carol who is an outside entity.

Point 1 is no problem, since Alice has the public Key.
Point 2 is no problem, since only Alice was given the Key.
Point 3 is simple, due to the implementation of a separate communication channel that Bob has with Carol and Alice does not.
Point 4 is where the problem lies.

Failed solutions:
1. Give Carol's private key to Bob. In doing so, Bob can confirm the message that Alice has created. However, we are unable to get Carol's private key.
2. Give Bob a method of generating Alice's payload from the plaintext, AKA with Carol's public key. This however breaks point 2, since now Bob can generate messages without Alice.

I feel like the solution to the problem will be similar to failed solution #2, with a way of giving Bob both the plain-text and the payload, as well as some sort of supporting document that confirms the two are the same.

Improve this question
2
  • Keeping a public key as a secret contradicts the principle of asymmetric encryption and is not a feasible approach to implement your scenario.
    – not2savvy
    Commented Jul 5, 2019 at 11:10
  • @not2savvy, While in general that is true, in our specific set of circumstances we can guarantee that Carol's public key is accessible sparingly. That is, to get Carol's public key, there will be an audit left behind, and in doing so is considered malicious.
    – DBADave
    Commented Jul 5, 2019 at 11:46

1 Answer 1

Reset to default
3

You need to use signatures instead of encryption.

Eg. Alice signs a message with her private key and optionally encrypys it with Bobs key. Bob decrypts the message (if encrypted), signs it, opyionally encrypys it with Carols public key and sends it to Carol. Carol checks that the message is signed by both Alice and Bob.

Improve this answer
4
  • In this case, we cannot ask that Carol does dual signature verification. However, that solution will work as long as we introduce an intermediary, Sam. Sam will verify the signatures, then encrypt the message for Carol. Carol will now confirm the message came from Sam instead of Alice. Thanks!
    – DBADave
    Commented Jul 5, 2019 at 10:54
  • 1
    You shouldn’t accept answers that quickly. There might be better ways to solve this, but the fact that you already have accepted the answer could discourage others from providing alternative answers.
    – not2savvy
    Commented Jul 5, 2019 at 12:07
  • @not2savvy interesting observation. However, using signatures for authentization of messages is the industey standard seing as that is exactly what signatures were made for. As for using Sam as intermediary, I think it should be mostly OK, though using encryption as authentication has its problems that you probably should be aware of.... Please study up on them.
    – Peter Harmann
    Commented Jul 5, 2019 at 13:29
  • @PeterHarmann I absolutely don’t disagree with you on using signatures for this purpose in general. However, I think there might be a better than the proposed (and accepted) implementation.
    – not2savvy
    Commented Jul 5, 2019 at 13:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .