📅 Original date posted:2023-08-10
🗒️ Summary of this message: The sender is questioning the use of schnorr blind signatures in the statechain protocol and the potential for malicious signatures. They also suggest enforcing sequential blind signing to prevent attacks.
📝 Original message:
Hi Tom,
These questions might be wrongheaded since I'm not familiar enough with the
statechain protocol. Here goes:
Why do you need to use schnorr blind signatures for this? Are the blind
signatures being used to produce on-chain tx signatures or are they just
for credentials for transferring ownership (or are they for both). If they
are for on-chain txs then you won't be able to enforce that the signature
used was not generated maliciously so it doesn't seem to me like your trick
above would help you here. I can fully verify that the state chain
signatures were all produced non-maliciously but then there may be another
hidden forged signature that can take the on-chain funds that were produced
by malicious signing sessions I was never aware of (or how can you be sure
this isn't the case).
Following on from that point, is it not possible to enforce sequential
blind signing in the statechain protocol under each key. With that you
don't have the problem of wagner's attack.
LL
On Wed, 9 Aug 2023 at 23:34, Tom Trevethan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> @moonsettler
>
> When anyone receives a coin (either as payment or as part of a swap) they
> need to perform a verification of all previous signatures and
> corresponding backup txs. If anything is missing, then the verification
> will fail. So anyone 'breaking the chain' by signing something
> incorrectly simply cannot then send that coin on.
>
> The second point is important. All the 'transfer data' (i.e. new and all
> previous backup txs, signatures and values) is encrypted with the new owner
> public key. But the server cannot know this pubkey as this would enable it
> to compute the full coin pubkey and identify it on-chain. Currently, the
> server identifies individual coins (shared keys) with a statechain_id
> identifier (unrelated to the coin outpoint), which is used by the coin
> receiver to retrieve the transfer data via the API. But this means the
> receiver must be sent this identifier out-of-band by the sender, and also
> that if anyone else learns it they can corrupt the server key
> share/signature chain via the API. One solution to this is to have a second
> non-identifying key used only for authenticating with the server. This
> would mean a 'statchain address' would then be composed of 2 separate
> pubkeys 1) for the shared taproot address and 2) for server authentication.
>
> Thanks,
>
> Tom
>
> On Tue, Aug 8, 2023 at 6:44 PM moonsettler <moonsettler at protonmail.com>
> wrote:
>
>> Very nice! Is there an authentication mechanism to avoid 'breaking the
>> chain' with an unverifiable new state by a previous owner? Can the current
>> owner prove the knowledge of a non-identifying secret he learned as
>> recipient to the server that is related to the statechain tip?
>>
>> BR,
>> moonsettler
>>
>> ------- Original Message -------
>> On Monday, August 7th, 2023 at 2:55 AM, Tom Trevethan via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> A follow up to this, I have updated the blinded statechain protocol
>> description to include the mitigation to the Wagner attack by requiring the
>> server to send R1 values only after commitments made to the server of the
>> R2 values used by the user, and that all the previous computed c values are
>> verified by each new statecoin owner.
>> https://github.com/commerceblock/mercury/blob/master/layer/protocol.md
>>
>> Essentially, the attack is possible because the server cannot verify that
>> the blinded challenge (c) value it has been sent by the user has been
>> computed honestly (i.e. c = SHA256(X1 + X2, R1 + R2, m) ), however this CAN
>> be verified by each new owner of a statecoin for all the previous
>> signatures.
>>
>> Each time an owner cooperates with the server to generate a signature on
>> a backup tx, the server will require that the owner send a commitment to
>> their R2 value: e.g. SHA256(R2). The server will store this value before
>> responding with it's R1 value. This way, the owner cannot choose the value
>> of R2 (and hence c).
>>
>> When the statecoin is received by a new owner, they will receive ALL
>> previous signed backup txs for that coin from the sender, and all the
>> corresponding R2 values used for each signature. They will then ask the
>> server (for each previous signature), the commitments SHA256(R2) and the
>> corresponding server generated R1 value and c value used. The new owner
>> will then verify that each backup tx is valid, and that each c value was
>> computed c = SHA256(X1 + X2, R1 + R2, m) and each commitment equals
>> SHA256(R2). This ensures that a previous owner could not have generated
>> more valid signatures than the server has partially signed.
>>
>> On Thu, Jul 27, 2023 at 2:25 PM Tom Trevethan <tom at commerceblock.com>
>> wrote:
>>
>>>
>>> On Thu, Jul 27, 2023 at 9:08 AM Jonas Nick <jonasdnick at gmail.com> wrote:
>>>
>>>> No, proof of knowledge of the r values used to generate each R does not
>>>> prevent
>>>> Wagner's attack. I wrote
>>>>
>>>> > Using Wagner's algorithm, choose R2[0], ..., R2[K-1] such that
>>>> > c[0] + ... + c[K-1] = c[K].
>>>>
>>>> You can think of this as actually choosing scalars r2[0], ..., r2[K-1]
>>>> and
>>>> define R2[i] = r2[i]*G. The attacker chooses r2[i]. The attack wouldn't
>>>> make
>>>> sense if he didn't.
>>>>
>>>
>> _______________________________________________
> 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/20230810/ed54cc20/attachment.html>;
Lloyd Fournier [ARCHIVE] /
npub1kh…y05yp
2023-08-10 23:09:38
in reply to nevent1q…gw0f
Author Public Key
npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05ypPublished at
2023-08-10 23:09:38Event JSON
{
"id": "71ece3a4bd4db017a788f6fa84c01db3aa30d1025d3108ebe8ed5b6c112b24b5",
"pubkey": "b5ff7c704f90e4eebfa414c0a017a84544c32586a1bd2fc86c74c2914d03c25e",
"created_at": 1691708978,
"kind": 1,
"tags": [
[
"e",
"1a018f91ac3ac792f80718e8157e85b0d7e9d33cc45070bd861f4373935bd569",
"",
"root"
],
[
"e",
"ccd97f630c67bb2df0c051e675a4d068261572a80ed31b208231a2776c7a5ef9",
"",
"reply"
],
[
"p",
"e9a17810d0fc59d84aa22d2a51b1cd65e5bbd14973fa4945175edb9118f89f0c"
]
],
"content": "📅 Original date posted:2023-08-10\n🗒️ Summary of this message: The sender is questioning the use of schnorr blind signatures in the statechain protocol and the potential for malicious signatures. They also suggest enforcing sequential blind signing to prevent attacks.\n📝 Original message:\nHi Tom,\n\nThese questions might be wrongheaded since I'm not familiar enough with the\nstatechain protocol. Here goes:\n\nWhy do you need to use schnorr blind signatures for this? Are the blind\nsignatures being used to produce on-chain tx signatures or are they just\nfor credentials for transferring ownership (or are they for both). If they\nare for on-chain txs then you won't be able to enforce that the signature\nused was not generated maliciously so it doesn't seem to me like your trick\nabove would help you here. I can fully verify that the state chain\nsignatures were all produced non-maliciously but then there may be another\nhidden forged signature that can take the on-chain funds that were produced\nby malicious signing sessions I was never aware of (or how can you be sure\nthis isn't the case).\n\nFollowing on from that point, is it not possible to enforce sequential\nblind signing in the statechain protocol under each key. With that you\ndon't have the problem of wagner's attack.\n\nLL\n\nOn Wed, 9 Aug 2023 at 23:34, Tom Trevethan via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e @moonsettler\n\u003e\n\u003e When anyone receives a coin (either as payment or as part of a swap) they\n\u003e need to perform a verification of all previous signatures and\n\u003e corresponding backup txs. If anything is missing, then the verification\n\u003e will fail. So anyone 'breaking the chain' by signing something\n\u003e incorrectly simply cannot then send that coin on.\n\u003e\n\u003e The second point is important. All the 'transfer data' (i.e. new and all\n\u003e previous backup txs, signatures and values) is encrypted with the new owner\n\u003e public key. But the server cannot know this pubkey as this would enable it\n\u003e to compute the full coin pubkey and identify it on-chain. Currently, the\n\u003e server identifies individual coins (shared keys) with a statechain_id\n\u003e identifier (unrelated to the coin outpoint), which is used by the coin\n\u003e receiver to retrieve the transfer data via the API. But this means the\n\u003e receiver must be sent this identifier out-of-band by the sender, and also\n\u003e that if anyone else learns it they can corrupt the server key\n\u003e share/signature chain via the API. One solution to this is to have a second\n\u003e non-identifying key used only for authenticating with the server. This\n\u003e would mean a 'statchain address' would then be composed of 2 separate\n\u003e pubkeys 1) for the shared taproot address and 2) for server authentication.\n\u003e\n\u003e Thanks,\n\u003e\n\u003e Tom\n\u003e\n\u003e On Tue, Aug 8, 2023 at 6:44 PM moonsettler \u003cmoonsettler at protonmail.com\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e Very nice! Is there an authentication mechanism to avoid 'breaking the\n\u003e\u003e chain' with an unverifiable new state by a previous owner? Can the current\n\u003e\u003e owner prove the knowledge of a non-identifying secret he learned as\n\u003e\u003e recipient to the server that is related to the statechain tip?\n\u003e\u003e\n\u003e\u003e BR,\n\u003e\u003e moonsettler\n\u003e\u003e\n\u003e\u003e ------- Original Message -------\n\u003e\u003e On Monday, August 7th, 2023 at 2:55 AM, Tom Trevethan via bitcoin-dev \u003c\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e A follow up to this, I have updated the blinded statechain protocol\n\u003e\u003e description to include the mitigation to the Wagner attack by requiring the\n\u003e\u003e server to send R1 values only after commitments made to the server of the\n\u003e\u003e R2 values used by the user, and that all the previous computed c values are\n\u003e\u003e verified by each new statecoin owner.\n\u003e\u003e https://github.com/commerceblock/mercury/blob/master/layer/protocol.md\n\u003e\u003e\n\u003e\u003e Essentially, the attack is possible because the server cannot verify that\n\u003e\u003e the blinded challenge (c) value it has been sent by the user has been\n\u003e\u003e computed honestly (i.e. c = SHA256(X1 + X2, R1 + R2, m) ), however this CAN\n\u003e\u003e be verified by each new owner of a statecoin for all the previous\n\u003e\u003e signatures.\n\u003e\u003e\n\u003e\u003e Each time an owner cooperates with the server to generate a signature on\n\u003e\u003e a backup tx, the server will require that the owner send a commitment to\n\u003e\u003e their R2 value: e.g. SHA256(R2). The server will store this value before\n\u003e\u003e responding with it's R1 value. This way, the owner cannot choose the value\n\u003e\u003e of R2 (and hence c).\n\u003e\u003e\n\u003e\u003e When the statecoin is received by a new owner, they will receive ALL\n\u003e\u003e previous signed backup txs for that coin from the sender, and all the\n\u003e\u003e corresponding R2 values used for each signature. They will then ask the\n\u003e\u003e server (for each previous signature), the commitments SHA256(R2) and the\n\u003e\u003e corresponding server generated R1 value and c value used. The new owner\n\u003e\u003e will then verify that each backup tx is valid, and that each c value was\n\u003e\u003e computed c = SHA256(X1 + X2, R1 + R2, m) and each commitment equals\n\u003e\u003e SHA256(R2). This ensures that a previous owner could not have generated\n\u003e\u003e more valid signatures than the server has partially signed.\n\u003e\u003e\n\u003e\u003e On Thu, Jul 27, 2023 at 2:25 PM Tom Trevethan \u003ctom at commerceblock.com\u003e\n\u003e\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e On Thu, Jul 27, 2023 at 9:08 AM Jonas Nick \u003cjonasdnick at gmail.com\u003e wrote:\n\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e No, proof of knowledge of the r values used to generate each R does not\n\u003e\u003e\u003e\u003e prevent\n\u003e\u003e\u003e\u003e Wagner's attack. I wrote\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e \u003e Using Wagner's algorithm, choose R2[0], ..., R2[K-1] such that\n\u003e\u003e\u003e\u003e \u003e c[0] + ... + c[K-1] = c[K].\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e You can think of this as actually choosing scalars r2[0], ..., r2[K-1]\n\u003e\u003e\u003e\u003e and\n\u003e\u003e\u003e\u003e define R2[i] = r2[i]*G. The attacker chooses r2[i]. The attack wouldn't\n\u003e\u003e\u003e\u003e make\n\u003e\u003e\u003e\u003e sense if he didn't.\n\u003e\u003e\u003e\u003e\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/20230810/ed54cc20/attachment.html\u003e",
"sig": "6aa504c96561f4bd99fe2e25f9749b93a622afaafe4bed6686147a730ea82c7ec56703389cac5362ab6cf69732b8d60f611f378d0a975a62ec61edae50ee5f3e"
}