📅 Original date posted:2014-03-12
📝 Original message:On Wed, Mar 12, 2014 at 3:04 PM, Pavol Rusnak <stick at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140312/437c157a/attachment.html>;
William Yager [ARCHIVE] /
npub1mt…qzgqk
2023-06-07 15:15:16
in reply to nevent1q…2pa8
Author Public Key
npub1mtzsyxnmqze93rehd90508tdg7k4mwktknmtamqam55446tkaq7qnqzgqkPublished at
2023-06-07 15:15:16Event JSON
{
"id": "47c72b16f96eeed2d8f431db4df581ccc1a7ec66b483688046b19a8da9bb8f40",
"pubkey": "dac5021a7b00b2588f37695f479d6d47ad5dbacbb4f6beec1ddd295ae976e83c",
"created_at": 1686150916,
"kind": 1,
"tags": [
[
"e",
"e2b06c13dda090fd765a6fae17847c84821995c150a37c86a1dca89140911552",
"",
"root"
],
[
"e",
"60f5dea4f1aa428840550da864863beb605881b8d9a64ee6a25b83124f54d5dc",
"",
"reply"
],
[
"p",
"7631397e469f47f3535567311f5f7c17129e0ff2cb253df015e3d92ddfd92c63"
]
],
"content": "📅 Original date posted:2014-03-12\n📝 Original message:On Wed, Mar 12, 2014 at 3:04 PM, Pavol Rusnak \u003cstick at gk2.sk\u003e wrote:\n\n\u003e On 03/12/2014 08:55 PM, William Yager wrote:\n\u003e \u003e The proposed BIP uses a bloom filter, so it has both plausible\n\u003e deniability *and\n\u003e \u003e *typo checking. The bloom filter is optimized for two elements and will\n\u003e \u003e catch something like 99.9975% of typos, despite allowing two different\n\u003e \u003e passwords.\n\u003e\n\u003e Ok, I see. So the spec allows one real and one fake password. That is\n\u003e something I don't consider plausible deniability. I am not saying that\n\u003e this solution is wrong, I find it quite interesting, but it's not\n\u003e plausible deniability. ;-)\n\u003e\n\nIt's a little more nuanced than that. There are *always* at least two\npasswords. If the user doesn't want a second password, a random one is\ngenerated for them. A wallet with two known encryption keys and only one\nknown encryption key are indistinguishable. If compelled to decrypt, there\nis no way to prove that the user actually knows a second password.\n\n\n\u003e\n\u003e \u003e\u003e I'm afraid one would end up with code generated in one client that is\n\u003e \u003e\u003e unusable in a different client, because the client's developer thought\n\u003e \u003e\u003e that using fancier algorithm instead of the proposed ones was a good\n\u003e idea.\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e This is clearly in violation of the spec.\n\u003e\n\u003e Ah, I misunderstood. I thought that outsourcing the KDF means allowing\n\u003e the 3rd party to use any KDF instead of the specified ones. What would\n\u003e be the reason to outsource if this is not possible, anyway?\n\u003e\n\u003e\nYes, the \"outsourcing\" terminology is a little confusing. The idea is this:\nYou have a little device, like a Trezor. It has very little RAM and very\nlittle CPU power. However, you want to use a powerful key-stretching\nalgorithm (like the maximum Scrypt KDF defined in the spec). One way to\nimplement this is to allow semi-trusted devices (like desktop PCs) to do\nall the \"heavy lifting\". The way the spec is defined, it is easy to have a\nmore powerful device do all the tough key stretching work without\nsignificantly compromising the security of the wallet.\n\nWill\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140312/437c157a/attachment.html\u003e",
"sig": "1dc8c755b2d4f654219a25b717561cc9040b0fcfe6a0199d078a9bd28505b158859121cf6cd454b816cc2729c7eab9bd30d414feda0cdb8d549678d60174f4f6"
}