2
$\begingroup$

In an application, I need to share a secret (random number) with a Group of known receivers over a public channel (a Blockchain) but each receiver needs to be able to check that the others received the same secret and if not will ignore the message. The problem is that the other receivers may not be online right now and thus an interactive protocol is not an option. The end goal is that all recipients get the same secret or all recipients ignore the message.

One solution I came up with is that after a recipient decrypted its part and received the secret he encrypts it with the public keys of the other recipients and checks that the cyphertext is the same, but this requires that the encryption scheme is deterministic but I only found probabilistic schemes and explanations why deterministic schemes are bad (but the concerns seem not to be a problem in my case as the plaintext is always a random number).

Is there a ready available deterministic asymmetric encryption scheme? In other parts of the system, I use ECDSA so if I could reuse these keys it would be optimal but adding another scheme would be possible as well. I'm not a cryptography expert and unless there is no other way I would like to avoid changing an existing scheme to make it deterministic.

Another option I found was using zero-knowledge proofs like SNARK, STARK or Bulletproofs but this seems like overkill and extremely complicated to pull off.

Are their other options I missed?

Improve this question
$\endgroup$
4
  • 1
    $\begingroup$ How can a receiver know if other receivers even have received the secret? $\endgroup$
    – AleksanderCH
    Apr 16, 2019 at 9:27
  • 1
    $\begingroup$ it's shared over a blockchain and because these are censorship resistance as soon as the message is included in a block and finalized by the consensus mechanism it is ensured that everybody has the same state (so all see the same messages). $\endgroup$
    – Markus Knecht
    Apr 16, 2019 at 9:49
  • $\begingroup$ Why not use a distributed coin flip protocol? $\endgroup$
    – Natanael
    Apr 16, 2019 at 18:29
  • $\begingroup$ These are interactive and generate a random number instead of sharing an existent secret, the result is publicly known $\endgroup$
    – Markus Knecht
    Apr 25, 2019 at 9:06

1 Answer 1

Reset to default
0
$\begingroup$

After looking a bit more into it I found a solution which I think should work. I combined ECDH with AES todo the following:

Message Generation

  1. I generate a new Elliptic Curve key pair (sesPk, sesSk)
  2. I generate a key for each receiver: key_i = ECDH(sesSk, receiverPk_i)
  3. I generate a message for each receiver: msg_i = AesEnc(key_i, sesSk||secret)
  4. I combine the messages: msg = sesPk||msg_0||...||msg_n

Secret Extraction

  1. I generate my key: key_i = ECDH(mySk, sesPk)
  2. I decrypt my message: sesSk||secret = AesDec(key_i, msg_i)

Secret Verification

  1. I generate all keys: key_i = ECDH(sesSk, receiverPk_i)
  2. I decrypt all messages: sesSk_i||secret_i = AesDec(key_i, msg_i)
  3. I verify that all received the same secret: secret == secret_0 == ... == secret_n
  4. I verify that all used the same session key: sesSk == sesSk_0 == ... == sesSk_n

Reminder

  • msg is shared over a blockchain so all receiver see the message or none does
  • receiverPks are known beforehand and thus are not included in msg but they could if necessary

If someone sees a weakness in this approach please share in the comments.

Improve this answer
$\endgroup$

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.