š
Original date posted:2014-03-12
š Original message: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. ;-)
>> 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?
--
Best Regards / S pozdravom,
Pavol Rusnak <stick at gk2.sk>
Pavol Rusnak [ARCHIVE] /
npub1wcā¦3hnuq
2023-06-07 15:15:16
in reply to nevent1qā¦j3j4
Author Public Key
npub1wccnjljxnarlx564vuc37hmuzuffurljevjnmuq4u0vjmh7e933sn3hnuqPublished at
2023-06-07 15:15:16Event JSON
{
"id": "60f5dea4f1aa428840550da864863beb605881b8d9a64ee6a25b83124f54d5dc",
"pubkey": "7631397e469f47f3535567311f5f7c17129e0ff2cb253df015e3d92ddfd92c63",
"created_at": 1686150916,
"kind": 1,
"tags": [
[
"e",
"e2b06c13dda090fd765a6fae17847c84821995c150a37c86a1dca89140911552",
"",
"root"
],
[
"e",
"5bf3563520b5c6c586c288a786c3a30d333f076ee1a4c1727dfb3b8216eb3fc7",
"",
"reply"
],
[
"p",
"dac5021a7b00b2588f37695f479d6d47ad5dbacbb4f6beec1ddd295ae976e83c"
]
],
"content": "š
Original date posted:2014-03-12\nš Original message:On 03/12/2014 08:55 PM, William Yager wrote:\n\u003e The proposed BIP uses a bloom filter, so it has both plausible deniability *and\n\u003e *typo checking. The bloom filter is optimized for two elements and will\n\u003e catch something like 99.9975% of typos, despite allowing two different\n\u003e passwords.\n\nOk, I see. So the spec allows one real and one fake password. That is\nsomething I don't consider plausible deniability. I am not saying that\nthis solution is wrong, I find it quite interesting, but it's not\nplausible deniability. ;-)\n\n\u003e\u003e I'm afraid one would end up with code generated in one client that is\n\u003e\u003e unusable in a different client, because the client's developer thought\n\u003e\u003e that using fancier algorithm instead of the proposed ones was a good idea.\n\u003e\u003e\n\u003e\u003e\n\u003e This is clearly in violation of the spec. \n\nAh, I misunderstood. I thought that outsourcing the KDF means allowing\nthe 3rd party to use any KDF instead of the specified ones. What would\nbe the reason to outsource if this is not possible, anyway?\n\n-- \nBest Regards / S pozdravom,\n\nPavol Rusnak \u003cstick at gk2.sk\u003e",
"sig": "0947fca60d313c5696ac710707b35102d043106fc572936b0045c64da822ed15b327d2b9ff0d64bf65eebbcfd30ad8291ed511d4ab759788df5402964441e5f7"
}