search

bnb-chain / tss-lib

Threshold Signature Scheme, for ECDSA and EDDSA
MIT License
790 stars 271 forks source link

tss peers do not throw out the err when applying incorrect wiredMsg in keygen #98

Open froyobin opened 4 years ago

froyobin commented 4 years ago

We have 3 nodes, A,B,C that involved in the keygen.

after successfully run the first keygen , node A saved the wiredBytes from the previous keygen for the round binance.tss-lib.ecdsa.keygen.KGRound2Message2.

They run the keygen with same parties again.

in the round "binance.tss-lib.ecdsa.keygen.KGRound2Message2" node A broadcasts the wiredBytes that from the previous keygen request to the peers, and the peers accept this incorrect wiredBytes as partyInfo.Party.UpdateFromBytes return nil error. Since the peers applied the incorrect share, their outChannel cannot produce the wiredMsg for the round "binance.tss-lib.ecdsa.keygen.KGRound3Message", finally, the Tss process stuck there.

mungaij83 commented 3 years ago

This issue is affecting me as well. I can't move to round 2 if node x receives round 2 Message before round 1 message.

notatestuser commented 3 years ago

Hey @froyobin. As mentioned in the readme, in the transport layer sitting above tss-lib you should be using a 'session ID' in messages to differentiate the keygen sessions. The effect of this is that a message for a prior session should not even be able to reach tss-lib.

froyobin commented 3 years ago

@notatestuser Thank you for your reply, that make sense. I was thinking bout the scenario that the malicious nodes tamper the share and trying to send incorrect tss share to the victim with the session ID of this round.

notatestuser commented 3 years ago

@froyobin yeah. I think what you are looking for is covered in section 4.1 of the 2020 paper. The paper from 2018 that this lib implements does not provide identifiable aborts in keygen.

froyobin commented 3 years ago

@notatestuser Thank you. I will have a try with that one.