From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: References: Date: Fri, 12 Sep 2014 11:33:36 -0400 Message-ID: From: Christophe Biocca To: Andreas Schildbach 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" Subject: Re: [Bitcoin-development] BIP72 amendment proposal X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 > 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