{"type":"rich","version":"1.0","author_name":"npub1mtxs7jztn027d9cylej99hltqq9vq84uxm80zl4naxafd9hpxqwsj9g5zm","author_url":"https://nostr.ae/npub1mtxs7jztn027d9cylej99hltqq9vq84uxm80zl4naxafd9hpxqwsj9g5zm","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-09-12\n📝 Original message:\u003e What hash function would you recommend?\n\nDue to the properties of hash functions, you can just take the first x\nbits of a SHA256 sum and they're pretty much as good as an equally\nsecure hash function of that length. In fact SHA512/224 and SHA512/256\nare defined in that way (Plus different initial values because you\nmight as well do that when defining a standard).\n\nOn Fri, Sep 12, 2014 at 10:36 AM, Andreas Schildbach\n\u003candreas at schildbach.de\u003e wrote:\n\u003e On 09/12/2014 03:49 PM, Mike Hearn wrote:\n\u003e\n\u003e\u003e (1) Base64 of SHA256 seems overkill. 256 bits of hash is a lot. The risk\n\u003e\u003e here is that a MITM intercepts the payment request, which will be\n\u003e\u003e typically requested just seconds after the QR code is vended. 80 bits of\n\u003e\u003e entropy would still be a lot and take a long time to brute force, whilst\n\u003e\u003e keeping QR codes more compact, which impacts scannability.\n\u003e\n\u003e To put that into perspective, here is how a bitcoin: URI would look like:\n\u003e bitcoin:?h=J-J-4mra0VorfffEZm5J7mBmHGKX86Dpt-TnnmC_fhE\u0026r=http://wallet.schildbach.de/bip70/r1409992884.bitcoinpaymentrequest\n\u003e (obviously for real-world usage you would optimize the \"r\" parameter)\n\u003e\n\u003e I looked at the list in this doc to evaluate what's easily available:\n\u003e https://code.google.com/p/guava-libraries/wiki/HashingExplained\n\u003e\n\u003e I thought SHA1 has a bad reputation these days, and we don't save much\n\u003e by using it. I don't know anything about Murmur. MD5 is clearly broken.\n\u003e What hash function would you recommend?\n\u003e\n\u003e\u003e (2) This should *not* be necessary in the common HTTPS context.\n\u003e\n\u003e It is. People can't check names. People don't want to check names.\n\u003e People can't get certificates for lots of reasons. X.509 is centralized.\n\u003e X.509 has had serious security issues in the past. And shit continues to\n\u003e happen.\n\u003e\n\u003e To sum up, X.509 can't replace the trust anchor that is established by\n\u003e scanning a QR code or tapping two devices together.\n\u003e\n\u003e\u003e (3) This can be useful in the Bluetooth context, but then again, we\n\u003e\u003e could also do things a different way by signing with the key in the\n\u003e\u003e first part of the URI, thus avoiding the need for a hash.\n\u003e\n\u003e Sure. But signing is harder than just calculating a hash.\n\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Want excitement?\n\u003e Manually upgrade your production database.\n\u003e When you want reliability, choose Perforce\n\u003e Perforce version control. Predictably reliable.\n\u003e http://pubads.g.doubleclick.net/gampad/clk?id=157508191\u0026iu=/4140/ostg.clktrk\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development"}