If the clients only communicate through the server, then without prior knowledge of one another, such as gpg keys, no.
Otherwise, maybe they could both generate an RSA key. Then they would both encrypt a string of this format “<RANDOM_STRING>_<RSA_PRIVATE>”, and send that to the other. After receiving the other’s package, each one sends over their own private key. They can use this to decrypt the string, which both of them had chosen before knowing what the other had. They can use the string to decide who won based on predetermined rules.
I put the private key in the package because this way clients can check that it was in fact the key used to encrypt it in the first place. Faking that would require infinite computing power or quantum shenanigans, I suspect.
Also this is probably way overkill and has flaws I didn’t think of.
This! The prior knowledge is even fairly small, everyone can toss in a random string + key. The only drawback is that all participants need to have synchronized rounds (one for collecting the random values, one for the decryption keys), and the whole protocol fails if someone decides not send timely their decryption key
If the clients only communicate through the server, then without prior knowledge of one another, such as gpg keys, no.
Otherwise, maybe they could both generate an RSA key. Then they would both encrypt a string of this format “<RANDOM_STRING>_<RSA_PRIVATE>”, and send that to the other. After receiving the other’s package, each one sends over their own private key. They can use this to decrypt the string, which both of them had chosen before knowing what the other had. They can use the string to decide who won based on predetermined rules.
I put the private key in the package because this way clients can check that it was in fact the key used to encrypt it in the first place. Faking that would require infinite computing power or quantum shenanigans, I suspect.
Also this is probably way overkill and has flaws I didn’t think of.
This! The prior knowledge is even fairly small, everyone can toss in a random string + key. The only drawback is that all participants need to have synchronized rounds (one for collecting the random values, one for the decryption keys), and the whole protocol fails if someone decides not send timely their decryption key