š
Original date posted:2021-02-11
š Original message:> ENCRYPTION_KEY = SHA256(SHA256(TOKEN))
This scheme might be vulnerable to rainbow table attack.
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.
Also, is there any reason why you'd want to disable encryption? Why not
keep that as mandatory?
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/9aae5cfa/attachment.html>;
Pavol Rusnak [ARCHIVE] /
npub1wcā¦3hnuq
2023-06-07 18:28:33
in reply to nevent1qā¦32jt
Author Public Key
npub1wccnjljxnarlx564vuc37hmuzuffurljevjnmuq4u0vjmh7e933sn3hnuqPublished at
2023-06-07 18:28:33Event JSON
{
"id": "e954a6b247db944e0a999e1a950eee1a1443e5b7f6be6465936ba46907ec743c",
"pubkey": "7631397e469f47f3535567311f5f7c17129e0ff2cb253df015e3d92ddfd92c63",
"created_at": 1686162513,
"kind": 1,
"tags": [
[
"e",
"86ad6c37ed92954d8359f9dbcd43bb8becf51e4b072d4e707f08909fe0306de5",
"",
"root"
],
[
"e",
"39183ca287e293c2b5eeb360d99db59d446e1b6b787bc12608e72ff19a1cf50a",
"",
"reply"
],
[
"p",
"900d0aa57c9ef670488e2c0efb871d265d6926e13726d517e503044f1806ab78"
]
],
"content": "š
Original date posted:2021-02-11\nš Original message:\u003e ENCRYPTION_KEY = SHA256(SHA256(TOKEN))\n\nThis scheme might be vulnerable to rainbow table attack.\n\nThe following scheme might be more secure:\n\nDESCRIPTION = ASCII description provided by user\nNONCE = 256-bit random number\nENCRYPTION_KEY = hmac-sha256(key=NONCE, msg=DESCRIPTION)\n\nCoordinator distributes DESCRIPTION (fka TOKEN) together with NONCE to the\nsigners.\n\nAlso, is there any reason why you'd want to disable encryption? Why not\nkeep that as mandatory?\n\n\nOn Tue, 9 Feb 2021 at 12:39, Hugo Nguyen via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e\n\u003e\n\u003e On Tue, Feb 9, 2021 at 2:19 AM Christopher Allen \u003c\n\u003e ChristopherA at lifewithalacrity.com\u003e wrote:\n\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e On Tue, Feb 9, 2021 at 2:06 AM Hugo Nguyen \u003chugo at nunchuk.io\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e I don't think reusing XPUBs inside different multisig wallets is a good\n\u003e\u003e\u003e idea... For starters, loss of privacy in one wallet will immediately affect\n\u003e\u003e\u003e privacy of other wallets. I think multisig wallets should be completely\n\u003e\u003e\u003e firewalled from each other. That means one unique XPUB per wallet. This is\n\u003e\u003e\u003e what we have been doing with the Nunchuk wallet.\n\u003e\u003e\u003e\n\u003e\u003e\n\u003e\u003e To be clear, I have stated repeatedly that xpub reuse into multisig is a\n\u003e\u003e poor practice. However, finding a trustless solution when a wallet is\n\u003e\u003e airgapped with no network, or is stateless like Trezor, is quite hard.\n\u003e\u003e\n\u003e\u003e The challenge also includes how does an airgapped or stateless wallet\n\u003e\u003e know that it is talking to the same process on the other side that that it\n\u003e\u003e gave the xpub to in the first place. Without state to allow for a\n\u003e\u003e commitment, or at least a TOFU, a cosigner who thought he was part of a 3\n\u003e\u003e of 5 could discover that he instead is in a 2 of 3, or in a script with an\n\u003e\u003e OR, as some form of scam.\n\u003e\u003e\n\u003e\n\u003e The shared secret approach that I mentioned in the proposal actually can\n\u003e help you here. The TOKEN doubles as a session ID - thereby establishing a\n\u003e common state on both sides.\n\u003e\n\u003e Best,\n\u003e Hugo\n\u003e\n\u003e\n\u003e\u003e\n\u003e\u003e ā Christopher Allen\n\u003e\u003e\n\u003e\u003e\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\n\n-- \nBest Regards / S pozdravom,\n\nPavol \"stick\" Rusnak\nCTO, SatoshiLabs\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210211/9aae5cfa/attachment.html\u003e",
"sig": "516fd8a95c3e4459d141b5a5181af655770c0c2a21f87f9f05adc56dc7d382b19b612668609d462df5532994631580168021efa6508cf04ab1fe94292c730ed7"
}