📅 Original date posted:2023-07-26 🗒️ Summary of this message: The text ...

Lloyd Fournier [ARCHIVE] /

npub1khl…05yp

2023-07-28 15:08:07

in reply to nevent1q…kmgd

📅 Original date posted:2023-07-26
🗒️ Summary of this message: The text discusses the need for a secure blind schnorr signing service and the potential attacks that can occur without proof of knowledge of the signing key.
📝 Original message:
Hello all,

1. No proof of knowledge of each R does *NOT* prevent wagner's attack.
2. In my mind, A generic blind signing service is sufficient for doing
blinded MuSig, Muig2, FROST or whatever without the blind signing service
knowing. You don't need a specialized MuSig2 blind singing service to
extract MuSig2 compatible shares from it. You can just add the MuSig tweak
(and/or BIP32 etc) to their key when you do the blind signing request (this
seemed to be what the OP was suggesting). Making the server have multiple
nonces like in MuSig2 proper doesn't help the server's security at all. I
think the problem is simply reduced to creating a secure blind schnorr
signing service. Jonas mentioned some papers which show how to do that. The
question is mostly about whether you can practically integrate those tricks
into your protocol which might be tricky.

LL

On Thu, 27 Jul 2023 at 08:20, Erik Aronesty via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> correct. you cannot select R if it is shipped with a POP
>
> On Wed, Jul 26, 2023, 4:35 PM Tom Trevethan <tom at commerceblock.com> wrote:
>
>> Not 'signing' but 'secret' i.e. the r values (ephemeral keys). Proof of
>> knowledge of the r values used to generate each R used prevents the Wagner
>> attack, no?
>>
>> On Wed, Jul 26, 2023 at 8:59 PM Jonas Nick <jonasdnick at gmail.com> wrote:
>>
>>> None of the attacks mentioned in this thread so far (ZmnSCPxj mentioned
>>> an
>>> attack on the nonces, I mentioned an attack on the challenge c) can be
>>> prevented
>>> by proving knowledge of the signing key (usually known as proof of
>>> possession,
>>> PoP).
>>>
>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230727/4af404bf/attachment-0001.html>;

Author Public Key

npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05yp

Seen on

wss://relay.nostr.band

Show more details

Published at

2023-07-28 15:08:07

Kind type

1 Short Text Note

Event JSON

{ "id": "ebe67b64812d05b04d2e396fa33581c50bdf8b5584d209139e6be3ecea25d1df", "pubkey": "b5ff7c704f90e4eebfa414c0a017a84544c32586a1bd2fc86c74c2914d03c25e", "created_at": 1690556887, "kind": 1, "tags": [ [ "e", "86a87258a295f0e8a6ce06957ce368a6146cf45a73137d0af6fcc0729ce599a0", "", "root" ], [ "e", "96877d900e98a4be6d28e74b63c120eae9faa7649cbfb5de0d32f8b209557890", "", "reply" ], [ "p", "9b3cb9066a41d6c59c090531827defe6138e14f8b94a7802a8a183aa309a4e2b" ] ], "content": "📅 Original date posted:2023-07-26\n🗒️ Summary of this message: The text discusses the need for a secure blind schnorr signing service and the potential attacks that can occur without proof of knowledge of the signing key.\n📝 Original message:\nHello all,\n\n1. No proof of knowledge of each R does *NOT* prevent wagner's attack.\n2. In my mind, A generic blind signing service is sufficient for doing\nblinded MuSig, Muig2, FROST or whatever without the blind signing service\nknowing. You don't need a specialized MuSig2 blind singing service to\nextract MuSig2 compatible shares from it. You can just add the MuSig tweak\n(and/or BIP32 etc) to their key when you do the blind signing request (this\nseemed to be what the OP was suggesting). Making the server have multiple\nnonces like in MuSig2 proper doesn't help the server's security at all. I\nthink the problem is simply reduced to creating a secure blind schnorr\nsigning service. Jonas mentioned some papers which show how to do that. The\nquestion is mostly about whether you can practically integrate those tricks\ninto your protocol which might be tricky.\n\nLL\n\nOn Thu, 27 Jul 2023 at 08:20, Erik Aronesty via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e correct. you cannot select R if it is shipped with a POP\n\u003e\n\u003e On Wed, Jul 26, 2023, 4:35 PM Tom Trevethan \u003ctom at commerceblock.com\u003e wrote:\n\u003e\n\u003e\u003e Not 'signing' but 'secret' i.e. the r values (ephemeral keys). Proof of\n\u003e\u003e knowledge of the r values used to generate each R used prevents the Wagner\n\u003e\u003e attack, no?\n\u003e\u003e\n\u003e\u003e On Wed, Jul 26, 2023 at 8:59 PM Jonas Nick \u003cjonasdnick at gmail.com\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e None of the attacks mentioned in this thread so far (ZmnSCPxj mentioned\n\u003e\u003e\u003e an\n\u003e\u003e\u003e attack on the nonces, I mentioned an attack on the challenge c) can be\n\u003e\u003e\u003e prevented\n\u003e\u003e\u003e by proving knowledge of the signing key (usually known as proof of\n\u003e\u003e\u003e possession,\n\u003e\u003e\u003e PoP).\n\u003e\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230727/4af404bf/attachment-0001.html\u003e", "sig": "91694419665abadfc79cfe31368f0486f3268fbcafb826fbea04b8143b3b9d7d20458da4d993fb9e8947943689f5526579ed6b79ca2fe4514609179144b8d00b" }