From: Hugo Nguyen <hugo@nunchuk.io>
To: Dmitry Petukhov <dp@simplexum.com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
Date: Thu, 11 Feb 2021 11:11:45 -0800 [thread overview]
Message-ID: <CAPKmR9t0hta0n4tAqp1SwH4gJ_5cswh-pg4DDAJ=qMhZjtUgYw@mail.gmail.com> (raw)
In-Reply-To: <CAPKmR9udiK+2gC2qUueAfKm7VBf8csM-3WOz1+-bMNR0iVeGew@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2674 bytes --]
*BIP39 seed words list.
On Thu, Feb 11, 2021 at 11:11 AM Hugo Nguyen <hugo@nunchuk.io> wrote:
> Hi Pavol,
>
> On Thu, Feb 11, 2021 at 8:25 AM Dmitry Petukhov via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> В Thu, 11 Feb 2021 05:45:33 -0800
>> Hugo Nguyen via bitcoin-dev <bitcoin-dev@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@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
[-- Attachment #2: Type: text/html, Size: 3759 bytes --]
next prev parent reply other threads:[~2021-02-11 19:12 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-08 23:14 [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup Hugo Nguyen
2021-02-09 9:33 ` Craig Raw
[not found] ` <CAPR5oBNWGLcnw97yPJBCgrj=EwoNdxz_RS9HM6EMpuX2-90JnQ@mail.gmail.com>
2021-02-09 9:45 ` Hugo Nguyen
[not found] ` <CACrqygA1JRA293joYOxxpSepiuFD=uVvQQy3wpuosYyLQHff-A@mail.gmail.com>
2021-02-09 9:38 ` Christopher Allen
2021-02-09 10:05 ` Hugo Nguyen
[not found] ` <CACrqygDhuateDtJMBSWd9sGRu1yzrZBw2yZ75OyKD1Xmzix3Cw@mail.gmail.com>
2021-02-09 10:58 ` Hugo Nguyen
2021-02-11 13:25 ` Pavol Rusnak
2021-02-11 13:45 ` Hugo Nguyen
2021-02-11 16:29 ` Dmitry Petukhov
2021-02-11 19:11 ` Hugo Nguyen
2021-02-11 19:11 ` Hugo Nguyen [this message]
2021-02-11 22:29 ` Christopher Allen
2021-02-12 12:31 ` Hugo Nguyen
2021-02-12 13:48 ` Peter D. Gray
2021-02-12 16:55 ` Hugo Nguyen
2021-02-12 17:42 ` Dmitry Petukhov
2021-02-12 17:48 ` Dmitry Petukhov
2021-02-12 17:54 ` Hugo Nguyen
2021-02-14 10:37 ` Dmitry Petukhov
2021-02-14 11:28 ` Dmitry Petukhov
2021-02-15 8:44 ` Hugo Nguyen
2021-02-15 13:53 ` Craig Raw
2021-02-15 14:19 ` Hugo Nguyen
2021-02-15 16:45 ` Hugo Nguyen
2021-04-05 7:02 ` Hugo Nguyen
2021-04-09 12:07 ` Sjors Provoost
2021-04-09 14:09 ` Hugo Nguyen
2021-04-09 14:54 ` Hugo Nguyen
2021-04-09 15:33 ` Sjors Provoost
2021-04-10 19:32 ` Robert Spigler
2021-04-11 2:34 ` Michael.flaxman
2021-04-11 16:45 ` Hugo Nguyen
2021-04-12 15:03 ` Salvatore Ingala
2021-04-12 17:55 ` Hugo Nguyen
2021-04-12 18:45 ` Christopher Allen
2021-04-12 20:43 ` Robert Spigler
2021-04-10 13:53 ` Erik Aronesty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPKmR9t0hta0n4tAqp1SwH4gJ_5cswh-pg4DDAJ=qMhZjtUgYw@mail.gmail.com' \
--to=hugo@nunchuk.io \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=dp@simplexum.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox