{"type":"rich","version":"1.0","author_name":"npub10r66s2stvnancx9axwnfc5a34asjkwkgmkq7ztm5hf30x7fa4szsv9afdw","author_url":"https://nostr.ae/npub10r66s2stvnancx9axwnfc5a34asjkwkgmkq7ztm5hf30x7fa4szsv9afdw","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-02-14\n📝 Original message:I think that it is better to issue individual TOKEN for each\nparticipant. Otherwise it will be possible for one participant to\nattack another (intercept and replace their xpub sent to the\ncoordinator).\n\nIt will also be convenient to have a public 'participant id', derived\nfrom the token. It can be derived from the same token, but with\ndifferent (but fixed) `Pwd`. With unique token per participant, such\nderivation will uniquely identify each participant, so the coordinator\nwon't need to try all the tokens to decrypt the data.\n\nIt will also be easier to deal with more elaborate setups where the\nposition of the xpub in the descriptor does matter - for example, with\nminiscript-extended descriptors. With a descriptor template such as\n\n`wsh(or(multi(2, \u003cAlice\u003e, \u003cBob\u003e, \u003cCarol\u003e), older(1000, \u003cDylan\u003e))`\n\nThe coordinator will be able to store the map between the participant\nlabels (Alice, Bob, Carol, Dylan) and their participant ids (and the\nTOKENs). When the data from Alice comes with participant id attached,\nthe coordinator will immediately know which TOKEN to use, and which\nplace in the descriptor the xpub should be put in.\n\nOf course this is all possible without 'participant id' derived from\ntoken, as long as there's unique TOKEN per participant - the coordinator\ncan always try all the tokens to decrypt the data from participant. But\nimplementors will likely invent their own ways to introduce\n'participant id' anyway, as this is more convenient, and it might make\nsense to have this standardized, for interoperability. \n\nВ Fri, 12 Feb 2021 09:54:57 -0800\nHugo Nguyen \u003chugo at nunchuk.io\u003e wrote:\n\n\u003e On Fri, Feb 12, 2021 at 9:36 AM Dmitry Petukhov \u003cdp at simplexum.com\u003e\n\u003e wrote:\n\u003e \n\u003e \u003e If HUMAN_READABLE_TITLE is the additional secret, the user would\n\u003e \u003e need to enter it on the device in addition to the nonce, wouldn't\n\u003e \u003e it defeat the advantage in UX that was gained by using (relatively)\n\u003e \u003e short nonce ?\n\u003e \u003e\n\u003e \u003e Is 64 bit nonce not enough ?\n\u003e \u003e\n\u003e \u003e  \n\u003e Good question. If we don't need the extra entropy, we can fix\n\u003e the HUMAN_READABLE_TITLE string.\n\u003e \n\u003e Something like \"No SPOF\". (No Single Point Of Failure).\n\u003e \n\u003e \n\u003e \n\u003e \u003e It seems that to crack this with fixed Pwd and 64 bit nonce, the\n\u003e \u003e attacker will need to be about 10^15 more powerful than 80Mhz MCU:\n\u003e \u003e (2^64)/(0.3*10^15)/3600 = 17 hours. I don't know if 10^15 is\n\u003e \u003e realistic scale. Average desktop cpu seems to be about 10^3 more\n\u003e \u003e powerful than the mentioned MCU for this task.\n\u003e \u003e\n\u003e \u003e Maybe for the UX it would be better to choose the number of rounds\n\u003e \u003e to use in PBKDF2, instead of using variable Pwd. Number of rounds\n\u003e \u003e will be easier to enter on the device (or just choose it from a set\n\u003e \u003e of pre-defined values). The more money is at stake, the higher\n\u003e \u003e number of rounds could the coordinator choose (taking into account\n\u003e \u003e the characteristics of the participant devices)\n\u003e \u003e  \n\u003e \n\u003e \u003e Or simply allow bigger entropy (more than 6 mnemonic words), if\n\u003e \u003e the coordinator feels that 64 bit of entropy is not enough.  \n\u003e \n\u003e \n\u003e That could work. Allowing variable iteration count is probably better\n\u003e UX-wise.\n\u003e \n\u003e Best,\n\u003e Hugo\n\u003e \n\u003e \n\u003e \u003e\n\u003e \u003e В Fri, 12 Feb 2021 08:55:55 -0800\n\u003e \u003e Hugo Nguyen \u003chugo at nunchuk.io\u003e wrote:\n\u003e \u003e  \n\u003e \u003e \u003e Thanks everyone who has provided inputs so far!\n\u003e \u003e \u003e\n\u003e \u003e \u003e This is the new proposal for the encryption aspect of the scheme,\n\u003e \u003e \u003e based on all the feedback.\n\u003e \u003e \u003e\n\u003e \u003e \u003e The key derivation function would be PBKDF2, with PRF = SHA512.\n\u003e \u003e \u003e This should be readily available on today's hardware already, as\n\u003e \u003e \u003e they are used for BIP39.\n\u003e \u003e \u003e\n\u003e \u003e \u003e DK = PBKDF2(PRF, Password, Salt, c, dkLen)\n\u003e \u003e \u003e PRF = SHA512\n\u003e \u003e \u003e Pwd = HUMAN_READABLE_TITLE\n\u003e \u003e \u003e Salt = NONCE\n\u003e \u003e \u003e c = 2048\n\u003e \u003e \u003e dkLen = 256\n\u003e \u003e \u003e\n\u003e \u003e \u003e HUMAN_READABLE_TITLE is in ASCII format, minimum length = 8,\n\u003e \u003e \u003e maximum length = 20.\n\u003e \u003e \u003e NONCE is a 64-bit number.\n\u003e \u003e \u003e\n\u003e \u003e \u003e Reason for going with SHA512 is due to legacy support on some\n\u003e \u003e \u003e hardware. c=2048 also mimics BIP39. It takes about ~3 seconds to\n\u003e \u003e \u003e derive the encryption key on a 80Mhz MCU. We feel like this is a\n\u003e \u003e \u003e good enough tradeoff for this use case. The assumption here is\n\u003e \u003e \u003e that the secure session is only needed temporarily for a few\n\u003e \u003e \u003e hours, maybe up to one day.\n\u003e \u003e \u003e\n\u003e \u003e \u003e The Coordinator and Signers agree and exchange these 2 secrets\n\u003e \u003e \u003e prior to the setup. The NONCE can be converted to either:\n\u003e \u003e \u003e (a) a 6-word phrase using BIP39 wordlist\n\u003e \u003e \u003e (b) a 20-digit decimal number\n\u003e \u003e \u003e (c) a QR code\n\u003e \u003e \u003e\n\u003e \u003e \u003e Depending on the vendor. This flexibility in the data format\n\u003e \u003e \u003e allows each vendor to customize the UX based on their respective\n\u003e \u003e \u003e device capabilities.\n\u003e \u003e \u003e\n\u003e \u003e \u003e Best,\n\u003e \u003e \u003e Hugo\n\u003e \u003e \u003e\n\u003e \u003e \u003e On Thu, Feb 11, 2021 at 8:25 AM Dmitry Petukhov via bitcoin-dev \u003c\n\u003e \u003e \u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e \u003e  \n\u003e \u003e \u003e \u003e В Thu, 11 Feb 2021 05:45:33 -0800\n\u003e \u003e \u003e \u003e Hugo Nguyen via bitcoin-dev\n\u003e \u003e \u003e \u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e \u003e \u003e  \n\u003e \u003e \u003e \u003e \u003e \u003e \u003e ENCRYPTION_KEY = SHA256(SHA256(TOKEN))  \n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e This scheme might be vulnerable to rainbow table attack.\n\u003e \u003e \u003e \u003e \u003e \u003e  \n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e Thank you for pointing this out! Incidentally, Dmitry Petukhov\n\u003e \u003e \u003e \u003e \u003e also told me the same privately.  \n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e My thought was that if TOKEN has the characteristics of a\n\u003e \u003e \u003e \u003e password (short ASCII string), then it would be better to use\n\u003e \u003e \u003e \u003e key derivation function designed for passwords, like PBKDF2.\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e The counter-argument to this is that this adds another code\n\u003e \u003e \u003e \u003e dependency for vendors, if the device firmware does not already\n\u003e \u003e \u003e \u003e have the required key derivation function.\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e Maybe this could be solved by going into opposite direction -\n\u003e \u003e \u003e \u003e make the \"token\" even longer, use the mnemoic.\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e The issue is that entering long data of the shared key into the\n\u003e \u003e \u003e \u003e device manually is difficult UX-wise.\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e Hww vendors that allow to enter custom keys into their device\n\u003e \u003e \u003e \u003e already have to face this issue, and those who allow to enter\n\u003e \u003e \u003e \u003e custom keys via mnemonic probably tackled this somehow.\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e Maybe the shared key for multisig setup can be entered in the\n\u003e \u003e \u003e \u003e same way ? (with maybe additional visual check via some\n\u003e \u003e \u003e \u003e fingerprint).\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e Although we would then have another issue of potential confusion\n\u003e \u003e \u003e \u003e between two procedures (entering the main key and entering the\n\u003e \u003e \u003e \u003e shared key for multisig setup), and the measures has to be\n\u003e \u003e \u003e \u003e taken to prevent such confusion.\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e The approaches can be combined - specify a key derivation\n\u003e \u003e \u003e \u003e function suitable for passwords; via secure channel, share a\n\u003e \u003e \u003e \u003e password and/or the derived key. If hww supports derivation\n\u003e \u003e \u003e \u003e function, it can derive the key from password. If hww supports\n\u003e \u003e \u003e \u003e only keys, the key can be entered raw or via mnemonic.\n\u003e \u003e \u003e \u003e _______________________________________________\n\u003e \u003e \u003e \u003e bitcoin-dev mailing list\n\u003e \u003e \u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e \u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \u003e \u003e \u003e  \n\u003e \u003e\n\u003e \u003e"}