{"type":"rich","version":"1.0","author_name":"npub1jqxs4ftunmm8qjyw9s80hpcayewkjfhpxund29l9qvzy7xqx4duq85jqeg","author_url":"https://nostr.ae/npub1jqxs4ftunmm8qjyw9s80hpcayewkjfhpxund29l9qvzy7xqx4duq85jqeg","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 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"}