From jonasdnick at gmail.com  Sat Oct  9 12:21:03 2021
From: jonasdnick at gmail.com (Jonas Nick)
Date: Sat, 9 Oct 2021 12:21:03 +0000
Subject: [Lightning-dev] Lightning over taproot with PTLCs
In-Reply-To: <20211009011207.GA3984@erisian.com.au>
References: <20211009011207.GA3984@erisian.com.au>
Message-ID: <80140f82-daf5-09ea-42f6-c8bb1157a245@gmail.com>

Hi,

it seems like parts of this proposal rely on deterministic nonces in MuSig.
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?

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]. In
particular, generally the secret X must be input to the hash function that
generates nonce coefficient k. Otherwise, an attacker can grind through
challenge hashes by varying X without affecting the aggregate nonce and produce
a forgery. For the same reason, the message m is included in hash function
inputs of k. However, taking X into account when computing k shouldn't be an
issue for protocols making use of adaptor signatures because k does not need to
be determined before signing time and X is required to be known at that point
anyway.

[0] https://medium.com/blockstream/musig-dn-schnorr-multisignatures-with-verifiably-deterministic-nonces-27424b5df9d6
     See "The attack works as follows."
[1] MuSig2 adaptor signature issue: https://github.com/ElementsProject/scriptless-scripts/issues/23,
     PR: https://github.com/ElementsProject/scriptless-scripts/pull/24