The rogue public-key attack is a known problem for the BLS signature scheme. In this attack, an adversary can produce a valid aggregate signature for a given message that appears to be made by them and other honest participants. However, I can't seem to find anywhere in the documentation of this project if securities were implemented to preclude this attack.
Prove knowledge of the private key. I don't understand fully how this would work, but I assume that it could be achieved by doing a challenge every time a participant signs a message, in order to prove that they indeed own the private key. However, the overhead that must be added to each message because of this solution defeats the purpose of aggregate signatures, which is to have short and fixed-size signatures.
Force messages to be distinct, that is, reject all aggregate signatures that contain several individual signatures for the same message. However, this restriction prevents several applications of aggregate signatures (such as the one I'm interested in).
Use the modified BLS construction, which is presented in the post above, and which, from my perspective, seems to be the best solution against rogue public-key attacks, because it allows aggregate signatures for the same message without adding any overhead.
Was any of these solutions implemented in this project? It seems that we can aggregate signatures for the same message with this crate, so I don't think that solution 2 was implemented.
Besides, if signatures for the same message can be aggregated, would it be possible to implement in this crate the fast verification technique that is given in the post above?
When all the messages are the same (m_1 = … = m_n) the verification relation reduces to a simpler test that requires only two pairings:
e(g_1, sig) = e(pk_1...pk_n, H(m_1))
Hello,
The rogue public-key attack is a known problem for the BLS signature scheme. In this attack, an adversary can produce a valid aggregate signature for a given message that appears to be made by them and other honest participants. However, I can't seem to find anywhere in the documentation of this project if securities were implemented to preclude this attack.
The following post lists 3 defenses against this kind of attack: https://crypto.stanford.edu/~dabo/pubs/papers/BLSmultisig.html
Was any of these solutions implemented in this project? It seems that we can aggregate signatures for the same message with this crate, so I don't think that solution 2 was implemented.
Besides, if signatures for the same message can be aggregated, would it be possible to implement in this crate the fast verification technique that is given in the post above?