Re: [Bitcoin-development] BIP72 amendment proposal

Re: [Bitcoin-development] BIP72 amendment proposal

[Mark van Cuijk]

On 12 Sep 2014, at 11:55 , bitcoin-development-request@lists.sourceforge.net wrote:

> The hash is meant to link the trust anchor (e.g. the QR code) to the
> payment request message in a secure way. This will solve the problem
> several apps are comparing address+amount fields as a workaround
> instead, preventing some advanced BIP70 usecases. When these apps read a
> matching hash, they need not compare any of the other fields.

Sounds like a good plan.

Do you have a list (possibly incomplete) of apps that perform this kind of checking? We’re currently working with some parties in a supply chain to allow a consumer payment on a retail website to automatically pay supply chain parties, the way BIP70 allows with multiple outputs on a transaction. This behaviour would prohibit this use case.

/Mark

Re: [Bitcoin-development] BIP72 amendment proposal

[Andreas Schildbach]

On 09/12/2014 12:11 PM, Mark van Cuijk wrote:
> On 12 Sep 2014, at 11:55 , bitcoin-development-request@lists.sourceforge.net wrote:
> 
>> The hash is meant to link the trust anchor (e.g. the QR code) to the
>> payment request message in a secure way. This will solve the problem
>> several apps are comparing address+amount fields as a workaround
>> instead, preventing some advanced BIP70 usecases. When these apps read a
>> matching hash, they need not compare any of the other fields.
> 
> Sounds like a good plan.
> 
> Do you have a list (possibly incomplete) of apps that perform this kind of checking? We’re currently working with some parties in a supply chain to allow a consumer payment on a retail website to automatically pay supply chain parties, the way BIP70 allows with multiple outputs on a transaction. This behaviour would prohibit this use case.

Hard to say, but here is my last assertion:

- Bitcoin Wallet
- Hive Bitcoin Wallet (checked by source)
- countless (> 300) forks/clones of Bitcoin Wallet

Since you're planning an advanced BIP70 usecase, you'll also have to
deal with the many wallets that don't support BIP70 at all.

Re: [Bitcoin-development] BIP72 amendment proposal

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1373 bytes --]

Re: [Bitcoin-development] BIP72 amendment proposal

[Jeff Garzik]

Indeed -- Every byte added to the QR code makes it more difficult to
be used in restaurants, pubs and other low-light conditions.  BitPay
tested some of these scenarios.

Scannability is absolutely impacted.

On Fri, Sep 12, 2014 at 9:49 AM, Mike Hearn <mike@plan99.net> wrote:
> 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.
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] BIP72 amendment proposal

[Andreas Schildbach]

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.

Re: [Bitcoin-development] BIP72 amendment proposal

[Christophe Biocca]

> What hash function would you recommend?

Due to the properties of hash functions, you can just take the first x
bits of a SHA256 sum and they're pretty much as good as an equally
secure hash function of that length. In fact SHA512/224 and SHA512/256
are defined in that way (Plus different initial values because you
might as well do that when defining a standard).

On Fri, Sep 12, 2014 at 10:36 AM, Andreas Schildbach
<andreas@schildbach.de> wrote:
> 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.
>
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP72 amendment proposal

[Christophe Biocca]

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.

That way we leave up to implementers to experiment with different
lengths and figure out what the optimum is (which could depend on the
security/convenience tradeoff of that particular transaction, as in
more bits for large payments).

On Fri, Sep 12, 2014 at 11:25 AM, Christophe Biocca
<christophe.biocca@gmail.com> wrote:
>> What hash function would you recommend?
>
> Due to the properties of hash functions, you can just take the first x
> bits of a SHA256 sum and they're pretty much as good as an equally
> secure hash function of that length. In fact SHA512/224 and SHA512/256
> are defined in that way (Plus different initial values because you
> might as well do that when defining a standard).
>
> On Fri, Sep 12, 2014 at 10:36 AM, Andreas Schildbach
> <andreas@schildbach.de> wrote:
>> 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.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Want excitement?
>> Manually upgrade your production database.
>> When you want reliability, choose Perforce
>> Perforce version control. Predictably reliable.
>> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP72 amendment proposal

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 168 bytes --]

>
> That way we leave up to implementers to experiment with different
> lengths and figure out what the optimum is


Ah, that's a good suggestion if we do go this way.

[-- Attachment #2: Type: text/html, Size: 395 bytes --]

Re: [Bitcoin-development] BIP72 amendment proposal

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 934 bytes --]

