Profile: e9a17810...
📅 Original date posted:2023-07-26
🗒️ Summary of this message: The author proposes a solution to the blinding issue in a signature protocol and seeks feedback on its correctness.
📝 Original message:
Hi All,
I believe it's fairly simple to solve the blinding (sorry for the bastard notation!):
Signing:
X = X1 + X2
K1 = k1G
K2 = k2G
R = K1 + K2 + bX
e = hash(R||X||m)
e' = e + b
s = (k1 + e'*x1) + (k2 + e'*x2)
s = (k1 + k2 + b(x1 + x2)) + e(x1 + x2)
sG = (K1 + K2 + bX) + eX
sG = R + eX
Verification:
Rv = sG - eX
ev = hash(R||X||m)
e ?= ev
https://gist.github.com/moonsettler/05f5948291ba8dba63a3985b786233bb
Been trying to get a review on this for a while, please let me know if I got it wrong!
BR,
moonsettler
------- Original Message -------
On Monday, July 24th, 2023 at 5:39 PM, Jonas Nick via bitcoin-dev
> > Party 1 never learns the final value of (R,s1+s2) or m.
>
>
> Actually, it seems like a blinding step is missing. Assume the server (party 1)
> received some c during the signature protocol. Can't the server scan the
> blockchain for signatures, compute corresponding hashes c' = H(R||X||m) as in
> signature verification and then check c == c'? If true, then the server has the
> preimage for the c received from the client, including m.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
📅 Original date posted:2023-07-26
🗒️ Summary of this message: The scheme for blinding the challenge works well and doesn't require modifying the aggregated pubkey. The receiver of a statecoin would verify the signatures and transactions.
📝 Original message:
@moonsettler
Your scheme for blinding the challenge (e in your notation) works as far as
I can tell. It is better than the way I suggested as it doesn't require
modifying the aggregated pubkey (and the blinding nonce can be different
for each signature).
@AdamISZ and @Jonas
It is not necessarily the server that would need to verify that the
challenge is 'well formed', but the receiver of a statecoin. The concept of
having a blinded statechain server is that each signature generated for a
shared public key must be verified by the receiver of the corresponding
coin. So a receiver would retrieve the number of co-signings performed by
the server (K) and then verify each of the K signatures, and K transactions
that they have received from the sender. They can additionally verify that
each of the K R values has been correctly formed with a proof of secret
value for creating R2 (along with the R1 from the server).
-------------- next part --------------
An HTML attachment was scrubbed...
📅 Original date posted:2023-07-25
🗒️ Summary of this message: The discussion is about the security of the blind MuSig scheme and the potential vulnerabilities it may have.
📝 Original message:
posk is "proof of secret key". so you cannot use wagner to select R
On Mon, Jul 24, 2023 at 1:59 PM AdamISZ via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> @ZmnSCPxj:
>
> yes, Wagner is the attack you were thinking of.
>
> And yeah, to avoid it, you should have the 3rd round of MuSig1, i.e. the R
> commitments.
>
> @Tom:
> As per above it seems you were more considering MuSig1 here, not MuSig2.
> At least in this version. So you need the initial commitments to R.
>
> Jonas' reply clearly has covered a lot of what matters here, but I wanted
> to mention (using your notation):
>
> in s1 = c * a1 * x1 + r1, you expressed the idea that the challenge c
> could be given to the server, to construct s1, but since a1 = H(L, X1) and
> L is the serialization of all (in this case, 2) keys, that wouldn't work
> for blinding the final key, right?
> But, is it possible that this addresses the other problem?
> If the server is given c1*a1 instead as the challenge for signing (with
> their "pure" key x1), then perhaps it avoids the issue? Given what's on the
> blockchain ends up allowing calculation of 'c' and the aggregate key a1X1 +
> a2X2, is it the case that you cannot find a1 and therefore you cannot
> correlate the transaction with just the quantity 'c1*a1' which the server
> sees?
>
> But I agree with Jonas that this is just the start, i.e. the fundamental
> requirement of a blind signing scheme is there has to be some guarantee of
> no 'one more forgery' possibility, so presumably there has to be some proof
> that the signing request is 'well formed' (Jonas expresses it below as a
> ZKP of a SHA2 preimage .. it does not seem pretty but I agree that on the
> face of it, that is what's needed).
>
> @Jonas, Erik:
> 'posk' is probably meant as 'proof of secret key' which may(?) be a mixup
> with what is sometimes referred to in the literature as "KOSK" (iirc they
> used it in FROST for example). It isn't clear to me yet how that factors
> into this scenario, although ofc it is for sure a potential building block
> of these constructions.
>
> Sent with Proton Mail secure email.
>
> ------- Original Message -------
> On Monday, July 24th, 2023 at 08:12, Jonas Nick via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> > Hi Tom,
> >
> > I'm not convinced that this works. As far as I know blind musig is still
> an open
> > research problem. What the scheme you propose appears to try to prevent
> is that
> > the server signs K times, but the client ends up with K+1 Schnorr
> signatures for
> > the aggregate of the server's and the clients key. I think it's possible
> to
> > apply a variant of the attack that makes MuSig1 insecure if the nonce
> commitment
> > round was skipped or if the message isn't determined before sending the
> nonce.
> > Here's how a malicious client would do that:
> >
> > - Obtain K R-values R1[0], ..., R1[K-1] from the server
> > - Let
> > R[i] := R1[i] + R2[i] for all i <= K-1
> > R[K] := R1[0] + ... + R1[K-1]
> > c[i] := H(X, R[i], m[i]) for all i <= K.
> > Using Wagner's algorithm, choose R2[0], ..., R2[K-1] such that
> > c[0] + ... + c[K-1] = c[K].
> > - Send c[0], ..., c[K-1] to the server to obtain s[0], ..., s[K-1].
> > - Let
> > s[K] = s[0] + ... + s[K-1].
> > Then (s[K], R[K]) is a valid signature from the server, since
> > s[K]G = R[K] + c[K]a1X1,
> > which the client can complete to a signature for public key X.
> >
> > What may work in your case is the following scheme:
> > - Client sends commitment to the public key X2, nonce R2 and message m
> to the
> > server.
> > - Server replies with nonce R1 = k1G
> > - Client sends c to the server and proves in zero knowledge that c =
> > SHA256(X1 + X2, R1 + R2, m).
> > - Server replies with s1 = k1 + c*x1
> >
> > However, this is just some quick intuition and I'm not sure if this
> actually
> > works, but maybe worth exploring.
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> 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...
📅 Original date posted:2023-07-25
🗒️ Summary of this message: 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.
📝 Original message:
Thanks for the replies. As I understand it, the v=2 nonces signing protocol
of musig2 prevents the Wagner attack. Also, that the challenge value c must
be blinded from the server to prevent the server from being able to
determine the signature from the on-chain state.
In addition, in order to update the server (party 1) keyshare when a
statecoin is transferred between users, the key aggregation coefficient
must be set to 1 for each key. The purpose of this coefficient in the
Musig2 protocol is to prevent 'rogue key attacks' where one party can
choose a public key derived from both their own secret key and the inverse
of the other party's public key giving them the ability to unilaterally
produce a valid signature over the aggregate key. However this can be
prevented by the party producing a proof of knowledge of the private key
corresponding to their supplied public key. This can be a signature, which
is produced in any case by signing the statechain state in the mercury
protocol. This signature must be verified by the receiver of a coin (who
must also verify the server pubkey combines with the sender pubkey to get
the coin address) which proves that the server is required to co-sign to
generate any signature for this address.
Here is a modified protocol:
Keygen:
Server generates private key x1 and public key X1 = x1.G and sends X1 to
user (party 2)
User generates private key x2 and public key X2 = x2.G and (random)
blinding nonce z and computes the aggregate public key X = z.(X1 + X2)
(server never learns of X, X2 or z).
Signing:
Server generates nonces r11 and r12 and R11 = r11.G and R12 = r12.G and
sends R11 and R12 to the user.
User generates nonces r21 and r22 and R21 = r21.G and R22 = r22.G
User computes R1 = R11 + R21 and R2 = R12 + R22 and b = H(X,(R1,R2),m) and
R = R1 + b.R2 and c = (X,R,m)
User sends the values y = cz and b to the server.
Server computes s1 = yx1 + r11 + br12 and sends it to the user.
User computes s2 = yx2 + r21 + br22 and s = s1 + s2 and signature (s,R)
Transfer:
In a statecoin transfer, when receiving a statecoin, in order to verify
that the coin address (i.e. aggregate public key) is shared correctly
between the previous owner and the server, the client must verify the
following:
Retrieve the CURRENT public key from the server for this coin X1.
Retrieve the public key X2 and the blinding nonce z from the sender.
Verify that z.X1 + X2 = P the address of the statecoin.
Verify that the sender has the private key used to generate X2: this is
done by verifying the statechain signature over the receiver public key X3
from X2.
This proves that the address P was generated (aggregated) with the server
and can only be signed with cooperation with the server, i.e. no previous
owner can hold the full key.
In order to update the key shares on transfer, the following protocol can
be used:
Server (party 1) generates a random blinding nonce e and sends it to user.
User adds their private key to the nonce: t1 = e + x2
Client sends t1 and z to the reciever as part of transfer_msg (encrypted
with the receiver public key X3 = x3.G).
Receiver client decrypts t1 and then subtracts their private key x3: t2 = e
+ x2 - x3.
Receiver client sends t2 to the server as part of transfer_receiver.
Server the updates the private key share x1_2 = x1 + t2 - e = x1 + e + x2 -
x3 - e = x1 + x2 - x3
So now, x1_2 + x3 (the aggregation of the new server key share with the new
client key share) is equal to x1 + x2 (the aggregation of the old server
key share with the old client key share).
The server deletes x1.
On Tue, Jul 25, 2023 at 3:12 PM Erik Aronesty
> posk is "proof of secret key". so you cannot use wagner to select R
>
> On Mon, Jul 24, 2023 at 1:59 PM AdamISZ via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> @ZmnSCPxj:
>>
>> yes, Wagner is the attack you were thinking of.
>>
>> And yeah, to avoid it, you should have the 3rd round of MuSig1, i.e. the
>> R commitments.
>>
>> @Tom:
>> As per above it seems you were more considering MuSig1 here, not MuSig2.
>> At least in this version. So you need the initial commitments to R.
>>
>> Jonas' reply clearly has covered a lot of what matters here, but I wanted
>> to mention (using your notation):
>>
>> in s1 = c * a1 * x1 + r1, you expressed the idea that the challenge c
>> could be given to the server, to construct s1, but since a1 = H(L, X1) and
>> L is the serialization of all (in this case, 2) keys, that wouldn't work
>> for blinding the final key, right?
>> But, is it possible that this addresses the other problem?
>> If the server is given c1*a1 instead as the challenge for signing (with
>> their "pure" key x1), then perhaps it avoids the issue? Given what's on the
>> blockchain ends up allowing calculation of 'c' and the aggregate key a1X1 +
>> a2X2, is it the case that you cannot find a1 and therefore you cannot
>> correlate the transaction with just the quantity 'c1*a1' which the server
>> sees?
>>
>> But I agree with Jonas that this is just the start, i.e. the fundamental
>> requirement of a blind signing scheme is there has to be some guarantee of
>> no 'one more forgery' possibility, so presumably there has to be some proof
>> that the signing request is 'well formed' (Jonas expresses it below as a
>> ZKP of a SHA2 preimage .. it does not seem pretty but I agree that on the
>> face of it, that is what's needed).
>>
>> @Jonas, Erik:
>> 'posk' is probably meant as 'proof of secret key' which may(?) be a mixup
>> with what is sometimes referred to in the literature as "KOSK" (iirc they
>> used it in FROST for example). It isn't clear to me yet how that factors
>> into this scenario, although ofc it is for sure a potential building block
>> of these constructions.
>>
>> Sent with Proton Mail secure email.
>>
>> ------- Original Message -------
>> On Monday, July 24th, 2023 at 08:12, Jonas Nick via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>
>> > Hi Tom,
>> >
>> > I'm not convinced that this works. As far as I know blind musig is
>> still an open
>> > research problem. What the scheme you propose appears to try to prevent
>> is that
>> > the server signs K times, but the client ends up with K+1 Schnorr
>> signatures for
>> > the aggregate of the server's and the clients key. I think it's
>> possible to
>> > apply a variant of the attack that makes MuSig1 insecure if the nonce
>> commitment
>> > round was skipped or if the message isn't determined before sending the
>> nonce.
>> > Here's how a malicious client would do that:
>> >
>> > - Obtain K R-values R1[0], ..., R1[K-1] from the server
>> > - Let
>> > R[i] := R1[i] + R2[i] for all i <= K-1
>> > R[K] := R1[0] + ... + R1[K-1]
>> > c[i] := H(X, R[i], m[i]) for all i <= K.
>> > Using Wagner's algorithm, choose R2[0], ..., R2[K-1] such that
>> > c[0] + ... + c[K-1] = c[K].
>> > - Send c[0], ..., c[K-1] to the server to obtain s[0], ..., s[K-1].
>> > - Let
>> > s[K] = s[0] + ... + s[K-1].
>> > Then (s[K], R[K]) is a valid signature from the server, since
>> > s[K]G = R[K] + c[K]a1X1,
>> > which the client can complete to a signature for public key X.
>> >
>> > What may work in your case is the following scheme:
>> > - Client sends commitment to the public key X2, nonce R2 and message m
>> to the
>> > server.
>> > - Server replies with nonce R1 = k1G
>> > - Client sends c to the server and proves in zero knowledge that c =
>> > SHA256(X1 + X2, R1 + R2, m).
>> > - Server replies with s1 = k1 + c*x1
>> >
>> > However, this is just some quick intuition and I'm not sure if this
>> actually
>> > works, but maybe worth exploring.
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> _______________________________________________
>> 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...
📅 Original date posted:2023-07-26
🗒️ Summary of this message: Proving knowledge of the r values used in generating each R can prevent the Wagner attack, not signing or secret keys.
📝 Original message:
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
> 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).
>
-------------- next part --------------
An HTML attachment was scrubbed...
📅 Original date posted:2023-07-24
🗒️ Summary of this message: 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.
📝 Original message:
Hi Jonas,
Seems you are right: for every tx, compute c from the on-chain data, and
the server can match the c to the m (tx). So there would need to be a
method for blinding the value of c.
On Mon, Jul 24, 2023 at 4:39 PM Jonas Nick
> > Party 1 never learns the final value of (R,s1+s2) or m.
>
> Actually, it seems like a blinding step is missing. Assume the server
> (party 1)
> received some c during the signature protocol. Can't the server scan the
> blockchain for signatures, compute corresponding hashes c' = H(R||X||m) as
> in
> signature verification and then check c == c'? If true, then the server
> has the
> preimage for the c received from the client, including m.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230724/2bc0b366/attachment.html>
📅 Original date posted:2023-07-24
🗒️ Summary of this message: 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.
📝 Original message:
Hi Eric,
Yes, this was my thinking. The current statechain protocol requires that
the sender of a coin sign the statechain with their public key, which is
then verified by the receiver. The receiver also verifies that this
(sender) public key aggregated with the current server public key
corresponds to the public key (TR address) of the coin. This prevents a
'rogue key' attack by the sender and verifies that this coin cannot be
spent without cooperation of the server.
On Mon, Jul 24, 2023 at 3:25 PM Erik Aronesty
> as long as all parties provide a proof of secret key along with their
> public key, that should not be possible
>
> or you can do it as a two-step process where all parties provide a
> commitment to the public key and nobody reveals a public key until that
> commitment is received
>
> or if you want to be paranoid you can do both
>
> On Mon, Jul 24, 2023, 7:00 AM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Good morning Tom,
>>
>> Would this allow party 2 to itself be composed of N >= 2 parties?
>>
>> MuSig2 (as opposed to MuSig1) requires that signatories provide multiple
>> `R` points, not just one each, which are finally aggregated by first
>> combining them using the MuSig() public key compose function.
>> This prevents party 2 from creating an `R` that may allow it to perform
>> certain attacks whose name escapes me right now but which I used to know.
>> (it is the reason why MuSig1 requires 3 round trips, and why MuSig2
>> requires at least 2 `R` nonces per signatory)
>>
>> Your scheme has only one `R` per party, would it not be vulnerably to
>> that attack?
>>
>> Regards,
>> ZmnSCPxj
>>
>>
>> Sent with Proton Mail secure email.
>>
>> ------- Original Message -------
>> On Monday, July 24th, 2023 at 7:46 AM, Tom Trevethan via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>
>> > We are implementing a version of 2-of-2 Schnorr Musig2 for statechains
>> where the server (party 1 in the 2-of-2) will be fully 'blinded' - in that
>> it can hold a private key that is required to generate an aggregate
>> signature on an aggregate public key, but that it does not learn either: 1)
>> The aggregate public key 2) The aggregate signature and 3) The message (m)
>> being signed.
>> >
>> > In the model of blinded statechains, the security rests on the
>> statechain server being trusted to report the NUMBER of partial signatures
>> it has generated for a particular key (as opposed to being trusted to
>> enforce rules on WHAT it has signed in the unblinded case) and the full set
>> of signatures generated being verified client side
>> https://github.com/commerceblock/mercury/blob/master/doc/merc_blind.md#blinding-considerations
>> >
>> > Given the 2-of-2 musig2 protocol operates as follows (in the following
>> description, private keys (field elements) are denoted using lower case
>> letters, and elliptic curve points as uppercase letters. G is the generator
>> point and point multiplication denoted as X = xG and point addition as A =
>> G + G):
>> >
>> > Party 1 generates private key x1 and public key X1 = x1G. Party 2
>> generates private key x2 and public key X2 = x2G. The set of pubkeys is L =
>> {X1,X2}. The key aggregation coefficient is KeyAggCoef(L,X) = H(L,X). The
>> shared (aggregate) public key X = a1X1 + a2X2 where a1 = KeyAggCoef(L,X1)
>> and a2 = KeyAggCoef(L,X2).
>> >
>> > To sign a message m, party 1 generates nonce r1 and R1 = r1G. Party 2
>> generates nonce r2 and R2 = r2G. These are aggregated into R = R1 + R2.
>> >
>> > Party 1 then computes 'challenge' c = H(X||R||m) and s1 = c.a1.x1 + r1
>> > Party 2 then computes 'challenge' c = H(X||R||m) and s2 = c.a2.x2 + r2
>> >
>> > The final signature is then (R,s1+s2).
>> >
>> > In the case of blinding this for party 1:
>> >
>> > To prevent party 1 from learning of either the full public key or final
>> signature seems straightforward, if party 1 doesn't not need to
>> independently compute and verify c = H(X||R||m) (as they are blinded from
>> the message in any case).
>> >
>> > 1) Key aggregation is performed only by party 2. Party 1 just sends X1
>> to party 2.
>> > 2) Nonce aggregation is performed only by party 2. Party 1 just sends
>> R1 to party 2.
>> > 3) Party 2 computes c = H(X||R||m) and sends it to party 1 in order to
>> compute s1 = c.a1.x1 + r1
>> >
>> > Party 1 never learns the final value of (R,s1+s2) or m.
>> >
>> > Any comments on this or potential issues would be appreciated.
>> >
>> > Tom
>> _______________________________________________
>> 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...
📅 Original date posted:2023-07-24
🗒️ Summary of this message: The sender acknowledges that the full scheme should have multiple nonces and compute b, but it doesn't change the approach to blinding.
📝 Original message:
Hi ZmnSCPxj,
Yes, you are correct - the full scheme (
https://eprint.iacr.org/2020/1261.pdf) should have two or more nonces (and
also compute b). I don't think this changes the approach to blinding
however.
On Mon, Jul 24, 2023 at 11:50 AM ZmnSCPxj
> Good morning Tom,
>
> Would this allow party 2 to itself be composed of N >= 2 parties?
>
> MuSig2 (as opposed to MuSig1) requires that signatories provide multiple
> `R` points, not just one each, which are finally aggregated by first
> combining them using the MuSig() public key compose function.
> This prevents party 2 from creating an `R` that may allow it to perform
> certain attacks whose name escapes me right now but which I used to know.
> (it is the reason why MuSig1 requires 3 round trips, and why MuSig2
> requires at least 2 `R` nonces per signatory)
>
> Your scheme has only one `R` per party, would it not be vulnerably to that
> attack?
>
> Regards,
> ZmnSCPxj
>
>
> Sent with Proton Mail secure email.
>
> ------- Original Message -------
> On Monday, July 24th, 2023 at 7:46 AM, Tom Trevethan via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> > We are implementing a version of 2-of-2 Schnorr Musig2 for statechains
> where the server (party 1 in the 2-of-2) will be fully 'blinded' - in that
> it can hold a private key that is required to generate an aggregate
> signature on an aggregate public key, but that it does not learn either: 1)
> The aggregate public key 2) The aggregate signature and 3) The message (m)
> being signed.
> >
> > In the model of blinded statechains, the security rests on the
> statechain server being trusted to report the NUMBER of partial signatures
> it has generated for a particular key (as opposed to being trusted to
> enforce rules on WHAT it has signed in the unblinded case) and the full set
> of signatures generated being verified client side
> https://github.com/commerceblock/mercury/blob/master/doc/merc_blind.md#blinding-considerations
> >
> > Given the 2-of-2 musig2 protocol operates as follows (in the following
> description, private keys (field elements) are denoted using lower case
> letters, and elliptic curve points as uppercase letters. G is the generator
> point and point multiplication denoted as X = xG and point addition as A =
> G + G):
> >
> > Party 1 generates private key x1 and public key X1 = x1G. Party 2
> generates private key x2 and public key X2 = x2G. The set of pubkeys is L =
> {X1,X2}. The key aggregation coefficient is KeyAggCoef(L,X) = H(L,X). The
> shared (aggregate) public key X = a1X1 + a2X2 where a1 = KeyAggCoef(L,X1)
> and a2 = KeyAggCoef(L,X2).
> >
> > To sign a message m, party 1 generates nonce r1 and R1 = r1G. Party 2
> generates nonce r2 and R2 = r2G. These are aggregated into R = R1 + R2.
> >
> > Party 1 then computes 'challenge' c = H(X||R||m) and s1 = c.a1.x1 + r1
> > Party 2 then computes 'challenge' c = H(X||R||m) and s2 = c.a2.x2 + r2
> >
> > The final signature is then (R,s1+s2).
> >
> > In the case of blinding this for party 1:
> >
> > To prevent party 1 from learning of either the full public key or final
> signature seems straightforward, if party 1 doesn't not need to
> independently compute and verify c = H(X||R||m) (as they are blinded from
> the message in any case).
> >
> > 1) Key aggregation is performed only by party 2. Party 1 just sends X1
> to party 2.
> > 2) Nonce aggregation is performed only by party 2. Party 1 just sends R1
> to party 2.
> > 3) Party 2 computes c = H(X||R||m) and sends it to party 1 in order to
> compute s1 = c.a1.x1 + r1
> >
> > Party 1 never learns the final value of (R,s1+s2) or m.
> >
> > Any comments on this or potential issues would be appreciated.
> >
> > Tom
>
-------------- next part --------------
An HTML attachment was scrubbed...
📅 Original date posted:2023-07-24
🗒️ Summary of this message: 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.
📝 Original message:
Hi Eric,
Yes, this was my thinking. The current statechain protocol requires that
the sender of a coin sign the statechain with their public key, which is
then verified by the receiver. The receiver also verifies that this
(sender) public key aggregated with the current server public key
corresponds to the public key (TR address) of the coin. This prevents a
'rogue key' attack by the sender and verifies that this coin cannot be
spent without cooperation of the server.
On Mon, Jul 24, 2023 at 3:25 PM Erik Aronesty
> as long as all parties provide a proof of secret key along with their
> public key, that should not be possible
>
> or you can do it as a two-step process where all parties provide a
> commitment to the public key and nobody reveals a public key until that
> commitment is received
>
> or if you want to be paranoid you can do both
>
> On Mon, Jul 24, 2023, 7:00 AM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Good morning Tom,
>>
>> Would this allow party 2 to itself be composed of N >= 2 parties?
>>
>> MuSig2 (as opposed to MuSig1) requires that signatories provide multiple
>> `R` points, not just one each, which are finally aggregated by first
>> combining them using the MuSig() public key compose function.
>> This prevents party 2 from creating an `R` that may allow it to perform
>> certain attacks whose name escapes me right now but which I used to know.
>> (it is the reason why MuSig1 requires 3 round trips, and why MuSig2
>> requires at least 2 `R` nonces per signatory)
>>
>> Your scheme has only one `R` per party, would it not be vulnerably to
>> that attack?
>>
>> Regards,
>> ZmnSCPxj
>>
>>
>> Sent with Proton Mail secure email.
>>
>> ------- Original Message -------
>> On Monday, July 24th, 2023 at 7:46 AM, Tom Trevethan via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>
>> > We are implementing a version of 2-of-2 Schnorr Musig2 for statechains
>> where the server (party 1 in the 2-of-2) will be fully 'blinded' - in that
>> it can hold a private key that is required to generate an aggregate
>> signature on an aggregate public key, but that it does not learn either: 1)
>> The aggregate public key 2) The aggregate signature and 3) The message (m)
>> being signed.
>> >
>> > In the model of blinded statechains, the security rests on the
>> statechain server being trusted to report the NUMBER of partial signatures
>> it has generated for a particular key (as opposed to being trusted to
>> enforce rules on WHAT it has signed in the unblinded case) and the full set
>> of signatures generated being verified client side
>> https://github.com/commerceblock/mercury/blob/master/doc/merc_blind.md#blinding-considerations
>> >
>> > Given the 2-of-2 musig2 protocol operates as follows (in the following
>> description, private keys (field elements) are denoted using lower case
>> letters, and elliptic curve points as uppercase letters. G is the generator
>> point and point multiplication denoted as X = xG and point addition as A =
>> G + G):
>> >
>> > Party 1 generates private key x1 and public key X1 = x1G. Party 2
>> generates private key x2 and public key X2 = x2G. The set of pubkeys is L =
>> {X1,X2}. The key aggregation coefficient is KeyAggCoef(L,X) = H(L,X). The
>> shared (aggregate) public key X = a1X1 + a2X2 where a1 = KeyAggCoef(L,X1)
>> and a2 = KeyAggCoef(L,X2).
>> >
>> > To sign a message m, party 1 generates nonce r1 and R1 = r1G. Party 2
>> generates nonce r2 and R2 = r2G. These are aggregated into R = R1 + R2.
>> >
>> > Party 1 then computes 'challenge' c = H(X||R||m) and s1 = c.a1.x1 + r1
>> > Party 2 then computes 'challenge' c = H(X||R||m) and s2 = c.a2.x2 + r2
>> >
>> > The final signature is then (R,s1+s2).
>> >
>> > In the case of blinding this for party 1:
>> >
>> > To prevent party 1 from learning of either the full public key or final
>> signature seems straightforward, if party 1 doesn't not need to
>> independently compute and verify c = H(X||R||m) (as they are blinded from
>> the message in any case).
>> >
>> > 1) Key aggregation is performed only by party 2. Party 1 just sends X1
>> to party 2.
>> > 2) Nonce aggregation is performed only by party 2. Party 1 just sends
>> R1 to party 2.
>> > 3) Party 2 computes c = H(X||R||m) and sends it to party 1 in order to
>> compute s1 = c.a1.x1 + r1
>> >
>> > Party 1 never learns the final value of (R,s1+s2) or m.
>> >
>> > Any comments on this or potential issues would be appreciated.
>> >
>> > Tom
>> _______________________________________________
>> 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...