rich1.0npub1mtxs7jztn027d9cylej99hltqq9vq84uxm80zl4naxafd9hpxqwsj9g5zmhttps://nostr.ae/npub1mtxs7jztn027d9cylej99hltqq9vq84uxm80zl4naxafd9hpxqwsj9g5zmnjumphttps://nostr.ae📅 Original date posted:2014-09-12 📝 Original message:> 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 at 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 at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development