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
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <christophe.biocca@gmail.com>) id 1XSSr2-0006zR-4F
for bitcoin-development@lists.sourceforge.net;
Fri, 12 Sep 2014 15:33:44 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.176 as permitted sender)
client-ip=209.85.213.176;
envelope-from=christophe.biocca@gmail.com;
helo=mail-ig0-f176.google.com;
Received: from mail-ig0-f176.google.com ([209.85.213.176])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XSSr0-0002Pl-AG
for bitcoin-development@lists.sourceforge.net;
Fri, 12 Sep 2014 15:33:44 +0000
Received: by mail-ig0-f176.google.com with SMTP id hn15so712146igb.15
for <bitcoin-development@lists.sourceforge.net>;
Fri, 12 Sep 2014 08:33:36 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.43.137 with SMTP id w9mr3350401igl.36.1410536016653; Fri,
12 Sep 2014 08:33:36 -0700 (PDT)
Received: by 10.64.112.6 with HTTP; Fri, 12 Sep 2014 08:33:36 -0700 (PDT)
In-Reply-To: <CANOOu=8RJgUW+=regOcqa9udiLr=nK=4fiZoW0fj2UU2GCjH3w@mail.gmail.com>
References: <mailman.341412.1410515709.2178.bitcoin-development@lists.sourceforge.net>
<A4CC413B-D5A5-423C-9D56-463FCDBDDE08@coinqy.com>
<luuk5f$i8o$1@ger.gmane.org>
<CANEZrP1iTfZxY915hzoAEApz1+wd_S9j5RCwVJCNFqQ_+DNTSQ@mail.gmail.com>
<luv0dp$qms$1@ger.gmane.org>
<CANOOu=8RJgUW+=regOcqa9udiLr=nK=4fiZoW0fj2UU2GCjH3w@mail.gmail.com>
Date: Fri, 12 Sep 2014 11:33:36 -0400
Message-ID: <CANOOu=-yhKK-db+VtoJbWH8H_rwrNHqXM1J12SketBXeLL6L1Q@mail.gmail.com>
From: Christophe Biocca <christophe.biocca@gmail.com>
To: Andreas Schildbach <andreas@schildbach.de>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.6 (-)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(christophe.biocca[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: 1XSSr0-0002Pl-AG
Cc: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP72 amendment proposal
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, 12 Sep 2014 15:33:44 -0000
Specifically relevant here:
http://security.stackexchange.com/questions/34796/truncating-the-output-of-sha256-to-128-bits.
If you're going to truncate though, why not just leave the amount of
bits up the the person generating the QR code? The client simply takes
the hash prefix (any length up to full 256-bits) and makes sure it's a
strict prefix of the actual hash of the payment request.
That way we leave up to implementers to experiment with different
lengths and figure out what the optimum is (which could depend on the
security/convenience tradeoff of that particular transaction, as in
more bits for large payments).
On Fri, Sep 12, 2014 at 11:25 AM, Christophe Biocca
<christophe.biocca@gmail.com> wrote:
>> What hash function would you recommend?
>
> Due to the properties of hash functions, you can just take the first x
> bits of a SHA256 sum and they're pretty much as good as an equally
> secure hash function of that length. In fact SHA512/224 and SHA512/256
> are defined in that way (Plus different initial values because you
> might as well do that when defining a standard).
>
> On Fri, Sep 12, 2014 at 10:36 AM, Andreas Schildbach
> <andreas@schildbach.de> wrote:
>> On 09/12/2014 03:49 PM, Mike Hearn wrote:
>>
>>> (1) Base64 of SHA256 seems overkill. 256 bits of hash is a lot. The risk
>>> here is that a MITM intercepts the payment request, which will be
>>> typically requested just seconds after the QR code is vended. 80 bits of
>>> entropy would still be a lot and take a long time to brute force, whilst
>>> keeping QR codes more compact, which impacts scannability.
>>
>> To put that into perspective, here is how a bitcoin: URI would look like:
>> bitcoin:?h=J-J-4mra0VorfffEZm5J7mBmHGKX86Dpt-TnnmC_fhE&r=http://wallet.schildbach.de/bip70/r1409992884.bitcoinpaymentrequest
>> (obviously for real-world usage you would optimize the "r" parameter)
>>
>> I looked at the list in this doc to evaluate what's easily available:
>> https://code.google.com/p/guava-libraries/wiki/HashingExplained
>>
>> I thought SHA1 has a bad reputation these days, and we don't save much
>> by using it. I don't know anything about Murmur. MD5 is clearly broken.
>> What hash function would you recommend?
>>
>>> (2) This should *not* be necessary in the common HTTPS context.
>>
>> It is. People can't check names. People don't want to check names.
>> People can't get certificates for lots of reasons. X.509 is centralized.
>> X.509 has had serious security issues in the past. And shit continues to
>> happen.
>>
>> To sum up, X.509 can't replace the trust anchor that is established by
>> scanning a QR code or tapping two devices together.
>>
>>> (3) This can be useful in the Bluetooth context, but then again, we
>>> could also do things a different way by signing with the key in the
>>> first part of the URI, thus avoiding the need for a hash.
>>
>> Sure. But signing is harder than just calculating a hash.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Want excitement?
>> Manually upgrade your production database.
>> When you want reliability, choose Perforce
>> Perforce version control. Predictably reliable.
>> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
|
