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; 
MIME-Version: 1.0
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
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP72 amendment proposal
Precedence: list

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