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