Protect against rogue key attack during key generation

Situation

Currently, Alice sends to Bob the following keys in alice::Message0:

Bitcoin public key A;
Monero public spend key S_a^xmr;
Bitcoin public key S_a^btc; and
Monero private view key v_a.

Bob replies with his own bob::Message0:

Bitcoin public key B;
Monero public spend key S_b^xmr;
Bitcoin public key S_b^btc; and
Monero private view key v_b.

I've been thinking about what Bob can do with the information in alice::Message0 before he commits to his own keys.

Possible attacks

Monero shared output

For instance, S_a^xmr + S_b^xmr is the public spend key of their Monero shared output, so Bob could theoretically adaptively choose his S_b^xmr = S_r - S_a^xmr, with knowledge of the the corresponding private key s_r for the rogue key S_r, so that when combined S_a^xmr + S_b^xmr = S_a^xmr + S_r - S_a^xmr = S_r giving control to Bob over the shared output immediately.

In practice, because we attach a DLEQ proof to bob::Message0 which proves knowledge of the secret key for S_b^xmr, Bob doesn't actually have the ability to choose a key that would cancel out Alice's, because he cannot compute the private key corresponding to the public key S_r - S_a^xmr thanks to the discrete log problem being hard.

I can't imagine this DLEQ proof ever being removed, so I would say this is safe.

It's worth noting that Bob could also exploit prior knowledge of S_a^btc in the same way. Similarly, Alice is protected by the DLEQ proof that Bob must provide which proves knowledge of s_b so that Bob cannot choose S_b^btc adaptively.

Bitcoin shared output

The Bitcoin shared output is not an aggregation of keys, but a multisignature Bitcoin script, so in its current state it is not susceptible to the same kind of rogue key attack.

On the other hand, this could change. As soon as BIP340 hits we would probably construct this output using Schnorr signatures to make the protocol truly scriptless. The output would be vulnerable to the rogue key attack outlined above and we would have to modify the protocol slightly.

Monero private view keys

The private view keys are already being exchanged publicly because there's nothing tricky to do with them.

Conclusion

In my opinion, the key generation phase is currently safe.

I still recommend we future-proof our protocol before it becomes too cumbersome to modify it. I think the Monero output will always remain protected by the required DLEQ proof, but the Bitcoin one would be vulnerable after a predictable upgrade to the protocol (i.e. using BIP340).

I would replace the current 2-round key generation phase with a 3-generation phase which uses a commitment scheme to protect Alice:

Alice sends commitment to her keys to Bob.
Bob sends his keys in the open to Alice.
Alice sends the opening of her commitment to Bob.

This is the same procedure we followed for our Grin-Bitcoin protocol. We could implement it in a similar way by sending a hash of all the keys concatenated in a particular order as the commitment.

comit-network / xmr-btc-swap