rich1.0npub1xg2m84malu0cfm4444r0kysx4rgk27e75aj6sz6538kw8fcz627qeadsv7https://nostr.ae/npub1xg2m84malu0cfm4444r0kysx4rgk27e75aj6sz6538kw8fcz627qeadsv7njumphttps://nostr.ae📅 Original date posted:2014-09-12 📝 Original message: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.