Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What are the securities against rogue public-key attacks? #57

Open
TimotheAlbouy opened this issue Sep 14, 2022 · 0 comments
Open

What are the securities against rogue public-key attacks? #57

TimotheAlbouy opened this issue Sep 14, 2022 · 0 comments

Comments

@TimotheAlbouy
Copy link

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

  1. 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.
  2. 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).
  3. 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))

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant