<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 12, 2021 at 9:36 AM Dmitry Petukhov <<a href="mailto:dp@simplexum.com">dp@simplexum.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If HUMAN_READABLE_TITLE is the additional secret, the user would need<br>
to enter it on the device in addition to the nonce, wouldn't it defeat<br>
the advantage in UX that was gained by using (relatively) short nonce ?<br>
<br>
Is 64 bit nonce not enough ?<br>
<br></blockquote><div><br></div><div>Good question. If we don't need the extra entropy, we can fix the HUMAN_READABLE_TITLE string.<br><br>Something like "No SPOF". (No Single Point Of Failure).</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
It seems that to crack this with fixed Pwd and 64 bit nonce, the<br>
attacker will need to be about 10^15 more powerful than 80Mhz MCU:<br>
(2^64)/(0.3*10^15)/3600 = 17 hours. I don't know if 10^15 is realistic<br>
scale. Average desktop cpu seems to be about 10^3 more powerful than<br>
the mentioned MCU for this task.<br>
<br>
Maybe for the UX it would be better to choose the number of rounds to<br>
use in PBKDF2, instead of using variable Pwd. Number of rounds will be<br>
easier to enter on the device (or just choose it from a set of<br>
pre-defined values). The more money is at stake, the higher number of<br>
rounds could the coordinator choose (taking into account the<br>
characteristics of the participant devices)<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>Or simply allow bigger entropy (more than 6 mnemonic words), if<br>the coordinator feels that 64 bit of entropy is not enough.</blockquote><div><br>That could work. Allowing variable iteration count is probably better UX-wise.<br><br>Best,<br>Hugo<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
В Fri, 12 Feb 2021 08:55:55 -0800<br>
Hugo Nguyen <<a href="mailto:hugo@nunchuk.io" target="_blank">hugo@nunchuk.io</a>> wrote:<br>
<br>
> Thanks everyone who has provided inputs so far!<br>
> <br>
> This is the new proposal for the encryption aspect of the scheme,<br>
> based on all the feedback.<br>
> <br>
> The key derivation function would be PBKDF2, with PRF = SHA512. This<br>
> should be readily available on today's hardware already, as they are<br>
> used for BIP39.<br>
> <br>
> DK = PBKDF2(PRF, Password, Salt, c, dkLen)<br>
> PRF = SHA512<br>
> Pwd = HUMAN_READABLE_TITLE<br>
> Salt = NONCE<br>
> c = 2048<br>
> dkLen = 256<br>
> <br>
> HUMAN_READABLE_TITLE is in ASCII format, minimum length = 8, maximum<br>
> length = 20.<br>
> NONCE is a 64-bit number.<br>
> <br>
> Reason for going with SHA512 is due to legacy support on some<br>
> hardware. c=2048 also mimics BIP39. It takes about ~3 seconds to<br>
> derive the encryption key on a 80Mhz MCU. We feel like this is a good<br>
> enough tradeoff for this use case. The assumption here is that the<br>
> secure session is only needed temporarily for a few hours, maybe up<br>
> to one day.<br>
> <br>
> The Coordinator and Signers agree and exchange these 2 secrets prior<br>
> to the setup. The NONCE can be converted to either:<br>
> (a) a 6-word phrase using BIP39 wordlist<br>
> (b) a 20-digit decimal number<br>
> (c) a QR code<br>
> <br>
> Depending on the vendor. This flexibility in the data format allows<br>
> each vendor to customize the UX based on their respective device<br>
> capabilities.<br>
> <br>
> Best,<br>
> Hugo<br>
> <br>
> On Thu, Feb 11, 2021 at 8:25 AM Dmitry Petukhov via bitcoin-dev <<br>
> <a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
> <br>
> > В Thu, 11 Feb 2021 05:45:33 -0800<br>
> > Hugo Nguyen via bitcoin-dev <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>><br>
> > wrote:<br>
> >  <br>
> > > > > ENCRYPTION_KEY = SHA256(SHA256(TOKEN))  <br>
> > > ><br>
> > > > This scheme might be vulnerable to rainbow table attack.<br>
> > > >  <br>
> > ><br>
> > > Thank you for pointing this out! Incidentally, Dmitry Petukhov<br>
> > > also told me the same privately.  <br>
> ><br>
> > My thought was that if TOKEN has the characteristics of a password<br>
> > (short ASCII string), then it would be better to use key derivation<br>
> > function designed for passwords, like PBKDF2.<br>
> ><br>
> > The counter-argument to this is that this adds another code<br>
> > dependency for vendors, if the device firmware does not already<br>
> > have the required key derivation function.<br>
> ><br>
> > Maybe this could be solved by going into opposite direction - make<br>
> > the "token" even longer, use the mnemoic.<br>
> ><br>
> > The issue is that entering long data of the shared key into the<br>
> > device manually is difficult UX-wise.<br>
> ><br>
> > Hww vendors that allow to enter custom keys into their device<br>
> > already have to face this issue, and those who allow to enter<br>
> > custom keys via mnemonic probably tackled this somehow.<br>
> ><br>
> > Maybe the shared key for multisig setup can be entered in the same<br>
> > way ? (with maybe additional visual check via some fingerprint).<br>
> ><br>
> > Although we would then have another issue of potential confusion<br>
> > between two procedures (entering the main key and entering the<br>
> > shared key for multisig setup), and the measures has to be taken to<br>
> > prevent such confusion.<br>
> ><br>
> > The approaches can be combined - specify a key derivation function<br>
> > suitable for passwords; via secure channel, share a password and/or<br>
> > the derived key. If hww supports derivation function, it can derive<br>
> > the key from password. If hww supports only keys, the key can be<br>
> > entered raw or via mnemonic.<br>
> > _______________________________________________<br>
> > bitcoin-dev mailing list<br>
> > <a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
> > <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
> >  <br>
<br>
</blockquote></div></div>