<div dir="ltr"><div>Thanks everyone who has provided inputs so far! <br><br>This is the new proposal for the encryption aspect of the scheme, based on all the feedback.<br><br>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.<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 length = 20.<br>NONCE is a 64-bit number.<br><br>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.<br><br>The Coordinator and Signers agree and exchange these 2 secrets prior 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 each vendor to customize the UX based on their respective device capabilities.<br><br>Best,</div>Hugo<br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 11, 2021 at 8:25 AM Dmitry Petukhov via bitcoin-dev <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</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">В 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 also<br>
> 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 dependency<br>
for vendors, if the device firmware does not already have the required<br>
key derivation function.<br>
<br>
Maybe this could be solved by going into opposite direction - make the<br>
"token" even longer, use the mnemoic.<br>
<br>
The issue is that entering long data of the shared key into the device<br>
manually is difficult UX-wise.<br>
<br>
Hww vendors that allow to enter custom keys into their device already<br>
have to face this issue, and those who allow to enter custom keys via<br>
mnemonic probably tackled this somehow.<br>
<br>
Maybe the shared key for multisig setup can be entered in the same way<br>
? (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 shared<br>
key for multisig setup), and the measures has to be taken to prevent<br>
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 the<br>
derived key. If hww supports derivation function, it can derive the key<br>
from password. If hww supports only keys, the key can be entered raw or<br>
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>
</blockquote></div></div>