Matt Whitlock [ARCHIVE] on Nostr: ๐
Original date posted:2014-03-29 ๐ Original message:On Saturday, 29 March ...
๐
Original date posted:2014-03-29
๐ Original message:On Saturday, 29 March 2014, at 1:52 pm, Alan Reiner wrote:
> On 03/29/2014 01:19 PM, Matt Whitlock wrote:
> > I intentionally omitted the parameter M (minimum subset size) from the shares because including it would give an adversary a vital piece of information. Likewise, including any kind of information that would allow a determination of whether the secret has been correctly reconstituted would give an adversary too much information. Failing silently when given incorrect shares or an insufficient number of shares is intentional.
>
> I do not believe this is a good tradeoff. It's basically obfuscation of
> something that is already considered secure at the expense of
> usability. It's much more important to me that the user understands
> what is in their hands (or their family members after they get hit by a
> bus), than to obfuscate the parameters of the secret sharing to provide
> a tiny disadvantage to an adversary who gets ahold of one.
>
> The fact that it fails silently is really all downside, not a benefit.
> If I have enough fragments, I can reconstruct the seed and see that it
> produces addresses with money. If not, I know I need more fragments.
> I'm much more concerned about my family having all the info they need to
> recover the money, than an attacker knowing that he needs two more
> fragments instead of which are well-secured anyway.
For what it's worth, ssss also omits from the shares any information about the threshold. It will happily return a garbage secret if too few shares are combined. (And actually, it will happily return a garbage secret if too *many* shares are combined, too. My implementation does not have that problem.)
Published at
2023-06-07 15:16:41Event JSON
{
"id": "04ef1a2b69643dfae3bf42522bd6d489eca9d79800fa64a33c2cb8ba62110e18",
"pubkey": "f00d0858b09287e941ccbc491567cc70bdbc62d714628b167c1b76e7fef04d91",
"created_at": 1686151001,
"kind": 1,
"tags": [
[
"e",
"cd470d06d90a3107c21da4b48b344ebdd3b4ab813362bb85b0e7a02311012700",
"",
"root"
],
[
"e",
"a553b8169615a73c743e476b61ddce3c096f8225fb52e7902567d59cfd3f1caa",
"",
"reply"
],
[
"p",
"86f42bcb76a431c128b596c36714ae73a42cae48706a9e5513d716043447f5ec"
]
],
"content": "๐
Original date posted:2014-03-29\n๐ Original message:On Saturday, 29 March 2014, at 1:52 pm, Alan Reiner wrote:\n\u003e On 03/29/2014 01:19 PM, Matt Whitlock wrote:\n\u003e \u003e I intentionally omitted the parameter M (minimum subset size) from the shares because including it would give an adversary a vital piece of information. Likewise, including any kind of information that would allow a determination of whether the secret has been correctly reconstituted would give an adversary too much information. Failing silently when given incorrect shares or an insufficient number of shares is intentional.\n\u003e \n\u003e I do not believe this is a good tradeoff. It's basically obfuscation of\n\u003e something that is already considered secure at the expense of\n\u003e usability. It's much more important to me that the user understands\n\u003e what is in their hands (or their family members after they get hit by a\n\u003e bus), than to obfuscate the parameters of the secret sharing to provide\n\u003e a tiny disadvantage to an adversary who gets ahold of one. \n\u003e \n\u003e The fact that it fails silently is really all downside, not a benefit. \n\u003e If I have enough fragments, I can reconstruct the seed and see that it\n\u003e produces addresses with money. If not, I know I need more fragments. \n\u003e I'm much more concerned about my family having all the info they need to\n\u003e recover the money, than an attacker knowing that he needs two more\n\u003e fragments instead of which are well-secured anyway.\n\nFor what it's worth, ssss also omits from the shares any information about the threshold. It will happily return a garbage secret if too few shares are combined. (And actually, it will happily return a garbage secret if too *many* shares are combined, too. My implementation does not have that problem.)",
"sig": "1d28f54b1c60ad6ab05a34275236638598813b418f7b3d830835ac93c899f08f3e900d6fad0898d8359d3d64c92948de57993333df1747e8d8a56a77ae854263"
}