Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2021-10-09 📝 Original message: On Sat, Oct 09, 2021 at ...
📅 Original date posted:2021-10-09
📝 Original message:
On Sat, Oct 09, 2021 at 12:21:03PM +0000, Jonas Nick wrote:
> it seems like parts of this proposal rely on deterministic nonces in MuSig.
The "deterministic" nonces are combined with "recoverable" nonces via
musig2, so I think that part is a red-herring?
They're "deterministic" in the sense that the person who generated the
nonce needs to be able to recover the secret/dlog for the nonce later,
without having to store unique randomness for it. Thinking about it,
I think you could make the "deterministic" nonce secrets be
H( private-key, msg, other-party's-nonce-pair, 1 )
H( private-key, msg, other-party's-nonce-pair, 2 )
because you only need to recover the secret if the other party posts a
sig for a revoked transaction, in which case you can lookup their nonce
directly anyway. And you're choosing your "deterministic" nonce after
knowing what their ("revocable") nonce is, so can include it in the hash.
As far as the revocable nonce goes, you should only be generating a
single signature based on that, since that's used to finish things off
and post the tx on chain.
> Generally, this is insecure unless combined with heavy machinery that proves
> correctness of the nonce derivation in zero knowledge. If one signer uses
> deterministic nonces and another signer uses random nonces, then two signing
> sessions will have different challenge hashes which results in nonce reuse by
> the first signer [0]. Is there a countermeasure against this attack in the
> proposal? What are the inputs to the function that derive DA1, DA2? Is the
> assumption that a signer will not sign the same message more than once?
I had been thinking DA1,DA2 = f(seed,n) where n increases each round, but I
think the above would work and be an improvement. ie:
Bob has a shachain based secret generator, producing secrets s_0 to
s_(2**48). If you've seen s_0 to s_n, you only need to keep O(log(n))
of those values to regenerate all of them.
Bob generates RB1_n and RB2_n as H(s_n, 1)*G and H(s_n, 2)*G and sends
those values to Alice.
Alice determines the message (ie, the transaction), and sets da1_n
and da2_n as H(A_priv, msg, RB1_n, RB2_n, 1) and H(A_priv, msg, RB1_n,
RB2_n, 2). She then calculates k=H(da1_n, da2_n, RB1_n, RB2_n), and
signs for her nonce which da1_n+k*da2_n, and sends da1_n*G and
da2_n*G and the partial signature to Bob.
Bob checks and records Alice's musig2 derivation and partial signature,
but does not sign himself.
_If_ Bob wants to close the channel and publish the tx, he completes
the signature by signing with nonce RB1_n + k*RB2_n.
If you can convince Bob to close the channel repeatedly, using the
same nonce pair, then he'll have problems -- but if you can do that,
you can probably trick him into closing the channel with old state,
which gives him the same problems by design... Or that's my take.
> It may be worth pointing out that an adaptor signature scheme can not treat
> MuSig2 as a black box as indicated in the "Adaptor Signatures" section [1].
Hmm, you had me panicking that I'd been describing how to combine the
two despite having decided it wasn't necessary to combine them... :)
(I figured doing musig for k ptlcs for every update would get old fast --
if you maxed the channel out with ~400 inflight ptlcs you'd be exchanging
~800 nonces for every update. OTOH, I guess that's the only thing you'd
be saving, and the cost is ~176 bytes of extra witness data per ptlc...
Hmm...)
Cheers,
aj
Published at
2023-06-09 13:04:07Event JSON
{
"id": "9c70e67f01b5e887a9542f39cba38a6801b56493ca6370c832fbf8b31d389e5a",
"pubkey": "f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab",
"created_at": 1686315847,
"kind": 1,
"tags": [
[
"e",
"bfc4ed728b228b9341f3493f5bd7d935423e85bd9d039717f691001784a42238",
"",
"root"
],
[
"e",
"cb0bc2b2e0a14765139e83b32ad75a71dd854ea60bbb6f68e550288df9980be2",
"",
"reply"
],
[
"p",
"eae21eb28545b20116d940817b2995954758d0d5511695442681f035faabe60f"
]
],
"content": "📅 Original date posted:2021-10-09\n📝 Original message:\nOn Sat, Oct 09, 2021 at 12:21:03PM +0000, Jonas Nick wrote:\n\u003e it seems like parts of this proposal rely on deterministic nonces in MuSig.\n\nThe \"deterministic\" nonces are combined with \"recoverable\" nonces via\nmusig2, so I think that part is a red-herring?\n\nThey're \"deterministic\" in the sense that the person who generated the\nnonce needs to be able to recover the secret/dlog for the nonce later,\nwithout having to store unique randomness for it. Thinking about it,\nI think you could make the \"deterministic\" nonce secrets be\n\n H( private-key, msg, other-party's-nonce-pair, 1 )\n H( private-key, msg, other-party's-nonce-pair, 2 )\n\nbecause you only need to recover the secret if the other party posts a\nsig for a revoked transaction, in which case you can lookup their nonce\ndirectly anyway. And you're choosing your \"deterministic\" nonce after\nknowing what their (\"revocable\") nonce is, so can include it in the hash.\n\nAs far as the revocable nonce goes, you should only be generating a\nsingle signature based on that, since that's used to finish things off\nand post the tx on chain.\n\n\u003e Generally, this is insecure unless combined with heavy machinery that proves\n\u003e correctness of the nonce derivation in zero knowledge. If one signer uses\n\u003e deterministic nonces and another signer uses random nonces, then two signing\n\u003e sessions will have different challenge hashes which results in nonce reuse by\n\u003e the first signer [0]. Is there a countermeasure against this attack in the\n\u003e proposal? What are the inputs to the function that derive DA1, DA2? Is the\n\u003e assumption that a signer will not sign the same message more than once?\n\nI had been thinking DA1,DA2 = f(seed,n) where n increases each round, but I\nthink the above would work and be an improvement. ie:\n\n Bob has a shachain based secret generator, producing secrets s_0 to\n s_(2**48). If you've seen s_0 to s_n, you only need to keep O(log(n))\n of those values to regenerate all of them.\n\n Bob generates RB1_n and RB2_n as H(s_n, 1)*G and H(s_n, 2)*G and sends\n those values to Alice.\n\n Alice determines the message (ie, the transaction), and sets da1_n\n and da2_n as H(A_priv, msg, RB1_n, RB2_n, 1) and H(A_priv, msg, RB1_n,\n RB2_n, 2). She then calculates k=H(da1_n, da2_n, RB1_n, RB2_n), and\n signs for her nonce which da1_n+k*da2_n, and sends da1_n*G and\n da2_n*G and the partial signature to Bob.\n\n Bob checks and records Alice's musig2 derivation and partial signature,\n but does not sign himself.\n\n _If_ Bob wants to close the channel and publish the tx, he completes\n the signature by signing with nonce RB1_n + k*RB2_n.\n\nIf you can convince Bob to close the channel repeatedly, using the\nsame nonce pair, then he'll have problems -- but if you can do that,\nyou can probably trick him into closing the channel with old state,\nwhich gives him the same problems by design... Or that's my take.\n\n\u003e It may be worth pointing out that an adaptor signature scheme can not treat\n\u003e MuSig2 as a black box as indicated in the \"Adaptor Signatures\" section [1].\n\nHmm, you had me panicking that I'd been describing how to combine the\ntwo despite having decided it wasn't necessary to combine them... :)\n\n(I figured doing musig for k ptlcs for every update would get old fast --\nif you maxed the channel out with ~400 inflight ptlcs you'd be exchanging\n~800 nonces for every update. OTOH, I guess that's the only thing you'd\nbe saving, and the cost is ~176 bytes of extra witness data per ptlc...\nHmm...)\n\nCheers,\naj",
"sig": "d16f5e7946b8e2c4f7e3774362ae06f3113b9d1140f5792abbf9b4510f1afb865e5faf0b2e6fc585466119a7b8d05f9a277f0d54d9f946d3874060e11a7f9c5e"
}