Putting aside the question of necessity for a moment, a more efficient
approach to this would be;

   1. Add another marker param like &s to the end of the URL
   2. Add another field to PaymentRequest that contains an ECC signature
   calculated using the public key that hashes to the address in the URI
   3. Upgraded wallets look for the additional param and if it's there,
   expect to find the PaymentDetails signed with the address key. PKI signing
   of course is still useful to provide an actual identity for receipts,
   display on hardware wallets, dispute mediation etc.

This adds only a few characters to a normal backwards-compatible QR code,
and is not hard to implement.


On Fri, Sep 12, 2014 at 5:37 PM, Mike Hearn <mike@plan99.net> wrote:

> That way we leave up to implementers to experiment with different
>> lengths and figure out what the optimum is
>
>
> Ah, that's a good suggestion if we do go this way.
>

[-- Attachment #2: Type: text/html, Size: 1512 bytes --]

Re: [Bitcoin-development] BIP72 amendment proposal

[Aaron Voisine]

Are there any circumstances where the payment request object might be
served over a different domain than the CNAME of the object's signer?

BIP72 states "Bitcoin wallets must support fetching PaymentRequests
via http and https protocols;". If the request object is signed by the
owner of the domain, then the worst an attacker who doesn't have the
signing key can do is replace the request with another validly signed
request intended for someone else, but that could be the attacker's
own product order, tricking someone else into paying for it.

Should BIP72 require that signed payment requests be from the same
domain, and also require https?

Aaron

Aaron Voisine
breadwallet.com


On Fri, Sep 12, 2014 at 9:31 AM, Mike Hearn <mike@plan99.net> wrote:
> Putting aside the question of necessity for a moment, a more efficient
> approach to this would be;
>
> Add another marker param like &s to the end of the URL
> Add another field to PaymentRequest that contains an ECC signature
> calculated using the public key that hashes to the address in the URI
> Upgraded wallets look for the additional param and if it's there, expect to
> find the PaymentDetails signed with the address key. PKI signing of course
> is still useful to provide an actual identity for receipts, display on
> hardware wallets, dispute mediation etc.
>
> This adds only a few characters to a normal backwards-compatible QR code,
> and is not hard to implement.
>
>
> On Fri, Sep 12, 2014 at 5:37 PM, Mike Hearn <mike@plan99.net> wrote:
>>>
>>> That way we leave up to implementers to experiment with different
>>> lengths and figure out what the optimum is
>>
>>
>> Ah, that's a good suggestion if we do go this way.
>
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

Re: [Bitcoin-development] BIP72 amendment proposal

[Andreas Schildbach]

On 09/12/2014 08:43 PM, Aaron Voisine wrote:

> Should BIP72 require that signed payment requests be from the same
> domain,

Although it currently does not seem to be used that way, I'd like to see
merchants sign their payment requests but store them on their payment
processors server. Currently if you buy from Humble Bundle, all you see
is Coinbase which is unfortunate.

> and also require https?

I think that's unrealistic. HTTP is already in use, and also the
proposed spec is open to other transports, e.g. Bluetooth which is also
already in common use.

Re: [Bitcoin-development] BIP72 amendment proposal

[Andreas Schildbach]

I agree that this would be another way of achieving the same goal. I'd
be fine with that if there is a majority.

However, I also see downsides of this approach:

1. It's more complicated. It touches more BIPs, and although signing is
terribly difficult its still more difficult than just hashing. E.g.
signing the payment request twice (ECC + X.509) poses the question in
which order you sign, and which signature fields to null for signing.

2. Isn't it discouraged to disclose the public key you're going to
receive coins on? (not sure about that)

3. Unlike an hash we can just re-assign to different objects (see my
proposal) I think we cannot easily do the same with a signature. It's
probably not very important to have this option, but still it should be
considered.

4. I'm afraid of the idea of re-purposing the BIP21 address. Someone
might send money to it although it isn't meant to receive money any more
(service is already using an advanced BIP70 usecase). A clear separation
into two parameters would prevent such mistakes, and as soon as the
address can go away the URL needn't be longer than it used to be.

5. A hash can be checked without knowing a secret. Are we excluding
stateless devices (e.g. proxies, smartwatches)?


Generally about the URL length discussion:

Currently we have address, amount and r, and it works well. In future we
would have h and r.

So all we need to do is make sure h not longer than address+amount. I
think this is already the case with untruncated SHA256 hashes. But I'd
be fine with truncating to maybe 192 bits to save a few characters.


On 09/12/2014 06:31 PM, Mike Hearn wrote:
> Putting aside the question of necessity for a moment, a more efficient
> approach to this would be;
> 
>  1. Add another marker param like &s to the end of the URL
>  2. Add another field to PaymentRequest that contains an ECC signature
>     calculated using the public key that hashes to the address in the URI
>  3. Upgraded wallets look for the additional param and if it's there,
>     expect to find the PaymentDetails signed with the address key. PKI
>     signing of course is still useful to provide an actual identity for
>     receipts, display on hardware wallets, dispute mediation etc.
> 
> This adds only a few characters to a normal backwards-compatible QR
> code, and is not hard to implement.
> 
> 
> On Fri, Sep 12, 2014 at 5:37 PM, Mike Hearn <mike@plan99.net
> <mailto:mike@plan99.net>> wrote:
> 
>         That way we leave up to implementers to experiment with different
>         lengths and figure out what the optimum is
> 
> 
>     Ah, that's a good suggestion if we do go this way. 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> 
> 
> 
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

Re: [Bitcoin-development] BIP72 amendment proposal

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1470 bytes --]

