3

I would like to share documents within groups and make sure that the member of each group can only access the documents shared in his/her group. I also want to make sure that non of the parties can cheat in the process of creating this architecture.

Situation:

enter image description here

There are 5 participants (A, B, C, D). There are two groups (blue: A, B, D, red: D, C). A and B can only see blue documents (like Document_1) and C can only see red documents (like Document_2). D can see documents shared in both groups.

Approach: The following approach is close to the approach in Tom Leeks answer and is close to OpenPGP. This approach is taken, because it scales to groups with many users.

Example for blue group:

  • A generates a key pair. Public key: pk_a. Private/secret key: sk_a
  • B generates key pair pk_b, sk_b
  • C generates key pair pk_c, sk_c
  • pk_a, pk_b, pk_c are posted to a key server, visible to the public
  • A (or any member of the blue group) generates a symmetric key s1
  • A calculates pk_b(s1) (s1 encrypted with pk_b) and pk_c(s1).
  • A posts pk_b(s1) and pk_c(s1) to the server
  • B and C can now take those values and decrypt them using theis sk
  • A, B, C now know S1 and can share data within the blue group
  • If they are posting data in the blue group, they can use their sk to indicate to the others that it was really send by them
  • we do the same for the red group with the symmetric key S2

Problem: How can we make sure that A actually send the correct symmetric key? A might want to exclude B and send pk_b(Sx) instead of pk_b(S1). B would be excluded of the communication.

Idea:

  • A is posting a random integer "to B" sk_a(pk_b(int)). To authenticate himself, he is encrypting it with his secret key
  • B takes that value increments it and posts it to C sk_b(pk_d(int + 1))
  • D is posting sk_d(pk_a(int + 2))
  • A can confirm that things are correct and that he indeed received his original integer, incremented by 2
  • A posts sk_a(pk_b(int + 3))
  • B can confirm that things are correct
  • B posts sk_b(pk_d(int + 4))
  • D can confirm that things are correct

Does this approach make sense? Is there a more elegant or efficient solution?

User12547645
  • 173
  • 8
  • This is an interesting question, +1. Though I think your problem is about threat models, not algorithms. You don't trust A, which implies the threat that A might be an adversary. A can jeopardize your system *after* the group has been initialized by publishing false information. Hence, preventing the "cheating" during the setup does not mitigate your threat. – marstato Nov 02 '18 at 11:21
  • I do not trust any of them (A, B, C). And if A is publishing wrong information after this process it is no big deal anymore. Every publication of data has tobeen be encrypted with the sk. Hence you will know who piblished wrong data. I am more worried about an evil party trying to exclude someone during the establishment of the communication. – User12547645 Nov 02 '18 at 12:39
  • And the process has to be distributed? I can see two possible scenarios making sense here. 1: A, B, C distrust each other but still want to share documents. In that case they need a third (or fourth if you want) party that is trusted by A, B and C. That party can set up the group and prevent cheating. 2: A, B and C trust each other but they need a third party for the sharing which they don't want (or need) to trust. In that case your proposed algorithm looks quite fine to me. – marstato Nov 02 '18 at 13:04
  • Yes, the process has to be distributed, because A, B, C do not trust a third party. They also do not trust each other. They want to communicate, but one of them might be compromised. – User12547645 Nov 02 '18 at 13:32
  • Because A, B, C do not trust/want a nother party to be involved, I distributed the process of the establishment of the infrastructure. After the proposed algorithm is finished they also know that they can trust each other. One of them might still send wrong data in the end, but at least they know that everyone really is who he is claiming to be and that nobody is left out of the conversation. – User12547645 Nov 02 '18 at 13:36
  • %s/synchronous/symmetric/g – user1686 Nov 02 '18 at 21:41
  • I do not get it – User12547645 Nov 03 '18 at 00:26
  • Your post repeatedly uses 'synchronous key'. There is no such thing in cryptography. The kind of key you want is 'symmetric key'. `%s/synchronous/symmetric/g` is the command to make that change using the [`ex/vi` editor or a derivative](https://en.wikipedia.org/wiki/Vi) which for decades have been the preferred editor(s) of much of the Unix community. – dave_thompson_085 Nov 03 '18 at 08:14
  • Thank you very much, @dave_thompson_085 I changed that. Of cause you were right abt that – User12547645 Nov 03 '18 at 12:32

1 Answers1

1

It sounds like you're trying to do multi-party key exchange for the purposes of broadcast encryption.

In your scenario you aren't trusting the users to send everyone in their group a valid symmetric key (S1), but you're trusting a key server to correctly list the public keys for all participants. If you presume the keyserver is trustworthy (it could lie to any one of the group members if it were malicious), then can't we also assign it the function of generating the symmetric key and disseminating it to the group?

Let's assume we can't trust the keyserver to generate the symmetric key and send it to all the group participants. The solution you proposed takes a lot of communication.

Here's my suggestion:

Group: A, B, D
A -> B: pk_b(NONCE), sk_a(hash(NONCE))
B -> D: pk_d(NONCE), sk_b(sk_a(hash(NONCE)))
D -> A: pk_a(NONCE), sk_d(sk_b(sk_a(hash(NONCE))))

The message A receives from D can be verified by using all the public keys to verify the chain of signatures.

Each participant can hash the NONCE they receive and check that it matches the hash signed by A.

Daisetsu
  • 5,110
  • 1
  • 14
  • 24