public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Christophe Biocca <christophe.biocca@gmail.com>
To: Andreas Schildbach <andreas@schildbach.de>
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP72 amendment proposal
Date: Fri, 12 Sep 2014 11:25:48 -0400	[thread overview]
Message-ID: <CANOOu=8RJgUW+=regOcqa9udiLr=nK=4fiZoW0fj2UU2GCjH3w@mail.gmail.com> (raw)
In-Reply-To: <luv0dp$qms$1@ger.gmane.org>

> 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



  reply	other threads:[~2014-09-12 15:25 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.341412.1410515709.2178.bitcoin-development@lists.sourceforge.net>
2014-09-12 10:11 ` [Bitcoin-development] BIP72 amendment proposal Mark van Cuijk
2014-09-12 11:07   ` Andreas Schildbach
2014-09-12 13:49     ` Mike Hearn
2014-09-12 14:15       ` Jeff Garzik
2014-09-12 14:36       ` Andreas Schildbach
2014-09-12 15:25         ` Christophe Biocca [this message]
2014-09-12 15:33           ` Christophe Biocca
2014-09-12 15:37             ` Mike Hearn
2014-09-12 16:31               ` Mike Hearn
2014-09-12 18:43                 ` Aaron Voisine
2014-09-15  7:43                   ` Andreas Schildbach
2014-09-15  7:12                 ` Andreas Schildbach
2014-09-12 15:36         ` Mike Hearn
     [not found] <mailman.342174.1410547421.2163.bitcoin-development@lists.sourceforge.net>
2014-09-12 20:59 ` Mark van Cuijk
2014-09-13  8:53   ` Wladimir
2014-09-12  9:29 Andreas Schildbach
2014-09-12  9:55 ` Wladimir

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='CANOOu=8RJgUW+=regOcqa9udiLr=nK=4fiZoW0fj2UU2GCjH3w@mail.gmail.com' \
    --to=christophe.biocca@gmail.com \
    --cc=andreas@schildbach.de \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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