rich1.0npub1jqxs4ftunmm8qjyw9s80hpcayewkjfhpxund29l9qvzy7xqx4duq85jqeghttps://nostr.ae/npub1jqxs4ftunmm8qjyw9s80hpcayewkjfhpxund29l9qvzy7xqx4duq85jqegnjumphttps://nostr.ae📅 Original date posted:2021-02-12 📝 Original message:On Fri, Feb 12, 2021 at 9:36 AM Dmitry Petukhov <dp at simplexum.com> wrote: > If HUMAN_READABLE_TITLE is the additional secret, the user would need > to enter it on the device in addition to the nonce, wouldn't it defeat > the advantage in UX that was gained by using (relatively) short nonce ? > > Is 64 bit nonce not enough ? > > Good question. If we don't need the extra entropy, we can fix the HUMAN_READABLE_TITLE string. Something like "No SPOF". (No Single Point Of Failure). > It seems that to crack this with fixed Pwd and 64 bit nonce, the > attacker will need to be about 10^15 more powerful than 80Mhz MCU: > (2^64)/(0.3*10^15)/3600 = 17 hours. I don't know if 10^15 is realistic > scale. Average desktop cpu seems to be about 10^3 more powerful than > the mentioned MCU for this task. > > Maybe for the UX it would be better to choose the number of rounds to > use in PBKDF2, instead of using variable Pwd. Number of rounds will be > easier to enter on the device (or just choose it from a set of > pre-defined values). The more money is at stake, the higher number of > rounds could the coordinator choose (taking into account the > characteristics of the participant devices) > > Or simply allow bigger entropy (more than 6 mnemonic words), if > the coordinator feels that 64 bit of entropy is not enough. That could work. Allowing variable iteration count is probably better UX-wise. Best, Hugo > > В Fri, 12 Feb 2021 08:55:55 -0800 > Hugo Nguyen <hugo at nunchuk.io> wrote: > > > Thanks everyone who has provided inputs so far! > > > > This is the new proposal for the encryption aspect of the scheme, > > based on all the feedback. > > > > The key derivation function would be PBKDF2, with PRF = SHA512. This > > should be readily available on today's hardware already, as they are > > used for BIP39. > > > > DK = PBKDF2(PRF, Password, Salt, c, dkLen) > > PRF = SHA512 > > Pwd = HUMAN_READABLE_TITLE > > Salt = NONCE > > c = 2048 > > dkLen = 256 > > > > HUMAN_READABLE_TITLE is in ASCII format, minimum length = 8, maximum > > length = 20. > > NONCE is a 64-bit number. > > > > Reason for going with SHA512 is due to legacy support on some > > hardware. c=2048 also mimics BIP39. It takes about ~3 seconds to > > derive the encryption key on a 80Mhz MCU. We feel like this is a good > > enough tradeoff for this use case. The assumption here is that the > > secure session is only needed temporarily for a few hours, maybe up > > to one day. > > > > The Coordinator and Signers agree and exchange these 2 secrets prior > > to the setup. The NONCE can be converted to either: > > (a) a 6-word phrase using BIP39 wordlist > > (b) a 20-digit decimal number > > (c) a QR code > > > > Depending on the vendor. This flexibility in the data format allows > > each vendor to customize the UX based on their respective device > > capabilities. > > > > Best, > > Hugo > > > > 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). > > > > > > 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/20210212/0c8f1ab1/attachment-0001.html>