{"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:*BIP39 seed words list.\n\nOn Thu, Feb 11, 2021 at 11:11 AM Hugo Nguyen \u003chugo at nunchuk.io\u003e wrote:\n\n\u003e Hi Pavol,\n\u003e\n\u003e On Thu, Feb 11, 2021 at 8:25 AM Dmitry Petukhov via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e В Thu, 11 Feb 2021 05:45:33 -0800\n\u003e\u003e Hugo Nguyen via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e\u003e wrote:\n\u003e\u003e\n\u003e\u003e \u003e \u003e \u003e ENCRYPTION_KEY = SHA256(SHA256(TOKEN))\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e This scheme might be vulnerable to rainbow table attack.\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e\n\u003e\u003e \u003e Thank you for pointing this out! Incidentally, Dmitry Petukhov also\n\u003e\u003e \u003e told me the same privately.\n\u003e\u003e\n\u003e\u003e My thought was that if TOKEN has the characteristics of a password\n\u003e\u003e (short ASCII string), then it would be better to use key derivation\n\u003e\u003e function designed for passwords, like PBKDF2.\n\u003e\u003e\n\u003e\u003e The counter-argument to this is that this adds another code dependency\n\u003e\u003e for vendors, if the device firmware does not already have the required\n\u003e\u003e key derivation function.\n\u003e\u003e\n\u003e\u003e Maybe this could be solved by going into opposite direction - make the\n\u003e\u003e \"token\" even longer, use the mnemoic.\n\u003e\u003e\n\u003e\u003e The issue is that entering long data of the shared key into the device\n\u003e\u003e manually is difficult UX-wise.\n\u003e\u003e\n\u003e\u003e Hww vendors that allow to enter custom keys into their device already\n\u003e\u003e have to face this issue, and those who allow to enter custom keys via\n\u003e\u003e mnemonic probably tackled this somehow.\n\u003e\u003e\n\u003e\u003e Maybe the shared key for multisig setup can be entered in the same way\n\u003e\u003e ? (with maybe additional visual check via some fingerprint).\n\u003e\u003e\n\u003e\n\u003e You just gave me a great idea! We can reuse the BIP32 seed words list!\n\u003e Perhaps the encryption key can just be 6 words, but it'll be derived the\n\u003e same way. BIP39 also uses PBKDF2 as a key derivation function, so it\n\u003e matches with what you described here.\n\u003e\n\u003e And all HWW should have this functionality already.\n\u003e\n\u003e Best,\n\u003e Hugo\n\u003e\n\u003e\n\u003e\u003e\n\u003e\u003e Although we would then have another issue of potential confusion\n\u003e\u003e between two procedures (entering the main key and entering the shared\n\u003e\u003e key for multisig setup), and the measures has to be taken to prevent\n\u003e\u003e such confusion.\n\u003e\u003e\n\u003e\u003e The approaches can be combined - specify a key derivation function\n\u003e\u003e suitable for passwords; via secure channel, share a password and/or the\n\u003e\u003e derived key. If hww supports derivation function, it can derive the key\n\u003e\u003e from password. If hww supports only keys, the key can be entered raw or\n\u003e\u003e via mnemonic.\n\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-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210211/a7915106/attachment-0001.html\u003e"}