š
Original date posted:2021-02-11
š Original message:Hi Pavol,
On Thu, Feb 11, 2021 at 5:25 AM Pavol Rusnak <stick at satoshilabs.com> wrote:
> > ENCRYPTION_KEY = SHA256(SHA256(TOKEN))
>
> This scheme might be vulnerable to rainbow table attack.
>
Thank you for pointing this out! Incidentally, Dmitry Petukhov also told me
the same privately.
>
> The following scheme might be more secure:
>
> DESCRIPTION = ASCII description provided by user
> NONCE = 256-bit random number
> ENCRYPTION_KEY = hmac-sha256(key=NONCE, msg=DESCRIPTION)
>
> Coordinator distributes DESCRIPTION (fka TOKEN) together with NONCE to
> the signers.
>
This does seem to add a lot more entropy. The challenge is to balance the
security requirement with UX. In the absence of some handshake protocol to
exchange the shared secrets (DESCRIPTION / NONCE) , the user will have to
enter these manually on the devices. I'll think about this some more.
>
> Also, is there any reason why you'd want to disable encryption? Why not
> keep that as mandatory?
>
Making it mandatory would be nice, but IMHO not all use cases might require
encryption. For example, if you are setting up the multisig locally under a
safe environment you control, encryption might be an overkill.
Best,
Hugo
>
>
> On Tue, 9 Feb 2021 at 12:39, Hugo Nguyen via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>>
>>
>> On Tue, Feb 9, 2021 at 2:19 AM Christopher Allen <
>> ChristopherA at lifewithalacrity.com> wrote:
>>
>>>
>>>
>>> On Tue, Feb 9, 2021 at 2:06 AM Hugo Nguyen <hugo at nunchuk.io> wrote:
>>>
>>>>
>>>> I don't think reusing XPUBs inside different multisig wallets is a good
>>>> idea... For starters, loss of privacy in one wallet will immediately affect
>>>> privacy of other wallets. I think multisig wallets should be completely
>>>> firewalled from each other. That means one unique XPUB per wallet. This is
>>>> what we have been doing with the Nunchuk wallet.
>>>>
>>>
>>> To be clear, I have stated repeatedly that xpub reuse into multisig is a
>>> poor practice. However, finding a trustless solution when a wallet is
>>> airgapped with no network, or is stateless like Trezor, is quite hard.
>>>
>>> The challenge also includes how does an airgapped or stateless wallet
>>> know that it is talking to the same process on the other side that that it
>>> gave the xpub to in the first place. Without state to allow for a
>>> commitment, or at least a TOFU, a cosigner who thought he was part of a 3
>>> of 5 could discover that he instead is in a 2 of 3, or in a script with an
>>> OR, as some form of scam.
>>>
>>
>> The shared secret approach that I mentioned in the proposal actually can
>> help you here. The TOKEN doubles as a session ID - thereby establishing a
>> common state on both sides.
>>
>> Best,
>> Hugo
>>
>>
>>>
>>> ā Christopher Allen
>>>
>>>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> --
> Best Regards / S pozdravom,
>
> Pavol "stick" Rusnak
> CTO, SatoshiLabs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210211/2ab27396/attachment-0001.html>;
Hugo Nguyen [ARCHIVE] /
npub1jqā¦5jqeg
2023-06-07 18:28:33
in reply to nevent1qā¦89ct
Author Public Key
npub1jqxs4ftunmm8qjyw9s80hpcayewkjfhpxund29l9qvzy7xqx4duq85jqegPublished at
2023-06-07 18:28:33Event JSON
{
"id": "840c38478e145f3edcd91e16f5ee9c7af37b107e67216a4627542a670006a2c4",
"pubkey": "900d0aa57c9ef670488e2c0efb871d265d6926e13726d517e503044f1806ab78",
"created_at": 1686162513,
"kind": 1,
"tags": [
[
"e",
"86ad6c37ed92954d8359f9dbcd43bb8becf51e4b072d4e707f08909fe0306de5",
"",
"root"
],
[
"e",
"e954a6b247db944e0a999e1a950eee1a1443e5b7f6be6465936ba46907ec743c",
"",
"reply"
],
[
"p",
"7631397e469f47f3535567311f5f7c17129e0ff2cb253df015e3d92ddfd92c63"
]
],
"content": "š
Original date posted:2021-02-11\nš Original message:Hi Pavol,\n\nOn Thu, Feb 11, 2021 at 5:25 AM Pavol Rusnak \u003cstick at satoshilabs.com\u003e wrote:\n\n\u003e \u003e ENCRYPTION_KEY = SHA256(SHA256(TOKEN))\n\u003e\n\u003e This scheme might be vulnerable to rainbow table attack.\n\u003e\n\nThank you for pointing this out! Incidentally, Dmitry Petukhov also told me\nthe same privately.\n\n\n\u003e\n\u003e The following scheme might be more secure:\n\u003e\n\u003e DESCRIPTION = ASCII description provided by user\n\u003e NONCE = 256-bit random number\n\u003e ENCRYPTION_KEY = hmac-sha256(key=NONCE, msg=DESCRIPTION)\n\u003e\n\u003e Coordinator distributes DESCRIPTION (fka TOKEN) together with NONCE to\n\u003e the signers.\n\u003e\n\nThis does seem to add a lot more entropy. The challenge is to balance the\nsecurity requirement with UX. In the absence of some handshake protocol to\nexchange the shared secrets (DESCRIPTION / NONCE) , the user will have to\nenter these manually on the devices. I'll think about this some more.\n\n\n\u003e\n\u003e Also, is there any reason why you'd want to disable encryption? Why not\n\u003e keep that as mandatory?\n\u003e\n\nMaking it mandatory would be nice, but IMHO not all use cases might require\nencryption. For example, if you are setting up the multisig locally under a\nsafe environment you control, encryption might be an overkill.\n\nBest,\nHugo\n\n\n\n\u003e\n\u003e\n\u003e On Tue, 9 Feb 2021 at 12:39, Hugo Nguyen via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e On Tue, Feb 9, 2021 at 2:19 AM Christopher Allen \u003c\n\u003e\u003e ChristopherA at lifewithalacrity.com\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e On Tue, Feb 9, 2021 at 2:06 AM Hugo Nguyen \u003chugo at nunchuk.io\u003e wrote:\n\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e I don't think reusing XPUBs inside different multisig wallets is a good\n\u003e\u003e\u003e\u003e idea... For starters, loss of privacy in one wallet will immediately affect\n\u003e\u003e\u003e\u003e privacy of other wallets. I think multisig wallets should be completely\n\u003e\u003e\u003e\u003e firewalled from each other. That means one unique XPUB per wallet. This is\n\u003e\u003e\u003e\u003e what we have been doing with the Nunchuk wallet.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e To be clear, I have stated repeatedly that xpub reuse into multisig is a\n\u003e\u003e\u003e poor practice. However, finding a trustless solution when a wallet is\n\u003e\u003e\u003e airgapped with no network, or is stateless like Trezor, is quite hard.\n\u003e\u003e\u003e\n\u003e\u003e\u003e The challenge also includes how does an airgapped or stateless wallet\n\u003e\u003e\u003e know that it is talking to the same process on the other side that that it\n\u003e\u003e\u003e gave the xpub to in the first place. Without state to allow for a\n\u003e\u003e\u003e commitment, or at least a TOFU, a cosigner who thought he was part of a 3\n\u003e\u003e\u003e of 5 could discover that he instead is in a 2 of 3, or in a script with an\n\u003e\u003e\u003e OR, as some form of scam.\n\u003e\u003e\u003e\n\u003e\u003e\n\u003e\u003e The shared secret approach that I mentioned in the proposal actually can\n\u003e\u003e help you here. The TOKEN doubles as a session ID - thereby establishing a\n\u003e\u003e common state on both sides.\n\u003e\u003e\n\u003e\u003e Best,\n\u003e\u003e Hugo\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e ā Christopher Allen\n\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\n\u003e\n\u003e --\n\u003e Best Regards / S pozdravom,\n\u003e\n\u003e Pavol \"stick\" Rusnak\n\u003e CTO, SatoshiLabs\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210211/2ab27396/attachment-0001.html\u003e",
"sig": "c5d6ebe2b88917e6e2b0723c7861e283dfea8b6223ea0d99a4f1918fade476378c4e8b27561da069ebbd3401db9437c1e4e1676eef095f41749aa7a27d1ad20f"
}