Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Mark van Cuijk <mark@coinqy.com>
In-Reply-To: <mailman.342174.1410547421.2163.bitcoin-development@lists.sourceforge.net>
Date: Fri, 12 Sep 2014 22:59:19 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <06D9FBBD-30DB-4591-A932-B5A19F1D6543@coinqy.com>
References: <mailman.342174.1410547421.2163.bitcoin-development@lists.sourceforge.net>
To: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] BIP72 amendment proposal
Precedence: list

On 12 Sep 2014, at 20:43 , =
bitcoin-development-request@lists.sourceforge.net wrote:

> Specifically relevant here:
> =
http://security.stackexchange.com/questions/34796/truncating-the-output-of=
-sha256-to-128-bits.
>=20
> 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=92t =
have an authenticated way of knowing the expected length of the hash, a =
MITM attacker can just truncate the hash to lower security.

/Mark=