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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jeremy@taplink.co>) id 1VAQnJ-0007KN-KM
for bitcoin-development@lists.sourceforge.net;
Fri, 16 Aug 2013 20:38:49 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of taplink.co
designates 50.117.27.232 as permitted sender)
client-ip=50.117.27.232; envelope-from=jeremy@taplink.co;
helo=mail.taplink.co;
Received: from mail.taplink.co ([50.117.27.232])
by sog-mx-3.v43.ch3.sourceforge.com with smtp (Exim 4.76)
id 1VAQnI-00035L-P1 for bitcoin-development@lists.sourceforge.net;
Fri, 16 Aug 2013 20:38:49 +0000
Received: from laptop-air ([192.168.168.158]) by mail.taplink.co ;
Fri, 16 Aug 2013 12:40:17 -0700
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: "Bitcoin Development" <bitcoin-development@lists.sourceforge.net>
References: <CAAS2fgQFOei6we8nfSr9DuQuHEjXT+G8_XGMk9um14DBgRuPyA@mail.gmail.com>
Date: Fri, 16 Aug 2013 12:37:50 -0700
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Jeremy Spilman" <jeremy@taplink.co>
Organization: TapLink
Message-ID: <op.w1xctcddyldrnw@laptop-air>
In-Reply-To: <CAAS2fgQFOei6we8nfSr9DuQuHEjXT+G8_XGMk9um14DBgRuPyA@mail.gmail.com>
User-Agent: Opera Mail/1.0 (Win32)
oclient: 192.168.168.158#jeremy@taplink.co#465
X-Spam-Score: -4.3 (----)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
-2.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-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: 1VAQnI-00035L-P1
Subject: Re: [Bitcoin-development] BIP 32.5
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, 16 Aug 2013 20:38:49 -0000
I personally like the full-measure of eliminating the "CS-PRNG" entirely
from signing. If the "random" component is assumed to be untrusted,
keeping it in there adds no value, while eschewing the main benefit of
deterministic signing (ease of testing, auditing)
This just leaves the CS-PRNG at the heart of the security system -- when
generating the root master key of an HD wallet. Adding to what Mike said,
a single invocation of a CS-PRNG driving all subsequent keys increases the
attack value if that one invocation turns out to be weak. By comparison,
at least compromised DSA signatures were one-off events which didn't allow
theft of funds beyond the one compromised address.
Cumulative / rolling entropy collection over time through multiple CS-PRNG
invocations, or multiple entropy sources, could serve to recover from an
"occasionally weak" CS-PRNG. I've read claims that this is bad practice
because a single low entropy source can take entropy out of the result,
but this seems like FUD. If you're using SHA512-HMAC to hash chain a few
entropy sources, even "return 4; // chosen by random dice roll" is not
going to help, but it's not going to hurt.
The DSA 'repeated-k' basically advertises itself on the block-chain and
people were actively scanning for this weakness, whereas a weak key in the
BIP32 root might not be as apparent, so exploitation may be more
difficult, but also more insidious. Of course this depends on the exact
failure mode of the CS-PRNG being used -- I wonder if anyone is searching
for BIP32 keys based off of one of the 32k Debian random numbers being
used as a master key?
Smartphones in particular have lots of sensors which could provide
entropy. For example, if you pulled 64 bytes from "secure random", you
could at least HMAC that with the SHA512 of a picture or a short video
sample taken by the user. I'm guessing some people would cringe at this,
but it seems to me like it provides some measure of protection to justify
the increased code complexity.
TL;DR - Really like the idea of minimizing CS-PRNG use whenever possible
(deterministic signing) and also would love to learn more best practices
for placing less trust in the so called "CS-PRNG" when we do have to use
them.
Thanks,
Jeremy
|
