jhansen858 (OP)
|
|
June 17, 2011, 07:29:42 PM |
|
|
Hi forum: 1DDpiEt36VTJsiJunyBc3XtG6CcSAnsQ4p
|
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
bbit
Legendary
Offline
Activity: 1330
Merit: 1000
Bitcoin
|
|
June 17, 2011, 09:29:12 PM |
|
At some point people are going to have to trust someone to help protect stuff - might be worth checking this out ... http://www.bitprotection.info at least you can get coverage against your wallet if anything happens... just a thought...
|
|
|
|
DukeOfEarl
Newbie
Offline
Activity: 28
Merit: 0
|
|
June 17, 2011, 09:52:51 PM |
|
Just wait until the first buffer overflow exploit in the client. Then things will really get interesting.
|
|
|
|
|
bitlotto
|
|
June 17, 2011, 10:00:31 PM |
|
Just wait until the first buffer overflow exploit in the client. Then things will really get interesting.
Interested. Explain.
|
*Next Draw Feb 1* BitLotto: monthly raffle (0.25 BTC per ticket) Completely transparent and impossible to manipulate who wins. TOR TOR2WEB Donations to: 1JQdiQsjhV2uJ4Y8HFtdqteJsZhv835a8J are appreciated.
|
|
|
enmaku
|
|
June 17, 2011, 10:03:49 PM |
|
Just wait until the first buffer overflow exploit in the client. Then things will really get interesting.
Interested. Explain. By giving an application carefully malformed input which is larger than the field it was expecting you can sometimes cause your malformed input to overwrite part of the copy of the application that is sitting in active memory, effectively rewriting some of its code to your own ends. This means that one could, for example, rewrite the code that sends BTC substituting whatever variable holds the recipient's address with a static wallet address, so it would look like you sent person A coins but actually sent them to attacker B. Buffer overflows are very scary, but they're also pretty hard to pull off in a meaningful way. I don't expect to see many such exploits in the wild any time soon.
|
|
|
|
bitlotto
|
|
June 17, 2011, 10:11:10 PM |
|
Just wait until the first buffer overflow exploit in the client. Then things will really get interesting.
Interested. Explain. By giving an application carefully malformed input which is larger than the field it was expecting you can sometimes cause your malformed input to overwrite part of the copy of the application that is sitting in active memory, effectively rewriting some of its code to your own ends. This means that one could, for example, rewrite the code that sends BTC substituting whatever variable holds the recipient's address with a static wallet address, so it would look like you sent person A coins but actually sent them to attacker B. Buffer overflows are very scary, but they're also pretty hard to pull off in a meaningful way. I don't expect to see many such exploits in the wild any time soon. Ok, but for most users the only place that would occur would be the address input or amount right? (I know just a tiny bit about buffer overflows) The address would have to be pretty malformed to work right? I guess if you're opening bitcoin with a script it would be easier...
|
*Next Draw Feb 1* BitLotto: monthly raffle (0.25 BTC per ticket) Completely transparent and impossible to manipulate who wins. TOR TOR2WEB Donations to: 1JQdiQsjhV2uJ4Y8HFtdqteJsZhv835a8J are appreciated.
|
|
|
passerby
Member
Offline
Activity: 112
Merit: 10
|
|
June 17, 2011, 11:52:33 PM |
|
I think the utility of wallet encryption in absence of a smartcard is very limited, if at all exists.
|
|
|
|
enmaku
|
|
June 18, 2011, 01:07:45 AM |
|
Just wait until the first buffer overflow exploit in the client. Then things will really get interesting.
Interested. Explain. By giving an application carefully malformed input which is larger than the field it was expecting you can sometimes cause your malformed input to overwrite part of the copy of the application that is sitting in active memory, effectively rewriting some of its code to your own ends. This means that one could, for example, rewrite the code that sends BTC substituting whatever variable holds the recipient's address with a static wallet address, so it would look like you sent person A coins but actually sent them to attacker B. Buffer overflows are very scary, but they're also pretty hard to pull off in a meaningful way. I don't expect to see many such exploits in the wild any time soon. Ok, but for most users the only place that would occur would be the address input or amount right? (I know just a tiny bit about buffer overflows) The address would have to be pretty malformed to work right? I guess if you're opening bitcoin with a script it would be easier... I think that's the idea, scripts like this one are popping up more and more often. People like the ease of use that a one-click payment option offers, but it can also lead to deliberate attacks on the client itself. It would also be possible for programs on the same local machine to attempt to overflow the bitcoin client through input methods not normally used by humans (like RPC) or even just directly manipulate its memory space.
|
|
|
|
Martin P. Hellwig
Newbie
Offline
Activity: 33
Merit: 0
|
|
June 18, 2011, 02:05:40 AM |
|
I think the utility of wallet encryption in absence of a smartcard is very limited, if at all exists.
As the wallet is only needed when sending an transaction it is perfectly alright to encrypt it and prompt the user for a password to when needed.
|
|
|
|
joan
Jr. Member
Offline
Activity: 56
Merit: 1
|
|
June 18, 2011, 09:49:42 AM |
|
Ok, but for most users the only place that would occur would be the address input or amount right? (I know just a tiny bit about buffer overflows) The address would have to be pretty malformed to work right? I guess if you're opening bitcoin with a script it would be easier...
Another input is the data sent from node to node. A malicious node could craft a transaction that the victim node will process to check for validity. The vulnerability could be in the transaction processing routine.
|
|
|
|
mp420
|
|
June 18, 2011, 12:28:02 PM |
|
Sorry for the thread hijack, but I did not want to make a new one just to outline my scheme for storing bitcoins securely.
How to make a secure savings wallet - a paranoid approach
1) Create a fresh, minimal install of Linux of the flavour of your choice. Preferably not on your primary computer. A "live" OS could suffice, too. 2) Install GnuPG and Bitcoin. 3) Start Bitcoin and let it download the blockchain. Create as many empty accounts as you need. 4) Take the computer offline. 5) Create a new GPG identity and a keypair. No need to use a passphrase for the private key. 6) Back up the wallet and encrypt it with the public key. 7) Transfer the encrypted wallet out of the system (on a USB memory, a CD or some other approach) and store it in several places both online and offline. Do the same to the list of accounts. 8) Write out, or type out on a mechanical typewriter, print out on a line printer or in some other analog or near-analog way transfer the private key out of the system and store it EXTREMELY securely. Preferably in two places, with a cover letter that explains what the key is good for and how to use it. 9) Shut down and erase the temporary Linux system. If paranoid, physically destroy the disk. 10) Transfer the funds to the account(s) and wait for the transaction(s) to get confirmed. 11) Enjoy the illusion of safety and start worrying over the VALUE of your savings.
Any thoughts?
|
|
|
|
Jaagu
Member
Offline
Activity: 62
Merit: 10
|
|
June 19, 2011, 02:04:17 AM |
|
Sorry for the thread hijack, but I did not want to make a new one just to outline my scheme for storing bitcoins securely. How to make a secure savings wallet - a paranoid approach1) Create a fresh, minimal install of Linux of the flavour of your choice. Preferably not on your primary computer. A "live" OS could suffice, too. 2) Install GnuPG and Bitcoin. 3) Start Bitcoin and let it download the blockchain. Create as many empty accounts as you need. 4) Take the computer offline. 5) Create a new GPG identity and a keypair. No need to use a passphrase for the private key. 6) Back up the wallet and encrypt it with the public key. 7) Transfer the encrypted wallet out of the system (on a USB memory, a CD or some other approach) and store it in several places both online and offline. Do the same to the list of accounts. Write out, or type out on a mechanical typewriter, print out on a line printer or in some other analog or near-analog way transfer the private key out of the system and store it EXTREMELY securely. Preferably in two places, with a cover letter that explains what the key is good for and how to use it. 9) Shut down and erase the temporary Linux system. If paranoid, physically destroy the disk. 10) Transfer the funds to the account(s) and wait for the transaction(s) to get confirmed. 11) Enjoy the illusion of safety and start worrying over the VALUE of your savings. Any thoughts? I've always been curious about what happens when you are going to use your precious wallet again. You have to download the entire blockchain -- it might take an hour or two -- during this time your wallet is exposed to all kind external threats, isn't it? Sure, you could speed up the process by downloading most of the chain (e. g. from http://sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain/ and using rescan switch, but it does not eliminate threats. Besides, you might need to revive your wallet after soooo many years and by this time there are absolutely new clients with no place for 'wallet.dat' (there might be new built-in encryption etc.). What will you do then?
|
|
|
|
Garrett Burgwardt
|
|
June 19, 2011, 02:42:25 AM |
|
Just wait until the first buffer overflow exploit in the client. Then things will really get interesting.
IIRC, there already was one, where someone generated a crazy amount of coins for themselves. There was a panicked update spree and the 'good' blockchain overtook the bad one once everyone had updated.
|
|
|
|
foo
|
|
June 19, 2011, 06:35:53 AM |
|
Just wait until the first buffer overflow exploit in the client. Then things will really get interesting.
IIRC, there already was one, where someone generated a crazy amount of coins for themselves. There was a panicked update spree and the 'good' blockchain overtook the bad one once everyone had updated. Not a buffer overflow. https://en.bitcoin.it/wiki/Incidents#Value_overflow
|
I know this because Tyler knows this.
|
|
|
|