<p>Alternative answers as always are welcome.</p>
<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#design" rel="nofollow noreferrer">BIP340</a> does actually (at least partially) answer this.</p>
<p>Key prefixes were included in the design of BIP340 Schnorr signatures as without them &quot;related key attacks&quot; (e.g. attacks with BIP32 unhardened derived keys) are possible. Related key attacks are where you are able to produce a signature for a BIP32 unhardened derived child key without access to that key if you have the signature of that same message from the parent key.</p>
<blockquote>
<p>a third party can convert a signature (R, s) for public key P into a signature (<code>R, s + a⋅hash(R || m)</code>) for public key <code>P + a⋅G</code> and the same message m, for any given additive tweak a to the signing key. This would render signatures insecure when keys are generated using BIP32's unhardened derivation and other methods that rely on additive tweaks to existing keys such as Taproot.</p>
</blockquote>
<p>Key prefixes are defined in BIP340 as:</p>
<blockquote>
<p>...we choose key prefixed Schnorr signatures which means that the public key is prefixed to the message in the challenge hash input. This changes the equation to:</p>
<p><code>s⋅G = R + hash(R || P || m)⋅P</code>.</p>
<p>It can be shown that key prefixing protects against related-key attacks with additive tweaks. In general, key prefixing increases robustness in multi-user settings, e.g., it seems to be a requirement for proving the MuSig multisignature scheme secure (see Applications below).</p>
</blockquote>
<p>BIP340 also links to this <a href="https://eprint.iacr.org/2015/1135.pdf" rel="nofollow noreferrer">paper</a> (On the Security of the Schnorr Signature Scheme and DSA against Related-Key Attacks).</p>
<blockquote>
<p>Is it hardened or non hardened derivation (or both) that are relevant here?</p>
</blockquote>
<p>As far as I can work out hardened BIP32 derivation isn't affected by related key attacks or any other security concerns so we are only concerned with unhardened BIP32 derivation when designing secure key aggregation multisig and threshold schemes like MuSig(2) and FROST. The design of these schemes are obviously constrained by the design decisions in BIP340 as they need to generate valid BIP340 public keys and be able to produce valid BIP340 signatures under the rules of SegWit version 1.</p>

CC BY-SA 4.0
2022-10-10T10:12:10.793Z
2022-10-10T15:41:29.080Z
2022-10-10T15:41:29.080Z
Michael Folkson
<p>I have seen it discussed in various places (e.g. <a href="https://btctranscripts.com/london-bitcoin-devs/2022-08-11-tim-ruffing-musig2/#speedymusig-and-proofs-of-possession" rel="nofollow noreferrer">1</a>, <a href="https://btctranscripts.com/mit-bitcoin-expo/mit-bitcoin-expo-2019/signature-scheme-security-properties/#qa" rel="nofollow noreferrer">2</a>) that using BIP32 key derivation impacts the design of secure key aggregation multisig and threshold schemes like MuSig(2) and FROST.</p>
<p>What are the relevant security concerns here? Is it hardened or non hardened derivation (or both) that are relevant here? Is BIP32 key derivation one of the reasons why Bitcoin design decisions are often different to those made in research papers without a focus on Bitcoin?</p>

CC BY-SA 4.0
2022-09-22T08:15:49.803Z
I cross-posted this question here: https://www.satsoverflow.io/questions/fa5fa7002060403389fcb805cd5d18c8
yzernik
<multi-signature><bip32-hd-wallets><schnorr-signatures><musig><frost>
To what extent does BIP32 key derivation impact the design of secure key aggregation multisig and threshold schemes like MuSig and FROST?
Michael Folkson
# To what extent does BIP32 key derivation impact the design of secure key aggregation multisig and threshold schemes like MuSig and FROST?

(Asked by: username_0 on 2022-09-21)

I have seen it discussed in various places (e.g. [1](https://btctranscripts.com/london-bitcoin-devs/2022-08-11-tim-ruffing-musig2/#speedymusig-and-proofs-of-possession), [2](https://btctranscripts.com/mit-bitcoin-expo/mit-bitcoin-expo-2019/signature-scheme-security-properties/#qa)) that using BIP32 key derivation impacts the design of secure key aggregation multisig and threshold schemes like MuSig(2) and FROST.

What are the relevant security concerns here? Is it hardened or non hardened derivation (or both) that are relevant here? Is BIP32 key derivation one of the reasons why Bitcoin design decisions are often different to those made in research papers without a focus on Bitcoin?

**Tags:** multi-signature, bip32-hd-wallets, schnorr-signatures, musig, frost

> **Comments:**
> **username_1**: I cross-posted this question here: https://www.satsoverflow.io/questions/fa5fa7002060403389fcb805cd5d18c8  

---

## 1 answers

### Answer by username_0 on 2022-10-10. Score: 1

Alternative answers as always are welcome.

[BIP340](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#design) does actually (at least partially) answer this.

Key prefixes were included in the design of BIP340 Schnorr signatures as without them "related key attacks" (e.g. attacks with BIP32 unhardened derived keys) are possible. Related key attacks are where you are able to produce a signature for a BIP32 unhardened derived child key without access to that key if you have the signature of that same message from the parent key.

> a third party can convert a signature (R, s) for public key P into a signature (`R, s + a⋅hash(R || m)`) for public key `P + a⋅G` and the same message m, for any given additive tweak a to the signing key. This would render signatures insecure when keys are generated using BIP32's unhardened derivation and other methods that rely on additive tweaks to existing keys such as Taproot.

Key prefixes are defined in BIP340 as:

> ...we choose key prefixed Schnorr signatures which means that the public key is prefixed to the message in the challenge hash input. This changes the equation to:
>
> `s⋅G = R + hash(R || P || m)⋅P`.
>
> It can be shown that key prefixing protects against related-key attacks with additive tweaks. In general, key prefixing increases robustness in multi-user settings, e.g., it seems to be a requirement for proving the MuSig multisignature scheme secure (see Applications below).

BIP340 also links to this [paper](https://eprint.iacr.org/2015/1135.pdf) (On the Security of the Schnorr Signature Scheme and DSA against Related-Key Attacks).

> Is it hardened or non hardened derivation (or both) that are relevant here?

As far as I can work out hardened BIP32 derivation isn't affected by related key attacks or any other security concerns so we are only concerned with unhardened BIP32 derivation when designing secure key aggregation multisig and threshold schemes like MuSig(2) and FROST. The design of these schemes are obviously constrained by the design decisions in BIP340 as they need to generate valid BIP340 public keys and be able to produce valid BIP340 signatures under the rules of SegWit version 1.


---

