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