deterministic session_secrand32 for secp256k1_musig_nonce_gen

[scgbckbone]

Looking at bitcoind code, I can see they choose to to run secp256k1_musig_nonce_gen with session_secrand32 sourced from RNG & if not all pubnonces already provided in TX, bitcoind will store resulting secnonce in some structure in RAM as mapping from scriptPubkey+own_pubkey+signaturehash -> secnonce for later access during 2nd round. This seems to be the correct way accoring to specification in this repo:

 *  session_secrand32: a 32-byte session_secrand32 as explained above. Must be unique to this
 *                     call to secp256k1_musig_nonce_gen and must be uniformly
 *                     random. If the function call is successful, the
 *                     session_secrand32 buffer is invalidated to prevent reuse.

As secp256k1_musig_nonce_gen is pure function, I was considering, instead of storing secnonce for 2nd musig round (as my memory is very restricted), I could use for instance sha256(privkey||sighash) as session_secrand32 and re-run secp256k1_musig_nonce_gen in 2nd musig round to get pubnonce/secnonce pair deterministically. Having current input private key in the hash adds something that attacker must not know, while sighash is used to differentiate between different transactions (or inputs).

Can this or some deterministic variation of sha256(privkey||sighash) be considered secure ?

[real-or-random]

I could use for instance sha256(privkey||sighash) as session_secrand32 and re-run secp256k1_musig_nonce_gen in 2nd musig round to get pubnonce/secnonce pair deterministically. Having current input private key in the hash adds something that attacker must not know, while sighash is used to differentiate between different transactions (or inputs).

No, this is insecure.

You must not resign with the same secnonce. So what you describe is secure IF you guarantee that there will ever only one secp256k1_musig_partial_sign(..., secnonce, ...) call per secnonce value.

I don't see how you could guarantee this using sha256(privkey||sighash). If an attacker asks an honest signer for partial signatures in two different sessions for the same sighash, then the attacker can compute the seckey and it's game over. Note that the two sessions don't need to happen concurrently.

And you'd want to support more than one session for the same sighash: if the first session fails to complete, e.g., because one of the counterparties never produces a partial signature, you'll probably need some way to start a new session (because otherwise the coins will be stuck forever).

Are 32 bytes really too much?

Can this or some deterministic variation of sha256(privkey||sighash) be considered secure ?

Please see this section in BIP327: https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki#modifications-to-nonce-generation

[scgbckbone]

Are 32 bytes really too much?

32 bytes is just secrand. You need a way to find a proper secrand, so need to add some more (meta)data to the mapping (as bitcoind for instance), then you can have multiple keys for which you need to sign in single musig expression, multiple musig expressions in an input, and multiple inputs in the transaction...