jan matejek [ARCHIVE] on Nostr: 📅 Original date posted:2019-05-08 📝 Original message:hello, On 07. 05. 19 ...
📅 Original date posted:2019-05-08
📝 Original message:hello,
On 07. 05. 19 15:40, Dmitry Petukhov via bitcoin-dev wrote:
> At the setup phase, hardware wallet can sign a message that consists of
> xpubs of participants, and some auxiliary text. It can use the key
> derived from the master key, with path chosen specifically for this
> purpose.
This seems overly complicated.
What is your threat model?
IIUC, each individual multisig signature also signs the set of signers
(through signing redeem-script (or scriptPubKey in address-based multisig))
So if an attacker gives me bad xpubs, i will sign them, but the
signature won't be valid for the given multisig output - even if the
attacker manages to trick 2 of 3 signers and recombine their signatures.
Therefore, the input==output check is sufficient: if I use the same set
of signers for an input and an output, I can be sure that the change
goes to the same multisig wallet.
Or is there something I'm missing?
The weak spot is the part where you generate receiving address, because
that "creates" the particular multisig wallet. But that's nothing to do
with PSBT.
> This would allow to distinguish the trusted output even if the inputs
> are not all derived from the same set of xpubs, that could happen in
> more complex scenarios (batching, key rotation, etc.), and can possibly
> be used to have several different types of 'trusted' outputs.
This seems to be an attempt at a different, much broader problem. And it
won't help if the attacker can replay a different trusted-xpub package
(e.g., one that contains a revoked previously compromised key).
regards
m.
📝 Original message:hello,
On 07. 05. 19 15:40, Dmitry Petukhov via bitcoin-dev wrote:
> At the setup phase, hardware wallet can sign a message that consists of
> xpubs of participants, and some auxiliary text. It can use the key
> derived from the master key, with path chosen specifically for this
> purpose.
This seems overly complicated.
What is your threat model?
IIUC, each individual multisig signature also signs the set of signers
(through signing redeem-script (or scriptPubKey in address-based multisig))
So if an attacker gives me bad xpubs, i will sign them, but the
signature won't be valid for the given multisig output - even if the
attacker manages to trick 2 of 3 signers and recombine their signatures.
Therefore, the input==output check is sufficient: if I use the same set
of signers for an input and an output, I can be sure that the change
goes to the same multisig wallet.
Or is there something I'm missing?
The weak spot is the part where you generate receiving address, because
that "creates" the particular multisig wallet. But that's nothing to do
with PSBT.
> This would allow to distinguish the trusted output even if the inputs
> are not all derived from the same set of xpubs, that could happen in
> more complex scenarios (batching, key rotation, etc.), and can possibly
> be used to have several different types of 'trusted' outputs.
This seems to be an attempt at a different, much broader problem. And it
won't help if the attacker can replay a different trusted-xpub package
(e.g., one that contains a revoked previously compromised key).
regards
m.