rich1.0npub10r66s2stvnancx9axwnfc5a34asjkwkgmkq7ztm5hf30x7fa4szsv9afdwhttps://nostr.ae/npub10r66s2stvnancx9axwnfc5a34asjkwkgmkq7ztm5hf30x7fa4szsv9afdwnjumphttps://nostr.ae📅 Original date posted:2021-02-11 📝 Original message:В 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). 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.