Re: [Bitcoin-development] Proposal to address Bitcoin malware
BIP70 is quite safe agains MitB. If user copies URL belonging to other merchant, he would see the fact after entering it into his wallet application. The only problem is, attacker can buy from the same merchant with user's money. (sending him different URL) This can be mitigated by merchant setting memo to the description of the basket and some user info (e.g. address to which goods are sent). I think BIP 70 does a good job at verifying where the payment request came from. I’m not convinced this is the same as verifying the transaction (ideally OOB). But if whole computer is compromised, you're already screwed. Trezor should help, but I'm not sure if it supports BIP70. The reason for OOB verification is if the entire computer is compromised. Again, this may only be possible with a trusted intermediary or a web wallet. Brian Erdelyi -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal to address Bitcoin malware
BIP70 is quite safe agains MitB. If user copies URL belonging to other merchant, he would see the fact after entering it into his wallet application. The only problem is, attacker can buy from the same merchant with user's money. (sending him different URL) This can be mitigated by merchant setting memo to the description of the basket and some user info (e.g. address to which goods are sent). But if whole computer is compromised, you're already screwed. Trezor should help, but I'm not sure if it supports BIP70. 2015-02-01 14:49 GMT+02:00 Brian Erdelyi brian.erde...@gmail.com: In online banking, the banks generate account numbers. An attacker cannot generate their own account number and the likelihood of an attacker having the same account number that I am trying to transfer funds to is low and this is why OCRA is effective with online banking. With Bitcoin, the Bitcoin address is comparable to the recipient’s bank account number. I now see how an an attacker can brute force the bitcoin address with vanitygen. Is there any way to generate an 8 digit number from the bitcoin address that can be used to verify transactions in such a way (possibly with hashing?) that brute forcing a bitcoin address would take longer than a reasonable period of time (say 60 seconds) so a system could time out if a transaction was not completed in that time? I’ve also looked into BIP70 (Payment Protocol) that claims protection against man-in-the-middle/man-in-the-browser (MitB) based attacks. A common way to protect against this is with out-of-band transaction verification (http://en.wikipedia.org/wiki/Man-in-the-browser#Out-of-band_transaction_verification). I see how BIP 70 verifies the payment request, however, is there any way to verify that the transaction signed by the wallet matches the request before it is sent to the blockchain (and how can this support out of band verification)? Perhaps this is something that can only be supported when sending money with web based wallets. Brian Erdelyi -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal to address Bitcoin malware
I see how BIP 70 verifies the payment request, however, is there any way to verify that the transaction signed by the wallet matches the request before it is sent to the blockchain (and how can this support out of band verification)? No. It cannot be done in the Bitcoin context. Your wallet MUST be secure. Otherwise BIP70 is irrelevant - if the attacker can make your wallet sign some other transaction than what you expect, they can also just steal your private keys and use them directly. BIP70 is based on the assumption of a secure signing core that cannot be compromised, with devices like the TREZOR and 2-factor pairings of desktops and mobiles being an obvious use case. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] var_int ambiguous serialization consequences
On Sun, 1 Feb 2015, Tamas Blummer wrote: I wonder of consequences if var_int is used in its longer than necessary forms (e.g encoding 1 as 0xfd0100 instead of 0x01) In serialize.h lingo you are talking about CompactSize, not VarInt. CompactSizes indeed have redundancy in their representation, i.e. the same number can be represented as up to four different byte sequences. VARINTs have a different format that (AFAIK) isn't used anywhere in the block chain. See WriteVarInt / ReadVarInt. These were designed to not have any redundancy in their representation. This is already of interest if applying size limit to a block, since transaction count is var_int but is not part of the hashed header or the merkle tree. Are you sure that this is a current concern? Non-canonical CompactSizes are forbidden - in serialize.h this is flagged in ReadCompactSize. Wladimir -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal to address Bitcoin malware
In online banking, the banks generate account numbers. An attacker cannot generate their own account number and the likelihood of an attacker having the same account number that I am trying to transfer funds to is low and this is why OCRA is effective with online banking. With Bitcoin, the Bitcoin address is comparable to the recipient’s bank account number. I now see how an an attacker can brute force the bitcoin address with vanitygen. Is there any way to generate an 8 digit number from the bitcoin address that can be used to verify transactions in such a way (possibly with hashing?) that brute forcing a bitcoin address would take longer than a reasonable period of time (say 60 seconds) so a system could time out if a transaction was not completed in that time? I’ve also looked into BIP70 (Payment Protocol) that claims protection against man-in-the-middle/man-in-the-browser (MitB) based attacks. A common way to protect against this is with out-of-band transaction verification (http://en.wikipedia.org/wiki/Man-in-the-browser#Out-of-band_transaction_verification http://en.wikipedia.org/wiki/Man-in-the-browser#Out-of-band_transaction_verification). I see how BIP 70 verifies the payment request, however, is there any way to verify that the transaction signed by the wallet matches the request before it is sent to the blockchain (and how can this support out of band verification)? Perhaps this is something that can only be supported when sending money with web based wallets. Brian Erdelyi-- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] var_int ambiguous serialization consequences
I wonder of consequences if var_int is used in its longer than necessary forms (e.g encoding 1 as 0xfd0100 instead of 0x01) This is already of interest if applying size limit to a block, since transaction count is var_int but is not part of the hashed header or the merkle tree. It could also be used to create variants of the same transaction message by altered representation of txIn and txout counts, that would remain valid provided signatures validate with the shortest form, as that is created while re-serializing for signature hashing. An implementation that holds mempool by raw message hashes could be tricked to believe that a modified encoded version of the same transaction is a real double spend. One could also mine a valid block with transactions that have a different hash if regularly parsed and re-serialized. An SPV client could be confused by such a transaction as it was present in the merkle tree proof with a different hash than it gets for the tx with its own serialization or from the raw message. Tamas Blummer Bits of Proof signature.asc Description: Message signed with OpenPGP using GPGMail -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal to address Bitcoin malware
TREZOR does not support BIP70. I think they planned to work on it after multi-sig support, which is now done, so I'm hoping that it's next on their roadmap. The signing features of BIP70 have (fortunately!) been implemented by payment processors quite early, before we really have the client side fully figured out and implemented. Mobile wallets (Android, iOS) do implement it and they are reasonably secure, for desktops we need TREZOR and we need the Bitcoin Authenticator 2-factor wallet to support it. I think they do, but can't remember exactly. Either they do, or it's on their roadmap. On Sun, Feb 1, 2015 at 2:31 PM, Martin Habovštiak martin.habovst...@gmail.com wrote: BIP70 is quite safe agains MitB. If user copies URL belonging to other merchant, he would see the fact after entering it into his wallet application. The only problem is, attacker can buy from the same merchant with user's money. (sending him different URL) This can be mitigated by merchant setting memo to the description of the basket and some user info (e.g. address to which goods are sent). But if whole computer is compromised, you're already screwed. Trezor should help, but I'm not sure if it supports BIP70. 2015-02-01 14:49 GMT+02:00 Brian Erdelyi brian.erde...@gmail.com: In online banking, the banks generate account numbers. An attacker cannot generate their own account number and the likelihood of an attacker having the same account number that I am trying to transfer funds to is low and this is why OCRA is effective with online banking. With Bitcoin, the Bitcoin address is comparable to the recipient’s bank account number. I now see how an an attacker can brute force the bitcoin address with vanitygen. Is there any way to generate an 8 digit number from the bitcoin address that can be used to verify transactions in such a way (possibly with hashing?) that brute forcing a bitcoin address would take longer than a reasonable period of time (say 60 seconds) so a system could time out if a transaction was not completed in that time? I’ve also looked into BIP70 (Payment Protocol) that claims protection against man-in-the-middle/man-in-the-browser (MitB) based attacks. A common way to protect against this is with out-of-band transaction verification ( http://en.wikipedia.org/wiki/Man-in-the-browser#Out-of-band_transaction_verification ). I see how BIP 70 verifies the payment request, however, is there any way to verify that the transaction signed by the wallet matches the request before it is sent to the blockchain (and how can this support out of band verification)? Perhaps this is something that can only be supported when sending money with web based wallets. Brian Erdelyi -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] var_int ambiguous serialization consequences
Hashes are always computed by reserializing data structures, never by hashing wire data directly. This has been the case in every version of the reference client's code that I know of. This even meant that for example a block of 99 bytes with non-shortest length for the transaction count could be over the mazimum block size, but still be valid. As Wladimir says, more recently we switched to just failing to deserialize (by throwing an exception) whenever a non-shortest form is used. On Feb 1, 2015 1:34 AM, Tamas Blummer ta...@bitsofproof.com wrote: I wonder of consequences if var_int is used in its longer than necessary forms (e.g encoding 1 as 0xfd0100 instead of 0x01) This is already of interest if applying size limit to a block, since transaction count is var_int but is not part of the hashed header or the merkle tree. It could also be used to create variants of the same transaction message by altered representation of txIn and txout counts, that would remain valid provided signatures validate with the shortest form, as that is created while re-serializing for signature hashing. An implementation that holds mempool by raw message hashes could be tricked to believe that a modified encoded version of the same transaction is a real double spend. One could also mine a valid block with transactions that have a different hash if regularly parsed and re-serialized. An SPV client could be confused by such a transaction as it was present in the merkle tree proof with a different hash than it gets for the tx with its own serialization or from the raw message. Tamas Blummer Bits of Proof -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal to address Bitcoin malware
This video demonstrates how HSBC uses a security token to verify transactions online. https://www.youtube.com/watch?v=Sh2Iha88agE. Since it's not very widely used outside of Austria and Germany, this may be interesting for some: there is a second factor scheme called cardTAN or chipTAN where authentication codes are generated on a device which is not specifically linked to an accout. When authenticating an online banking transaction the process is as follows: http://i.imgur.com/eWsffsp.jpg 1. Insert bank card into TAN generator 2. Scan flickering code on screen with the device's photodetector 3. Confirm amount to transfer and recipient on the generator 4. Finalize online banking transaction by entering a challenge-response generated by the device https://www.youtube.com/watch?v=5gyBC9irTsMt=22s http://en.wikipedia.org/wiki/Transaction_authentication_number#chipTAN_.2F_cardTAN Original Message *Subject: *[Bitcoin-development] Proposal to address Bitcoin malware *From: *Brian Erdelyi brian.erde...@gmail.com *To: *bitcoin-development@lists.sourceforge.net *Date: *Sat, 31 Jan 2015 18:15:53 -0400 Hello all, The number of incidents involving malware targeting bitcoin users continues to rise. One category of virus I find particularly nasty is when the bitcoin address you are trying to send money to is modified before the transaction is signed and recorded in the block chain. This behaviour allows the malware to evade two-factor authentication by becoming active only when the bitcoin address is entered. This is very similar to how man-in-the-browser malware attack online banking websites. Out of band transaction verification/signing is one method used with online banking to help protect against this. This can be done in a variety of ways with SMS, voice, mobile app or even security tokens. This video demonstrates how HSBC uses a security token to verify transactions online. https://www.youtube.com/watch?v=Sh2Iha88agE. Many Bitcoin wallets and services already use Open Authentication (OATH) based one-time passwords (OTP). Is there any interest (or existing work) in in the Bitcoin community adopting the OATH Challenge-Response Algorithm (OCRA) for verifying transactions? I know there are other forms of malware, however, I want to get thoughts on this approach as it would involve the use of a decimal representation of the bitcoin address (depending on particular application). In the HSBC example (see YouTube video above), this was the last 8 digits of the recipient’s account number. Would it make sense to convert a bitcoin address to decimal and then truncate to 8 digits for this purpose? I understand that truncating the number in some way only increases the likelihood for collisions… however, would this still be practical or could the malware generate a rogue bitcoin address that would produce the same 8 digits of the legitimate bitcoin address? Brian Erdelyi -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Bitcoin Core 0.9.4 not on bitcoin.org?
Why is that? Also, is it correct that there wasn't a release candidate before the release? Sounds dangerous to me. signature.asc Description: This is a digitally signed message part. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Core 0.9.4 not on bitcoin.org?
On Sun, 1 Feb 2015, xor wrote: Why is that? v0.9.4 is not really a release, just a tag in git. It contains merely a workaround for a change in OpenSSL which caused problems - see Gregory Maxwell's post. As the releases are statically built against OpenSSL, it is not necessary to upgrade if you use releases from bitcoin.org. Hence no change on the site. (but it can be used by people building from source, or distributions packages such as the Ubuntu PPA, which unwisely dynamically link OpenSSL) Also, is it correct that there wasn't a release candidate before the release? Sounds dangerous to me. Again, there hasn't been any 0.9.4 release, neither a release candidate or anything else. Testing and such should be focused on the 0.10 release candidates. Wladimir -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Core 0.9.4 not on bitcoin.org?
On Sun, Feb 1, 2015 at 8:08 PM, xor x...@freenetproject.org wrote: Why is that? Because Binaries on Bitcoin.org have always been unaffected by the issue 0.9.4 was released to address. Also, is it correct that there wasn't a release candidate before the release? Sounds dangerous to me. The changes were tried first by many people as part of git master. This was narrow bug fix backport required to prevent the software from no longer working at all for people who compiled it themselves and received software updates for their system. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
