Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2014-09-12 📝 Original message:A few thoughts on this: ...
📅 Original date posted:2014-09-12
📝 Original message:A few thoughts on this:
(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.
(2) This should *not* be necessary in the common HTTPS context. The QR code
itself is going to be fetched from some service, over HTTPS. I see no
reasonable attacker that can MITM the request for the BIP70 message but not
the request to get the QR code. Adding a hash makes QR codes more bloated
and harder to scan, all on the assumption that HTTPS is broken in some odd
way that we haven't actually ever seen in practice.
(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.
I know I've been around the loop on this one with Andreas many times. But
this BIP doesn't fix any actually existing problem in the previous spec. It
exists because Andreas thinks SSL is useless. If SSL is useless we all have
much bigger problems.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140912/4985906c/attachment.html>;
📝 Original message:A few thoughts on this:
(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.
(2) This should *not* be necessary in the common HTTPS context. The QR code
itself is going to be fetched from some service, over HTTPS. I see no
reasonable attacker that can MITM the request for the BIP70 message but not
the request to get the QR code. Adding a hash makes QR codes more bloated
and harder to scan, all on the assumption that HTTPS is broken in some odd
way that we haven't actually ever seen in practice.
(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.
I know I've been around the loop on this one with Andreas many times. But
this BIP doesn't fix any actually existing problem in the previous spec. It
exists because Andreas thinks SSL is useless. If SSL is useless we all have
much bigger problems.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140912/4985906c/attachment.html>;