search

BlockstreamResearch / bip-frost-dkg

15 stars 7 forks source link

Implement Identifiable Aborts #32

Closed real-or-random closed 1 day ago

real-or-random commented 2 days ago
LLFourn commented 2 days ago

We actually specified a DLEQ proof a while ago for ECDSA adaptor signatures: https://github.com/discreetlogcontracts/dlcspecs/blob/master/ECDSA-adaptor.md#proving. It's implemented in libsecp256k1-zkp somewhere by @jesseposner.

I'm not sure you actually need a DLEQ proof. What's wrong with just MAC'ing the ciphertext and providing the shared secret? (I tl;dr'd the citations in the last issue).

Just to confirm this keygen+IA protocol would enlargen the message size back to quadratic in $n$ right or are we now sending the un-aggregated share encryptions in separate messages.

DLEQ oracle attack

It sounds like the recipients key in the ElGamal encryption that they can provide verifiable decryption for will be their static public key. This is very risky when combined with verifiable ElGamal decryption at least if done naively. I might have misunderstood but that's how I interpreted "ephemeral-static ECDH". If so this would let the a malicious coordinator turn an honest participant into a DH oracle for their static key by providing simulated ElGamal encryptions with the right encryption nonce. Perhaps what you had in mind already addresses this but I wanted to bring it up in case.

real-or-random commented 2 days ago

We actually specified a DLEQ proof a while ago for ECDSA adaptor signatures: discreetlogcontracts/dlcspecs@master/ECDSA-adaptor.md#proving. It's implemented in libsecp256k1-zkp somewhere by @jesseposner.

Oh crazy, I couldn't remember this :D https://github.com/BlockstreamResearch/secp256k1-zkp/pull/117 ... I should tell the other team who's working on DLEQ proofs...

I'm not sure you actually need a DLEQ proof. What's wrong with just MAC'ing the ciphertext and providing the shared secret? (I tl;dr'd the citations in the last issue).

Quoting myself from #9:

I don't see how some variant of committing symmetric encryption (e.g., add a hash MAC) would work, at least not without adding a round. The accusing participant could reveal the symmetric key to the coordinator, but if the accusing participant is malicious and reveals a garbage key, the coordinator doesn't know who's wrong and then the accused participant needs to exculpate herself by revealing the real key.

So the victim can reveal the derived symmetric key (or the ECDH shared point), but without a DLEQ proof, the victim can't convince the coordinator that it was the right one. I think revealing the symmetric key is good enough for proving to the coordinator "The ciphertext you have received from the sender decrypts to X (under the key I revealed, which is unique because the encryption is committing)", but not enough for "The ciphertext you have received from the sender fails to decrypt (under the key derived from ECDH)".

(Or am I wrong here?)

As I said, it can be fixed by adding a round, but that's not great. edit: I can't even be an optional round. The accused participant needs to make sure that they either reveal the key or sign the transcript, but never both. This needs an additional accusation round.

DLEQ oracle attack

that's how I interpreted "ephemeral-static ECDH".

I believe you interpreted it correctly. The sender generates an ephemeral key and the receiver has a static key. I guess ElGamal is more or less a synonym to "ephemeral-static ECDH", at least when used as a KEM.

Ugh, and thanks for pointing out the static-DH oracle... I hadn't really thought about this risk here, and we were a bit too enthusiastic here. This breaks the protocol immediately. A malicious coordinator can just send a nonce from a previous successful session and get the shared secret from the participant. And I don't see anything we could do about it.