Currently our implementors of ProtocolParticipant do not keep track of what round they are on. This introduces possible security flaw, where during the current round, a malicious participant could send a message from a previous round. Currently, the code will happily accept this message and process it, possibly overwriting existing messages.
There are some checks for certain rounds. For example, any round that requires messages/values from previous rounds will attempt to pull those values out of LocalStorage. If that value is missing the sub-protocol will fail. Messages meant for future rounds can also be stashed by the library.
Task
This will be an Epic to track the overall work. We should make individual tickets for each sub-protocol.
For each sub-protocol (more specifically, for any type that implements ProtocolParticipant) we should have a new variable that keeps track of the current round of the sub-protocol. When a round is finished, this variable should be updated. A check should be added to each ProtocolParticipant's process_message function (before match expression that dispatches messages to the correct round processing function) that ensures the message is meant for the current round, or for a future round [1]. This check should reject incorrect messages with an error.
Implementation: We should probably use a Rust enum to keep track of the current round. One enum would be defined per sub-protocol.
This should be implemented for the following sub-protocols:
[x] Key generation
[x] Auxinfo generation
[x] Pre-sign Record generation
[x] Interactive Signing
[x] ?Non-interactive Signing?
[x] Key Refresh
[ ] ?Broadcast?
Footnotes
[1] We should for sure reject messages from previous rounds, as these represent a duplicated message at best, and a malicious attack at worst.
It is less clear how to handle future messages: This is not always a bug or undesirable. For example, another participant may finish its current round and quickly send out messages for the next round, before we finish our current round.
The library already has support for stashing these messages. However, looking at the code, we stash any future messages, even if a Participant sends a round 3 message and it is only round 1. We may not want to allow this behavior...
Currently our implementors of
ProtocolParticipantdo not keep track of what round they are on. This introduces possible security flaw, where during the current round, a malicious participant could send a message from a previous round. Currently, the code will happily accept this message and process it, possibly overwriting existing messages.There are some checks for certain rounds. For example, any round that requires messages/values from previous rounds will attempt to pull those values out of
LocalStorage. If that value is missing the sub-protocol will fail. Messages meant for future rounds can also be stashed by the library.Task
This will be an Epic to track the overall work. We should make individual tickets for each sub-protocol.
For each sub-protocol (more specifically, for any type that implements
ProtocolParticipant) we should have a new variable that keeps track of the current round of the sub-protocol. When a round is finished, this variable should be updated. A check should be added to eachProtocolParticipant'sprocess_messagefunction (before match expression that dispatches messages to the correct round processing function) that ensures the message is meant for the current round, or for a future round [1]. This check should reject incorrect messages with an error.Implementation: We should probably use a Rust enum to keep track of the current round. One enum would be defined per sub-protocol.
This should be implemented for the following sub-protocols:
Footnotes
[1] We should for sure reject messages from previous rounds, as these represent a duplicated message at best, and a malicious attack at worst. It is less clear how to handle future messages: This is not always a bug or undesirable. For example, another participant may finish its current round and quickly send out messages for the next round, before we finish our current round. The library already has support for stashing these messages. However, looking at the code, we stash any future messages, even if a
Participantsends a round 3 message and it is only round 1. We may not want to allow this behavior...