📅 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.
Andreas Schildbach [ARCHIVE] /
npub1xg…adsv7
2023-06-07 15:25:41
in reply to nevent1q…tddk
Author Public Key
npub1xg2m84malu0cfm4444r0kysx4rgk27e75aj6sz6538kw8fcz627qeadsv7Published at
2023-06-07 15:25:41Event JSON
{
"id": "85242212ea9e1fc72d7ff1d4c9a30381a784896fccd1e0566ba739bd759bf1f6",
"pubkey": "3215b3d77dff1f84eeb5ad46fb1206a8d1657b3ea765a80b5489ece3a702d2bc",
"created_at": 1686151541,
"kind": 1,
"tags": [
[
"e",
"5045235f447739204820462b94c541446b82ef26097d3889eeeed0767ae1d197",
"",
"root"
],
[
"e",
"add975312081c636df7ad68e0b546610f61e8ac1d29323d0a82085af3a4bc7a4",
"",
"reply"
],
[
"p",
"b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11"
]
],
"content": "📅 Original date posted:2014-09-12\n📝 Original message:On 09/12/2014 03:49 PM, Mike Hearn wrote:\n\n\u003e (1) Base64 of SHA256 seems overkill. 256 bits of hash is a lot. The risk\n\u003e here is that a MITM intercepts the payment request, which will be\n\u003e typically requested just seconds after the QR code is vended. 80 bits of\n\u003e entropy would still be a lot and take a long time to brute force, whilst\n\u003e keeping QR codes more compact, which impacts scannability.\n\nTo put that into perspective, here is how a bitcoin: URI would look like:\nbitcoin:?h=J-J-4mra0VorfffEZm5J7mBmHGKX86Dpt-TnnmC_fhE\u0026r=http://wallet.schildbach.de/bip70/r1409992884.bitcoinpaymentrequest\n(obviously for real-world usage you would optimize the \"r\" parameter)\n\nI looked at the list in this doc to evaluate what's easily available:\nhttps://code.google.com/p/guava-libraries/wiki/HashingExplained\n\nI thought SHA1 has a bad reputation these days, and we don't save much\nby using it. I don't know anything about Murmur. MD5 is clearly broken.\nWhat hash function would you recommend?\n\n\u003e (2) This should *not* be necessary in the common HTTPS context.\n\nIt is. People can't check names. People don't want to check names.\nPeople can't get certificates for lots of reasons. X.509 is centralized.\nX.509 has had serious security issues in the past. And shit continues to\nhappen.\n\nTo sum up, X.509 can't replace the trust anchor that is established by\nscanning a QR code or tapping two devices together.\n\n\u003e (3) This can be useful in the Bluetooth context, but then again, we\n\u003e could also do things a different way by signing with the key in the\n\u003e first part of the URI, thus avoiding the need for a hash.\n\nSure. But signing is harder than just calculating a hash.",
"sig": "b5b2d5ee622d39df31526f21194d2e57b171555459b8e972d1b80da3671fcc536dfb3eb6acaf54bcbd65268ea4f87dd1c5bfddf79372617ac92846d4937b5eb4"
}