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