Re: [Bitcoin-development] BIP72 amendment proposal
On 12 Sep 2014, at 20:43 , bitcoin-development-requ...@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 -- 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
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 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 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 > -- 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] Small update to BIP 62
On Mon, Sep 8, 2014 at 1:31 AM, Pieter Wuille wrote: > I've sent out a new pull request > (https://github.com/bitcoin/bips/pull/102/files) that: > * Changes the order of the rules. > * Adds more reference documentation about minimal pushes and number encodings. > * Clarified that extra consensus rules cannot prevent someone from > creating outputs whose spending transactions will be malleable. > > I haven't changed which rules are mandatory in v3, so this is a pure > clarification & reorganization of the text. Changes: https://github.com/bitcoin/bips/pull/102/files Gregory, Jeff: does this address your concerns? Others: comments? -- Pieter -- 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
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 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
> > 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
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. -- 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
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 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 > 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 -- 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
> 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 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 -- 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
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
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 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/ -- 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
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
Re: [Bitcoin-development] BIP72 amendment proposal
On 09/12/2014 12:11 PM, Mark van Cuijk wrote: > On 12 Sep 2014, at 11:55 , bitcoin-development-requ...@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. -- 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
On 12 Sep 2014, at 11:55 , bitcoin-development-requ...@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 -- 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
On Fri, Sep 12, 2014 at 11:29 AM, Andreas Schildbach 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 -- 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
[Bitcoin-development] BIP72 amendment proposal
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." -- 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
