๐
Original date posted:2018-01-22
๐ Original message:On Thu, Jan 18, 2018 at 1:58 PM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Thu, Jan 18, 2018 at 4:59 PM, Ondลej Vejpustek
> <ondrej.vejpustek at satoshilabs.com> wrote:
> >> If being secure against partial share leakage is really part of your
> >> threat model the current proposal is gratuitously insecure against it.
> >
> > I don't think that is true. Shared secret is an input of KDF which
> > should prevent this kind of attack.
>
> My post provided a concrete example. I'd be happy to answer any
> questions about it, but otherwise I'm not sure how to make it more
> clear.
>
> > Actually, we've been considering something like that. We concluded that
> it is to much "rolling your own crypto". Instead of diffusion layer we
> decided to apply KDF on the shared secret.
>
>
> Quite the opposite-- a large block cipher is a standard
> construction... and the off-label application of a KDF that you've
> used here doesn't provide any protection against the example I gave.
>
At this point, is it better just to use GF(2^256+n)? Is GF(2^256+n) going
to be that much slower than GF(2^8) that we care to make things this
complicated? (I honestly don't know the answer.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180122/c8799a13/attachment.html>;
Russell O'Connor [ARCHIVE] /
npub1dwโฆ8plrw
2023-06-07 18:09:34
in reply to nevent1qโฆw76y
Author Public Key
npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrwPublished at
2023-06-07 18:09:34Event JSON
{
"id": "e3790a241cc44c3bd4f98dfa85b884ccf1646b2d9f27af16ecc8d01657620564",
"pubkey": "6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d",
"created_at": 1686161374,
"kind": 1,
"tags": [
[
"e",
"ac3c87f148ca764c85262d935c0d26818cde51a790aa045223a08240c1ff8e91",
"",
"root"
],
[
"e",
"6d3710c9c0fabdeb5ecf6384b51ac98a0469d905125cab75665f8b9fd20aaaca",
"",
"reply"
],
[
"p",
"4a985f597a05c21d6724a792c5a4e4728a3bbd5316878a898b545fafea059fcb"
]
],
"content": "๐
Original date posted:2018-01-22\n๐ Original message:On Thu, Jan 18, 2018 at 1:58 PM, Gregory Maxwell via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Thu, Jan 18, 2018 at 4:59 PM, Ondลej Vejpustek\n\u003e \u003condrej.vejpustek at satoshilabs.com\u003e wrote:\n\u003e \u003e\u003e If being secure against partial share leakage is really part of your\n\u003e \u003e\u003e threat model the current proposal is gratuitously insecure against it.\n\u003e \u003e\n\u003e \u003e I don't think that is true. Shared secret is an input of KDF which\n\u003e \u003e should prevent this kind of attack.\n\u003e\n\u003e My post provided a concrete example. I'd be happy to answer any\n\u003e questions about it, but otherwise I'm not sure how to make it more\n\u003e clear.\n\u003e\n\u003e \u003e Actually, we've been considering something like that. We concluded that\n\u003e it is to much \"rolling your own crypto\". Instead of diffusion layer we\n\u003e decided to apply KDF on the shared secret.\n\u003e\n\u003e\n\u003e Quite the opposite-- a large block cipher is a standard\n\u003e construction... and the off-label application of a KDF that you've\n\u003e used here doesn't provide any protection against the example I gave.\n\u003e\n\nAt this point, is it better just to use GF(2^256+n)? Is GF(2^256+n) going\nto be that much slower than GF(2^8) that we care to make things this\ncomplicated? (I honestly don't know the answer.)\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180122/c8799a13/attachment.html\u003e",
"sig": "02a9b430f7cac2939fa30f67a3574366ab97da2e78faee96a6cd4983f505fb1df83852a3d008ce25debacd2ef192867b4755da306809970506988ffc118726e6"
}