{"type":"rich","version":"1.0","title":"Erik Aronesty [ARCHIVE] wrote","author_name":"Erik Aronesty [ARCHIVE] (npub1y2…5taj0)","author_url":"https://yabu.me/npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2023-07-26\n🗒️ Summary of this message: The author suggests that whenever a public key is transmitted, it should come with a \"proof of secret key\" to prevent vulnerabilities.\n📝 Original message:\npersonally, i think *any* time a public key is transmitted, it should come\nwith a \"proof of secret key\".   it should be baked-in to low level\nprotocols so that people don't accidentally create vulns.  alt discussion\nlink:  https://gist.github.com/RubenSomsen/be7a4760dd4596d06963d67baf140406\n\nOn Tue, Jul 25, 2023 at 5:18 PM Tom Trevethan via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Thanks for the replies. As I understand it, the v=2 nonces signing\n\u003e protocol of musig2 prevents the Wagner attack. Also, that the challenge\n\u003e value c must be blinded from the server to prevent the server from being\n\u003e able to determine the signature from the on-chain state.\n\u003e\n\u003e In addition, in order to update the server (party 1) keyshare when a\n\u003e statecoin is transferred between users, the key aggregation coefficient\n\u003e must be set to 1 for each key. The purpose of this coefficient in the\n\u003e Musig2 protocol is to prevent 'rogue key attacks' where one party can\n\u003e choose a public key derived from both their own secret key and the inverse\n\u003e of the other party's public key giving them the ability to unilaterally\n\u003e produce a valid signature over the aggregate key. However this can be\n\u003e prevented by the party producing a proof of knowledge of the private key\n\u003e corresponding to their supplied public key. This can be a signature, which\n\u003e is produced in any case by signing the statechain state in the mercury\n\u003e protocol. This signature must be verified by the receiver of a coin (who\n\u003e must also verify the server pubkey combines with the sender pubkey to get\n\u003e the coin address) which proves that the server is required to co-sign to\n\u003e generate any signature for this address.\n\u003e\n\u003e Here is a modified protocol:\n\u003e\n\u003e Keygen:\n\u003e\n\u003e Server generates private key x1 and public key X1 = x1.G and sends X1 to\n\u003e user (party 2)\n\u003e User generates private key x2 and public key X2 = x2.G and (random)\n\u003e blinding nonce z and computes the aggregate public key X = z.(X1 + X2)\n\u003e (server never learns of X, X2 or z).\n\u003e\n\u003e Signing:\n\u003e\n\u003e Server generates nonces r11 and r12 and R11 = r11.G and R12 = r12.G and\n\u003e sends R11 and R12 to the user.\n\u003e User generates nonces r21 and r22 and R21 = r21.G and R22 = r22.G\n\u003e User computes R1 = R11 + R21 and R2 = R12 + R22 and b = H(X,(R1,R2),m) and\n\u003e R = R1 + b.R2 and c = (X,R,m)\n\u003e User sends the values y = cz and b to the server.\n\u003e Server computes s1 = yx1 + r11 + br12 and sends it to the user.\n\u003e User computes s2 = yx2 + r21 + br22 and s = s1 + s2 and signature (s,R)\n\u003e\n\u003e Transfer:\n\u003e\n\u003e In a statecoin transfer, when receiving a statecoin, in order to verify\n\u003e that the coin address (i.e. aggregate public key) is shared correctly\n\u003e between the previous owner and the server, the client must verify the\n\u003e following:\n\u003e\n\u003e Retrieve the CURRENT public key from the server for this coin X1.\n\u003e Retrieve the public key X2 and the blinding nonce z from the sender.\n\u003e Verify that z.X1 + X2 = P the address of the statecoin.\n\u003e Verify that the sender has the private key used to generate X2: this is\n\u003e done by verifying the statechain signature over the receiver public key X3\n\u003e from X2.\n\u003e This proves that the address P was generated (aggregated) with the server\n\u003e and can only be signed with cooperation with the server, i.e. no previous\n\u003e owner can hold the full key.\n\u003e\n\u003e In order to update the key shares on transfer, the following protocol can\n\u003e be used:\n\u003e\n\u003e Server (party 1) generates a random blinding nonce e and sends it to user.\n\u003e User adds their private key to the nonce: t1 = e + x2\n\u003e Client sends t1 and z to the reciever as part of transfer_msg (encrypted\n\u003e with the receiver public key X3 = x3.G).\n\u003e Receiver client decrypts t1 and then subtracts their private key x3: t2 =\n\u003e e + x2 - x3.\n\u003e Receiver client sends t2 to the server as part of transfer_receiver.\n\u003e Server the updates the private key share x1_2 = x1 + t2 - e = x1 + e + x2\n\u003e - x3 - e = x1 + x2 - x3\n\u003e So now, x1_2 + x3 (the aggregation of the new server key share with the\n\u003e new client key share) is equal to x1 + x2 (the aggregation of the old\n\u003e server key share with the old client key share).\n\u003e The server deletes x1.\n\u003e\n\u003e On Tue, Jul 25, 2023 at 3:12 PM Erik Aronesty \u003cerik at q32.com\u003e wrote:\n\u003e\n\u003e\u003e posk is \"proof of secret key\".   so you cannot use wagner to select R\n\u003e\u003e\n\u003e\u003e On Mon, Jul 24, 2023 at 1:59 PM AdamISZ via bitcoin-dev \u003c\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e @ZmnSCPxj:\n\u003e\u003e\u003e\n\u003e\u003e\u003e yes, Wagner is the attack you were thinking of.\n\u003e\u003e\u003e\n\u003e\u003e\u003e And yeah, to avoid it, you should have the 3rd round of MuSig1, i.e. the\n\u003e\u003e\u003e R commitments.\n\u003e\u003e\u003e\n\u003e\u003e\u003e @Tom:\n\u003e\u003e\u003e As per above it seems you were more considering MuSig1 here, not MuSig2.\n\u003e\u003e\u003e At least in this version. So you need the initial commitments to R.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Jonas' reply clearly has covered a lot of what matters here, but I\n\u003e\u003e\u003e wanted to mention (using your notation):\n\u003e\u003e\u003e\n\u003e\u003e\u003e in s1 = c * a1 * x1 + r1, you expressed the idea that the challenge c\n\u003e\u003e\u003e could be given to the server, to construct s1, but since a1 = H(L, X1) and\n\u003e\u003e\u003e L is the serialization of all (in this case, 2) keys, that wouldn't work\n\u003e\u003e\u003e for blinding the final key, right?\n\u003e\u003e\u003e But, is it possible that this addresses the other problem?\n\u003e\u003e\u003e If the server is given c1*a1 instead as the challenge for signing (with\n\u003e\u003e\u003e their \"pure\" key x1), then perhaps it avoids the issue? Given what's on the\n\u003e\u003e\u003e blockchain ends up allowing calculation of 'c' and the aggregate key a1X1 +\n\u003e\u003e\u003e a2X2, is it the case that you cannot find a1 and therefore you cannot\n\u003e\u003e\u003e correlate the transaction with just the quantity 'c1*a1' which the server\n\u003e\u003e\u003e sees?\n\u003e\u003e\u003e\n\u003e\u003e\u003e But I agree with Jonas that this is just the start, i.e. the fundamental\n\u003e\u003e\u003e requirement of a blind signing scheme is there has to be some guarantee of\n\u003e\u003e\u003e no 'one more forgery' possibility, so presumably there has to be some proof\n\u003e\u003e\u003e that the signing request is 'well formed' (Jonas expresses it below as a\n\u003e\u003e\u003e ZKP of a SHA2 preimage .. it does not seem pretty but I agree that on the\n\u003e\u003e\u003e face of it, that is what's needed).\n\u003e\u003e\u003e\n\u003e\u003e\u003e @Jonas, Erik:\n\u003e\u003e\u003e 'posk' is probably meant as 'proof of secret key' which may(?) be a\n\u003e\u003e\u003e mixup with what is sometimes referred to in the literature as \"KOSK\" (iirc\n\u003e\u003e\u003e they used it in FROST for example). It isn't clear to me yet how that\n\u003e\u003e\u003e factors into this scenario, although ofc it is for sure a potential\n\u003e\u003e\u003e building block of these constructions.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Sent with Proton Mail secure email.\n\u003e\u003e\u003e\n\u003e\u003e\u003e ------- Original Message -------\n\u003e\u003e\u003e On Monday, July 24th, 2023 at 08:12, Jonas Nick via bitcoin-dev \u003c\n\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e \u003e Hi Tom,\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e I'm not convinced that this works. As far as I know blind musig is\n\u003e\u003e\u003e still an open\n\u003e\u003e\u003e \u003e research problem. What the scheme you propose appears to try to\n\u003e\u003e\u003e prevent is that\n\u003e\u003e\u003e \u003e the server signs K times, but the client ends up with K+1 Schnorr\n\u003e\u003e\u003e signatures for\n\u003e\u003e\u003e \u003e the aggregate of the server's and the clients key. I think it's\n\u003e\u003e\u003e possible to\n\u003e\u003e\u003e \u003e apply a variant of the attack that makes MuSig1 insecure if the nonce\n\u003e\u003e\u003e commitment\n\u003e\u003e\u003e \u003e round was skipped or if the message isn't determined before sending\n\u003e\u003e\u003e the nonce.\n\u003e\u003e\u003e \u003e Here's how a malicious client would do that:\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e - Obtain K R-values R1[0], ..., R1[K-1] from the server\n\u003e\u003e\u003e \u003e - Let\n\u003e\u003e\u003e \u003e R[i] := R1[i] + R2[i] for all i \u003c= K-1\n\u003e\u003e\u003e \u003e R[K] := R1[0] + ... + R1[K-1]\n\u003e\u003e\u003e \u003e c[i] := H(X, R[i], m[i]) for all i \u003c= K.\n\u003e\u003e\u003e \u003e Using Wagner's algorithm, choose R2[0], ..., R2[K-1] such that\n\u003e\u003e\u003e \u003e c[0] + ... + c[K-1] = c[K].\n\u003e\u003e\u003e \u003e - Send c[0], ..., c[K-1] to the server to obtain s[0], ..., s[K-1].\n\u003e\u003e\u003e \u003e - Let\n\u003e\u003e\u003e \u003e s[K] = s[0] + ... + s[K-1].\n\u003e\u003e\u003e \u003e Then (s[K], R[K]) is a valid signature from the server, since\n\u003e\u003e\u003e \u003e s[K]G = R[K] + c[K]a1X1,\n\u003e\u003e\u003e \u003e which the client can complete to a signature for public key X.\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e What may work in your case is the following scheme:\n\u003e\u003e\u003e \u003e - Client sends commitment to the public key X2, nonce R2 and message m\n\u003e\u003e\u003e to the\n\u003e\u003e\u003e \u003e server.\n\u003e\u003e\u003e \u003e - Server replies with nonce R1 = k1G\n\u003e\u003e\u003e \u003e - Client sends c to the server and proves in zero knowledge that c =\n\u003e\u003e\u003e \u003e SHA256(X1 + X2, R1 + R2, m).\n\u003e\u003e\u003e \u003e - Server replies with s1 = k1 + c*x1\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e However, this is just some quick intuition and I'm not sure if this\n\u003e\u003e\u003e actually\n\u003e\u003e\u003e \u003e works, but maybe worth exploring.\n\u003e\u003e\u003e \u003e _______________________________________________\n\u003e\u003e\u003e \u003e bitcoin-dev mailing list\n\u003e\u003e\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\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/20230726/b46458c8/attachment-0001.html\u003e"}