public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Hugo Nguyen <hugo@nunchuk.io>
To: Dmitry Petukhov <dp@simplexum.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
Date: Fri, 12 Feb 2021 09:54:57 -0800	[thread overview]
Message-ID: <CAPKmR9uUv32AbSUv9C-JvzEQo5WQb+a6iPSBWTnY1wwKwGaDng@mail.gmail.com> (raw)
In-Reply-To: <20210212184231.22b517aa@simplexum.com>

[-- Attachment #1: Type: text/plain, Size: 5330 bytes --]

On Fri, Feb 12, 2021 at 9:36 AM Dmitry Petukhov <dp@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@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@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).
> > >
> > > 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: 7243 bytes --]

  parent reply	other threads:[~2021-02-12 18:01 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] ` <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
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 [this message]
2021-02-14 10:37                     ` Dmitry Petukhov
2021-02-14 11:28                       ` Dmitry Petukhov
     [not found] ` <CAPR5oBNWGLcnw97yPJBCgrj=EwoNdxz_RS9HM6EMpuX2-90JnQ@mail.gmail.com>
2021-02-09  9:45   ` Hugo Nguyen
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=CAPKmR9uUv32AbSUv9C-JvzEQo5WQb+a6iPSBWTnY1wwKwGaDng@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