Your example doesn't have an address in it at all, so isn't compatible with
non-BIP70 wallets. Maybe for QRcodes specifically there are no longer any
such wallets out there. For clickable links it can still be an issue.


> 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?
>

Can just truncate SHA256, I think.


> It is. People can't check names. People don't want to check names.
>

Their wallet checks the name, though. It sees:

bitcoin:1AbCd?r=https://bitpay.com/r/12345

and the wallet verifies that the presented certificate is for CN=bitpay.com


> 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.
>

Well, I wrote an article that argues with this PoV:

https://medium.com/@octskyward/why-you-think-the-pki-sucks-b64cf5912aa7

No disagreement that it's a more complex mechanism. But seeing as we end up
depending on it anyway the moment you load any kind of web page to find out
the URI, adding another mechanism only increases complexity, it doesn't
remove any.

Sure. But signing is harder than just calculating a hash.


Well, again, it saves qrcode bytes. You don't have to include a dedicated
hash. The existing address hash can double up as both a backwards
compatibility measure, and also an auth mechanism.

[-- Attachment #2: Type: text/html, Size: 2722 bytes --]

Re: [Bitcoin-development] BIP72 amendment proposal

[Mark van Cuijk]

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.
> 
> 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

Re: [Bitcoin-development] BIP72 amendment proposal

[Wladimir]

On Fri, Sep 12, 2014 at 10:59 PM, Mark van Cuijk <mark@coinqy.com> wrote:
> 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.

But if they can truncate they can just as well pass a completely
different hash that matches their payment request. If an attacker can
change the bitcoin: URI, this scheme is broken.

The point of the proposal is to make sure that the payment request
matches the URI. So *if* you communicate the URI by secure means, this
authenticates the associated payment request as well, even if fetched
by insecure means (such as http:...) itself.

Wladimir

[Bitcoin-development] BIP72 amendment proposal

[Andreas Schildbach]

This is the discussion post corresponding to this PR:
https://github.com/bitcoin/bips/pull/106

"Amend BIP72 by an "h" parameter, which contains a hash of the
PaymentRequest message that is fetched via the "r" parameter.

The hash is meant to link the trust anchor (e.g. the QR code) to the
payment request message in a secure way. This will solve the problem
several apps are comparing address+amount fields as a workaround
instead, preventing some advanced BIP70 usecases. When these apps read a
matching hash, they need not compare any of the other fields.

Thanks to Julian Haight for helping with the standard."

Re: [Bitcoin-development] BIP72 amendment proposal

[Wladimir]

On Fri, Sep 12, 2014 at 11:29 AM, Andreas Schildbach
<andreas@schildbach.de> wrote:
> This is the discussion post corresponding to this PR:
> https://github.com/bitcoin/bips/pull/106
>
> "Amend BIP72 by an "h" parameter, which contains a hash of the
> PaymentRequest message that is fetched via the "r" parameter.
>
> The hash is meant to link the trust anchor (e.g. the QR code) to the
> payment request message in a secure way. This will solve the problem
> several apps are comparing address+amount fields as a workaround
> instead, preventing some advanced BIP70 usecases. When these apps read a
> matching hash, they need not compare any of the other fields.

Sounds like a good idea to me.

I had no idea that some clients were comparing addresses and amounts
in the URI with the payment request for security, that seems like a
hacky and inflexible way. This is much better.

Wladimir