From: Alan Reiner <etotheipi@gmail•com>
To: Tamas Blummer <tamas@bitsofproof•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys
Date: Sat, 29 Mar 2014 14:41:17 -0400 [thread overview]
Message-ID: <533713CD.3070403@gmail.com> (raw)
In-Reply-To: <19FE9882-7FC2-4518-BD50-8818B059271B@bitsofproof.com>
[-- Attachment #1: Type: text/plain, Size: 2995 bytes --]
Armory does exactly this: it defines the "Fragment ID" as the first few
bytes of the hash of the root pubKey + M-parameter, converted to
base58. Then it explains to the user "All fragments with the same
fragment ID are compatible" (which only works if you use deterministic
coefficients). Each fragment is then labeled with "[FragID]-#1",
"[FragID]-#2", etc. It became quite useful for organizing the fragments
and documenting how I was distributing them, especially if I had printed
or saved the same fragment twice by accident.
On 03/29/2014 02:16 PM, Tamas Blummer wrote:
> I also think that we can add usability features if the underlying
> secret remains well protected.
> I do not think there is any reason to assume that the knowledge of the
> degree of the polynomial, would aid an attacker.
>
> Similarly a fingerprint of the secret if it is unrelated to the hash
> used in the polinomyal should leak no useful information,
>
> The length of such fingerpring (say 4 bytes) and the degree (1 byte)
> does not seem a big overhead for me.
>
> Remember that the biggest obstacle of Bitcoin is usability not security.
>
> Regards,
>
> Tamas Blummer
> http://bitsofproof.com
>
> On 29.03.2014, at 18:52, Alan Reiner <etotheipi@gmail•com
> <mailto:etotheipi@gmail•com>> 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.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> <mailto:Bitcoin-development@lists•sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
[-- Attachment #2: Type: text/html, Size: 8228 bytes --]
next prev parent reply other threads:[~2014-03-29 18:41 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CACsn0ckScTWG4YxNCscxvtdsmcUkxtR2Gi-rdBs2HCkirPz5rA@mail.gmail.com>
2014-03-29 15:44 ` Matt Whitlock
2014-03-29 16:59 ` Alan Reiner
2014-03-29 17:19 ` Matt Whitlock
2014-03-29 17:52 ` Alan Reiner
2014-03-29 18:00 ` Matt Whitlock
2014-03-29 18:08 ` Alan Reiner
2014-03-29 18:10 ` Matt Whitlock
[not found] ` <CAAt2M18j7bGDsKouVw+e4j+FMiJ4vK6-sx+nrkwHyiKLqiH7Jg@mail.gmail.com>
2014-03-29 19:34 ` Natanael
2014-04-04 2:38 ` Jeff Garzik
2014-03-29 18:16 ` Tamas Blummer
2014-03-29 18:41 ` Alan Reiner [this message]
2014-03-29 17:28 ` Roy Badami
2014-03-29 17:42 ` Matt Whitlock
2014-03-29 17:51 ` Roy Badami
2014-03-29 17:28 ` devrandom
[not found] ` <1396113933.8809.91.camel@mimiz>
2014-03-29 17:38 ` Matt Whitlock
2014-03-29 17:46 ` Gregory Maxwell
2014-03-29 19:49 ` Tamas Blummer
2014-03-29 17:48 ` devrandom
2014-03-29 17:51 ` Matt Whitlock
2014-03-29 17:56 ` devrandom
2014-04-03 12:41 Nikita Schmidt
2014-04-03 21:42 ` Matt Whitlock
2014-04-04 13:51 ` Nikita Schmidt
2014-04-04 14:14 ` Gregory Maxwell
2014-04-04 16:05 ` Matt Whitlock
2014-04-04 16:25 ` Gregory Maxwell
2014-04-04 16:36 ` Matt Whitlock
2014-04-04 17:08 ` Gregory Maxwell
2014-04-04 17:16 ` Matt Whitlock
2014-04-04 17:51 ` Gregory Maxwell
2014-04-04 18:53 ` Matt Whitlock
2014-04-04 16:03 ` Matt Whitlock
2014-04-08 0:33 ` Nikita Schmidt
2014-04-08 0:38 ` Gregory Maxwell
2014-04-08 1:46 ` Matt Whitlock
2014-04-08 2:07 ` Gregory Maxwell
2014-04-08 11:52 ` Matt Whitlock
2014-04-10 22:31 ` Nikita Schmidt
2014-04-22 8:06 ` Jan Møller
2014-04-22 8:11 ` Matt Whitlock
2014-04-22 8:27 ` Jan Møller
2014-04-22 8:29 ` Matt Whitlock
2014-04-22 8:39 ` Jan Møller
2014-04-22 8:43 ` Matt Whitlock
2014-04-22 8:51 ` Jan Møller
2014-04-22 9:13 ` Matt Whitlock
2014-04-22 11:50 ` Justin A
2014-04-22 8:35 ` Matt Whitlock
2014-04-22 8:39 ` Tamas Blummer
2014-04-22 8:40 ` Matt Whitlock
2014-04-22 8:43 ` Tamas Blummer
2014-04-22 8:47 ` Matt Whitlock
2014-04-22 8:50 ` Tamas Blummer
2014-04-22 15:32 ` Mark Friedenbach
2014-04-22 15:49 ` Tamas Blummer
2014-04-22 17:03 ` Mark Friedenbach
2014-04-22 17:07 ` Jan Møller
2014-04-22 18:29 ` Tamas Blummer
2014-04-22 18:46 ` Gregory Maxwell
2014-04-23 5:33 ` Tamas Blummer
2014-04-23 6:16 ` Gregory Maxwell
2014-05-05 19:36 ` Nikita Schmidt
2014-05-12 12:09 ` Jan Møller
2014-08-14 19:23 ` Nikita Schmidt
2014-04-22 13:37 ` Nikita Schmidt
2014-04-22 8:15 ` Gregory Maxwell
2014-04-22 8:49 ` Jan Møller
-- strict thread matches above, loose matches on Subject: below --
2014-03-29 8:05 Matt Whitlock
2014-03-29 8:34 ` Tamas Blummer
2014-03-29 8:44 ` Tamas Blummer
2014-03-29 8:51 ` Matt Whitlock
2014-03-29 8:54 ` Matt Whitlock
2014-03-29 16:54 ` Matt Whitlock
2014-03-29 17:37 ` Tamas Blummer
2014-03-29 9:08 ` Chris Beams
2014-03-29 9:31 ` Matt Whitlock
2014-03-29 11:16 ` Matt Whitlock
2014-03-29 11:54 ` Chris Beams
2014-03-29 13:27 ` Jeff Garzik
2014-03-29 13:36 ` Mike Hearn
2014-03-29 13:38 ` Tamas Blummer
2014-03-29 14:10 ` Matt Whitlock
2014-03-29 14:19 ` Jeff Garzik
2014-03-29 14:55 ` Matt Whitlock
2014-03-29 15:04 ` Mike Hearn
2014-03-29 14:28 ` Watson Ladd
2014-03-29 14:36 ` Gregory Maxwell
2014-03-29 15:01 ` Matt Whitlock
2014-03-29 9:21 ` Chris Beams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=533713CD.3070403@gmail.com \
--to=etotheipi@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=tamas@bitsofproof$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox