Bitcoin Mailing List on Nostr: 🔖 Title: Blinded 2-party Musig2 🏷️ Categories: bitcoin-dev ...

🔖 Title: Blinded 2-party Musig2
🏷️ Categories: bitcoin-dev

quoting naddr1qq…l4hh

📝 Summary: A version of 2-of-2 Schnorr Musig2 is being implemented for statechains, with the server fully blinded. Concerns are raised about the vulnerability of the scheme's single R per party. The discussion revolves around the security of blind MuSig schemes, potential attacks on nonces and challenges, and the need for proof of knowledge of signing keys. Alternative approaches for blind Schnorr signatures are proposed.

👥 Authors: • Andrew Poelstra ( <span itemprop="mentions" itemscope itemtype="https://schema.org/Person"><a itemprop="url" href="/npub1ae27kq6z802dkqw4ey4dgdx493szm8dpmcm76d7vt0ma9gf6fj4svz5t04" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1"><span>Andrew Poelstra [ARCHIVE]</span> (<span class="italic">npub1ae2…5t04</span>)</a></span> ) • AdamISZ ( <span itemprop="mentions" itemscope itemtype="https://schema.org/Person"><a itemprop="url" href="/npub1nv7tjpn2g8tvt8qfq5ccyl00ucfcu98ch998sq4g5xp65vy6fc4sykqw2t" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1"><span>AdamISZ [ARCHIVE]</span> (<span class="italic">npub1nv7…qw2t</span>)</a></span> ) • Erik Aronesty ( <span itemprop="mentions" itemscope itemtype="https://schema.org/Person"><a itemprop="url" href="/npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1"><span>Erik Aronesty [ARCHIVE]</span> (<span class="italic">npub1y22…taj0</span>)</a></span> ) • Tom Trevethan ( <span itemprop="mentions" itemscope itemtype="https://schema.org/Person"><a itemprop="url" href="/npub1axshsyxsl3vasj4z9549rvwdvhjmh52fw0ayj3ghtmdezx8cnuxqlwyw7n" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1"><span>Tom Trevethan [ARCHIVE]</span> (<span class="italic">npub1axs…yw7n</span>)</a></span> ) • ZmnSCPxj ( <span itemprop="mentions" itemscope itemtype="https://schema.org/Person"><a itemprop="url" href="/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1"><span>ZmnSCPxj [ARCHIVE]</span> (<span class="italic">npub1g5z…ms3l</span>)</a></span> ) • Jonas Nick ( <span itemprop="mentions" itemscope itemtype="https://schema.org/Person"><a itemprop="url" href="/npub1at3pav59gkeqz9kegzqhk2v4j4r435x42ytf23pxs8crt74tuc8s2y3z5a" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1"><span>Jonas Nick [ARCHIVE]</span> (<span class="italic">npub1at3…3z5a</span>)</a></span> )

📅 Messages Date Range: 2023-07-24 to 2023-07-26

✉️ Message Count: 20

📚 Total Characters in Messages: 58102

Messages Summaries

✉️ Message by Tom Trevethan on 24/07/2023: A version of 2-of-2 Schnorr Musig2 is being implemented for statechains, where the server is fully blinded and does not learn certain information. The security relies on the server reporting the number of partial signatures generated and verifying the signatures client-side. The protocol operates by generating private and public keys, aggregating the public keys, generating nonces, computing challenges, and creating the final signature. In the case of blinding for party 1, key aggregation and nonce aggregation are performed by party 2, and party 1 does not learn the final signature or the message being signed.

✉️ Message by ZmnSCPxj on 24/07/2023: MuSig2 requires multiple R points, preventing certain attacks. The recipient questions if the scheme's single R per party is vulnerable.

✉️ Message by Erik Aronesty on 24/07/2023: The text discusses the implementation of a version of 2-of-2 Schnorr Musig2 for statechains, where the server is fully blinded. The security relies on the server reporting the number of partial signatures generated and verifying the full set of signatures client-side. The protocol involves generating private and public keys, aggregating the public keys, and signing a message using nonces.

✉️ Message by Jonas Nick on 24/07/2023: The text discusses concerns about the proposed scheme for blind music and suggests an alternative approach that may be worth exploring.

✉️ Message by Erik Aronesty on 24/07/2023: The email discusses the potential vulnerabilities of a proposed scheme and suggests an alternative approach that may be worth exploring.

✉️ Message by Jonas Nick on 24/07/2023: The meaning and connection between "posk" and the attack remains unclear and undefined.

✉️ Message by Jonas Nick on 24/07/2023: Party 1 is unable to determine the final value of (R, s1+s2) or m, but a blinding step may be missing, allowing the server to scan the blockchain for signatures and compute corresponding hashes to check for a match.

✉️ Message by Tom Trevethan on 24/07/2023: The current statechain protocol requires the sender to sign the statechain with their public key, preventing rogue key attacks and ensuring server cooperation for spending.

✉️ Message by Tom Trevethan on 24/07/2023: The sender acknowledges that the full scheme should have multiple nonces and compute b, but it doesn't change the approach to blinding.

✉️ Message by AdamISZ on 24/07/2023: Wagner's attack is discussed in the conversation, and it is suggested that using the 3rd round of MuSig1 can help avoid it. There are also discussions about blind signing schemes and the need for proof of a well-formed signing request.

✉️ Message by Erik Aronesty on 25/07/2023: The discussion is about the security of the blind MuSig scheme and the potential vulnerabilities it may have.

✉️ Message by Tom Trevethan on 25/07/2023: The v=2 nonces signing protocol of musig2 prevents the Wagner attack. The challenge value c must be blinded from the server to prevent signature determination.

✉️ Message by Erik Aronesty on 26/07/2023: The author suggests that whenever a public key is transmitted, it should come with a "proof of secret key" to prevent vulnerabilities.

✉️ Message by Andrew Poelstra on 26/07/2023: POSK (proof of secret key) is not a perfect solution for preventing rogue key attacks and has logistical difficulties in implementation.

✉️ Message by Jonas Nick on 26/07/2023: Attacks on nonces and challenges cannot be prevented by proving knowledge of the signing key (proof of possession, PoP).

✉️ Message by Tom Trevethan on 26/07/2023: Proving knowledge of the r values used in generating each R can prevent the Wagner attack, not signing or secret keys.

✉️ Message by Erik Aronesty on 26/07/2023: The email discusses attacks on nonces and challenges in cryptography and the need for proof of knowledge of signing keys to prevent them.

✉️ Message by Tom Trevethan on 24/07/2023: The sender is discussing with Jonas the need for a method to blind the value of c in order to prevent the server from learning the value of m.

✉️ Message by Jonas Nick on 26/07/2023: Blind Schnorr signatures can solve the issue of blinding, but not the problem of client-controlled forged signatures. Recent work proposes alternative approaches for blind Schnorr signatures.

✉️ Message by AdamISZ on 26/07/2023: The protocol described in the text is an interesting idea for incorporating 2FA authentication into blind signing. However, there may be vulnerabilities in the protocol that need to be addressed.

Follow <span itemprop="mentions" itemscope itemtype="https://schema.org/Person"><a itemprop="url" href="/npub15g7m7mrveqlpfnpa7njke3ccghmpryyqsn87vg8g8eqvqmxd60gqmx08lk" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1"><span>Bitcoin Mailing List</span> (<span class="italic">npub15g7…08lk</span>)</a></span> for full threads

⚠️ Heads up! We've now started linking to replaceable long-form events (NIP-23), which allow for dynamic display of thread details like summaries, authors, and more. If you're unable to see this, your client may not support this feature yet.