You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Does the current boradcasting message sender also send the message to oneself through the NATS message layer? Should it be enhanced by filtering toself message locally?
Additionally, seems to me a reliable broadcasting is not yet implemented? This is a requirement for tss-lib downstream applications. With a broadcasting message received, downstream applications are required to verify the consistency of it, to prevent a malicious party that sending inconsistent messages.
Additionally, there should be a mechanism in your transport to allow for "reliable broadcasts", meaning parties can broadcast a message to other parties such that it's guaranteed that each one receives the same message. There are several examples of algorithms online that do this by sharing and comparing hashes of received messages
In a broadcasting scenario with three ndoes A,B and C, a sender A broadcast a message m to receiver B and C. Assume the message received are actually m_b and m_c for receiver B and C. We need to verify m_b = m_c = m, here a malicious sender could compose inconsistent m_b and m_c to the two receivers. The current scheme incorporate only sender's signature for each message he sent, but it doesn't check the received message consistency among receivers. So I plan to fix this, by using the strategy here: using p2p channel for broadcast messages, and before revealing any computation result, check all hashed concatenated broadcast messages beforehand, only if they are all equal accept the final result (signature).
hi @nann-cheng , but if a maliciuous actor send a forged message m_b or m_c to either B,C . will it break the tss session and existing nodes will throw error and abort the session? Even though that malicious actor can break the communication, will he be able to derive any secrets ?
If you mean wrong "commitment" in the broadcasting message to B or C, the following MPC round parties will surely pop out errors and cause abort. In some cases where if it's just a plain message that is not verified in the following rounds, then it's developer's responsibility to realize a robust broadcasting channel where malicious node is not able to send "inconsistent" message, the tss-lib based MPC protocol clearly states this in their protocol design.
No, normally broadcasting messages are masked random values, or commitments, public keys that can be public, thus, all malicious nodes wouldn't be able to learn any secrets, if the protocol aborts just on time.
For my first step next, I will use p2p channel for broadcasting, verify all messages among all nodes at the end of per protocol execution.
(function handleTssMessage) with the p2p channel (with consistency verification using msg digest) and apply for all TSS rounds while keeping the pubsub channel for other purposes for example event notifications? Correct me if I'm wrong
actually, using a broadcast channel is almost instant since it’s fire-and-forget. In contrast, a P2P channel typically requires opening a connection, waiting for a reply, and handling additional overhead, which can negatively impact performance.
I had half-finished replacing Pubchannel using directChannel (not the strict standard p2p channel as described by @anhthii ), which would perform consistency check at the very end before publishing any result to the client, this satisfies the definition of "a broadcasting channel"
I think the reason @nann-cheng chose the p2p channel for exchanging messages is because plain NATS pub/sub cannot guarantee message consistency — for example, a network partition could cause some parties to miss messages. Since TSS protocols require strict cryptographic guarantees where every participant must receive and process every round’s message correctly, a reliable p2p channel is more suitable.
Agree, performance impact could be negligible. I'm writing benchmark tool, so before any changes to the messaging layer, we will run benchmark to compare with the previous result. if it reduces performance significantly we will notice
Activity
nann-cheng commentedon Aug 12, 2025
Additionally, seems to me a reliable broadcasting is not yet implemented? This is a requirement for tss-lib downstream applications. With a broadcasting message received, downstream applications are required to verify the consistency of it, to prevent a malicious party that sending inconsistent messages.
nann-cheng commentedon Aug 13, 2025
To realize a broadcasting channel, I think the description is exactly what we need:
This is from page 13 of https://eprint.iacr.org/2023/602.pdf.
Please let me know if you agree with it, if so then I would like to improve our current implementation to it above.
anhthii commentedon Aug 13, 2025
hi @nann-cheng ,isn't this the ed25519 signature used in broacast message or something different?
nann-cheng commentedon Aug 13, 2025
In a broadcasting scenario with three ndoes A,B and C, a sender A broadcast a message m to receiver B and C. Assume the message received are actually m_b and m_c for receiver B and C. We need to verify m_b = m_c = m, here a malicious sender could compose inconsistent m_b and m_c to the two receivers. The current scheme incorporate only sender's signature for each message he sent, but it doesn't check the received message consistency among receivers. So I plan to fix this, by using the strategy here: using p2p channel for broadcast messages, and before revealing any computation result, check all hashed concatenated broadcast messages beforehand, only if they are all equal accept the final result (signature).
anhthii commentedon Aug 13, 2025
hi @nann-cheng , but if a maliciuous actor send a forged message m_b or m_c to either B,C . will it break the tss session and existing nodes will throw error and abort the session? Even though that malicious actor can break the communication, will he be able to derive any secrets ?
nann-cheng commentedon Aug 13, 2025
If you mean wrong "commitment" in the broadcasting message to B or C, the following MPC round parties will surely pop out errors and cause abort. In some cases where if it's just a plain message that is not verified in the following rounds, then it's developer's responsibility to realize a robust broadcasting channel where malicious node is not able to send "inconsistent" message, the tss-lib based MPC protocol clearly states this in their protocol design.
No, normally broadcasting messages are masked random values, or commitments, public keys that can be public, thus, all malicious nodes wouldn't be able to learn any secrets, if the protocol aborts just on time.
For my first step next, I will use p2p channel for broadcasting, verify all messages among all nodes at the end of per protocol execution.
anhthii commentedon Aug 13, 2025
Ok I see, thanks for clarifying. Please go ahead with the draft implementation.
lkyizhou1911 commentedon Aug 29, 2025
Hi @nann-cheng does this issue overlap with #78 ?
nann-cheng commentedon Aug 29, 2025
No, this is only about internal (among mpc ndoes) broadcasting message design
lkyizhou1911 commentedon Aug 29, 2025
As I understand, we should replace this:
(function handleTssMessage) with the p2p channel (with consistency verification using msg digest) and apply for all TSS rounds while keeping the pubsub channel for other purposes for example event notifications? Correct me if I'm wrong
anhthii commentedon Aug 29, 2025
actually, using a broadcast channel is almost instant since it’s fire-and-forget. In contrast, a P2P channel typically requires opening a connection, waiting for a reply, and handling additional overhead, which can negatively impact performance.
nann-cheng commentedon Aug 29, 2025
I had half-finished replacing Pubchannel using directChannel (not the strict standard p2p channel as described by @anhthii ), which would perform consistency check at the very end before publishing any result to the client, this satisfies the definition of "a broadcasting channel"
lkyizhou1911 commentedon Aug 29, 2025
I think the reason @nann-cheng chose the p2p channel for exchanging messages is because plain NATS pub/sub cannot guarantee message consistency — for example, a network partition could cause some parties to miss messages. Since TSS protocols require strict cryptographic guarantees where every participant must receive and process every round’s message correctly, a reliable p2p channel is more suitable.
lkyizhou1911 commentedon Aug 29, 2025
IMO in fintech systems consistency is generally more critical than performance? @anhthii
anhthii commentedon Aug 29, 2025
Agree, performance impact could be negligible. I'm writing benchmark tool, so before any changes to the messaging layer, we will run benchmark to compare with the previous result. if it reduces performance significantly we will notice