1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1WW8Hb-0001nG-U8
for bitcoin-development@lists.sourceforge.net;
Fri, 04 Apr 2014 17:52:04 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.175 as permitted sender)
client-ip=209.85.217.175; envelope-from=gmaxwell@gmail.com;
helo=mail-lb0-f175.google.com;
Received: from mail-lb0-f175.google.com ([209.85.217.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WW8Hb-00041c-14
for bitcoin-development@lists.sourceforge.net;
Fri, 04 Apr 2014 17:52:03 +0000
Received: by mail-lb0-f175.google.com with SMTP id w7so2697033lbi.6
for <bitcoin-development@lists.sourceforge.net>;
Fri, 04 Apr 2014 10:51:56 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.235.3 with SMTP id ui3mr9610506lac.2.1396633916400; Fri,
04 Apr 2014 10:51:56 -0700 (PDT)
Received: by 10.112.89.68 with HTTP; Fri, 4 Apr 2014 10:51:56 -0700 (PDT)
In-Reply-To: <60732286.zdbbI6td0e@crushinator>
References: <CAC7yFxSE8-TWPN-kuFiqdPKMDuprbiVJi7-z-ym+AUyA_f-xJw@mail.gmail.com>
<1888881.3JyvKYNUFa@crushinator>
<CAAS2fgTEMtH99yvwv_79UvUQjFOuZymHOaa1+ZzYmKvaUDPmTA@mail.gmail.com>
<60732286.zdbbI6td0e@crushinator>
Date: Fri, 4 Apr 2014 10:51:56 -0700
Message-ID: <CAAS2fgT=n48F9=Yk9k1Vu3_8nsExAjaHYbUeW60q2bMN1pi-qA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Matt Whitlock <bip@mattwhitlock.name>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 2.4 (++)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
4.0 HK_SCAM_N2 BODY: HK_SCAM_N2
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WW8Hb-00041c-14
Cc: bitcoin-development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret
Sharing of Bitcoin private keys
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 04 Apr 2014 17:52:05 -0000
On Fri, Apr 4, 2014 at 10:16 AM, Matt Whitlock <bip@mattwhitlock.name> wrot=
e:
> Honestly, that sounds a lot more complicated than what I have now. I made=
my current implementation because I just wanted something simple that woul=
d let me divide a private key into shares for purposes of dissemination to =
my next of kin et al.
I suggest you go look at some of the other secret sharing
implementations that use GF(2^8), they end up just being a couple of
dozen lines of code. Pretty simple stuff, and they work efficiently
for all sizes of data, there are implementations in a multitude of
languages. There are a whole bunch of these.
> I already have a fairly polished implementation of my BIP, and it's not w=
ritten in a "very high-level language"; it's C++, and the parts that do the=
big-integer arithmetic are basically C. I'm using the GMP library: very st=
raightforward, very reliable, very fast.
With respect for the awesome work that GMP is=E2=80=94 It's 250,000 lines =
of
LGPLed code. It's not just "pic microcontrollers" that would find
that scale of a dependency unwelcome.
> Do you have a use case in mind that would benefit from byte-wise operatio=
ns rather than big-integer operations? I mean, I guess if you were trying t=
o implement this BIP on a PIC microcontroller, it might be nice to process =
the secret in smaller bites. (No pun intended.) But I get this feeling that=
you're only pushing me away from the present incarnation of my proposal be=
cause you think it's too similar (but not quite similar enough) to a thresh=
old ECDSA key scheme.
It lets you efficiently scale to any size data being encoded without
extra overhead or having additional primes. It can be compactly
implemented in Javascript (there are several implementations you can
find if you google), it shouldn't be burdensome to implement on a
device like a trezor (much less a real microcontroller).
And yea, sure, it's distinct from the implementation you'd use for
threshold signing. A threshold singing one would lack the size agility
or the easy of implementation on limited devices. So I do think that
if there is to be two it would be good to gain the advantages that
can't be achieved in an threshold ECDSA compatible approach.
|
