public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: William Yager <will.yager@gmail.com>
To: Pavol Rusnak <stick@gk2.sk>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption
Date: Wed, 12 Mar 2014 15:10:27 -0500	[thread overview]
Message-ID: <CAG8oi1PhrmCqciECGKNa+DPp3Q_NrHP=79xxzOTkCJ655b4HXg@mail.gmail.com> (raw)
In-Reply-To: <5320BDD1.50001@gk2.sk>

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

On Wed, Mar 12, 2014 at 3:04 PM, Pavol Rusnak <stick@gk2.sk> wrote:

> On 03/12/2014 08:55 PM, William Yager wrote:
> > The proposed BIP uses a bloom filter, so it has both plausible
> deniability *and
> > *typo checking. The bloom filter is optimized for two elements and will
> > catch something like 99.9975% of typos, despite allowing two different
> > passwords.
>
> Ok, I see. So the spec allows one real and one fake password. That is
> something I don't consider plausible deniability. I am not saying that
> this solution is wrong, I find it quite interesting, but it's not
> plausible deniability. ;-)
>

It's a little more nuanced than that. There are *always* at least two
passwords. If the user doesn't want a second password, a random one is
generated for them. A wallet with two known encryption keys and only one
known encryption key are indistinguishable. If compelled to decrypt, there
is no way to prove that the user actually knows a second password.


>
> >> I'm afraid one would end up with code generated in one client that is
> >> unusable in a different client, because the client's developer thought
> >> that using fancier algorithm instead of the proposed ones was a good
> idea.
> >>
> >>
> > This is clearly in violation of the spec.
>
> Ah, I misunderstood. I thought that outsourcing the KDF means allowing
> the 3rd party to use any KDF instead of the specified ones. What would
> be the reason to outsource if this is not possible, anyway?
>
>
Yes, the "outsourcing" terminology is a little confusing. The idea is this:
You have a little device, like a Trezor. It has very little RAM and very
little CPU power. However, you want to use a powerful key-stretching
algorithm (like the maximum Scrypt KDF defined in the spec). One way to
implement this is to allow semi-trusted devices (like desktop PCs) to do
all the "heavy lifting". The way the spec is defined, it is easy to have a
more powerful device do all the tough key stretching work without
significantly compromising the security of the wallet.

Will

[-- Attachment #2: Type: text/html, Size: 2770 bytes --]

  reply	other threads:[~2014-03-12 20:10 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <op.w0hd2nthyldrnw@laptop-air>
2013-07-19 18:15 ` [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet master seed with optional encryption Jean-Paul Kogelman
2013-07-22 13:14   ` Mike Hearn
2013-07-22 14:33     ` Jean-Paul Kogelman
2013-07-22 21:37     ` Jean-Paul Kogelman
2013-11-16  2:47       ` Gregory Maxwell
2013-11-16  3:09         ` Jean-Paul Kogelman
2013-12-26 11:48           ` Jean-Paul Kogelman
2014-03-12  3:17             ` [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet root key " Jean-Paul Kogelman
2014-03-12 13:11               ` Pavol Rusnak
2014-03-12 15:45                 ` Jean-Paul Kogelman
2014-03-12 15:55                   ` Pavol Rusnak
2014-03-12 16:49                     ` Gary Rowe
2014-03-12 18:00                       ` William Yager
2014-03-12 19:35                       ` Jean-Paul Kogelman
2014-03-12 19:41                         ` Gary Rowe
2014-03-12 19:26                     ` Jean-Paul Kogelman
2014-03-12 19:39                       ` Pavol Rusnak
2014-03-12 19:55                         ` William Yager
2014-03-12 20:04                           ` Pavol Rusnak
2014-03-12 20:10                             ` William Yager [this message]
2014-03-12 20:24                               ` Pavol Rusnak
2014-03-12 20:37                                 ` William Yager
2014-03-12 20:42                                   ` Pavol Rusnak
2014-03-12 20:49                                     ` William Yager
2014-03-12 21:08                                 ` Jean-Paul Kogelman
2014-03-12 21:15                                   ` William Yager
2014-04-22  0:05 William Yager
2014-04-24 19:39 ` William Yager

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='CAG8oi1PhrmCqciECGKNa+DPp3Q_NrHP=79xxzOTkCJ655b4HXg@mail.gmail.com' \
    --to=will.yager@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=stick@gk2.sk \
    /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