diff options
| author | Christophe Biocca <christophe.biocca@gmail.com> | 2014-09-12 11:33:36 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-09-12 15:33:44 +0000 |
| commit | 7a340a815e3b18d2906e50c9192d641bdf201ba1 (patch) | |
| tree | eb7beb65dbe8b7ea67948c64147f3a480f15b8d9 | |
| parent | 455e3df4bbe0be32d99c7752c24dba3a8c238118 (diff) | |
| download | pi-bitcoindev-7a340a815e3b18d2906e50c9192d641bdf201ba1.tar.gz pi-bitcoindev-7a340a815e3b18d2906e50c9192d641bdf201ba1.zip | |
Re: [Bitcoin-development] BIP72 amendment proposal
| -rw-r--r-- | 86/32492a9a8a6ecb79bd9c4a100305621937682b | 139 |
1 files changed, 139 insertions, 0 deletions
diff --git a/86/32492a9a8a6ecb79bd9c4a100305621937682b b/86/32492a9a8a6ecb79bd9c4a100305621937682b new file mode 100644 index 000000000..d98e9a402 --- /dev/null +++ b/86/32492a9a8a6ecb79bd9c4a100305621937682b @@ -0,0 +1,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 + + |