Mark van Cuijk [ARCHIVE] on Nostr: 📅 Original date posted:2014-09-12 📝 Original message:On 12 Sep 2014, at 20:43 , ...
📅 Original date posted:2014-09-12
📝 Original message:On 12 Sep 2014, at 20:43 , bitcoin-development-request at lists.sourceforge.net wrote:
> Specifically relevant here:
> http://security.stackexchange.com/questions/34796/truncating-the-output-of-sha256-to-128-bits.
>
> If you're going to truncate though, why not just leave the amount of
> bits up the the person generating the QR code? The client simply takes
> the hash prefix (any length up to full 256-bits) and makes sure it's a
> strict prefix of the actual hash of the payment request.
If you do so, please make sure the length of the hash is included in the PaymentDetails/PaymentRequest. If someone parses the URI and doesn’t have an authenticated way of knowing the expected length of the hash, a MITM attacker can just truncate the hash to lower security.
/Mark
📝 Original message:On 12 Sep 2014, at 20:43 , bitcoin-development-request at lists.sourceforge.net wrote:
> Specifically relevant here:
> http://security.stackexchange.com/questions/34796/truncating-the-output-of-sha256-to-128-bits.
>
> If you're going to truncate though, why not just leave the amount of
> bits up the the person generating the QR code? The client simply takes
> the hash prefix (any length up to full 256-bits) and makes sure it's a
> strict prefix of the actual hash of the payment request.
If you do so, please make sure the length of the hash is included in the PaymentDetails/PaymentRequest. If someone parses the URI and doesn’t have an authenticated way of knowing the expected length of the hash, a MITM attacker can just truncate the hash to lower security.
/Mark