public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Andreas Schildbach <andreas@schildbach•de>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] BIP72 amendment proposal
Date: Fri, 12 Sep 2014 16:36:41 +0200	[thread overview]
Message-ID: <luv0dp$qms$1@ger.gmane.org> (raw)
In-Reply-To: <CANEZrP1iTfZxY915hzoAEApz1+wd_S9j5RCwVJCNFqQ_+DNTSQ@mail.gmail.com>

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.





  parent reply	other threads:[~2014-09-12 14:37 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 ` 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 [this message]
2014-09-12 15:25         ` Christophe Biocca
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='luv0dp$qms$1@ger.gmane.org' \
    --to=andreas@schildbach$(echo .)de \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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