Wallet encryption

[jhansen858]

http://it.slashdot.org/story/11/06/17/141228/Trojan-Goes-After-Bitcoins

This is really bad.

[1714952438]

1714952438

[1714952438]

1714952438

[1714952438]

1714952438

[1714952438]

1714952438

[1714952438]

1714952438

[1714952438]

1714952438

[stevang]

Its time to focus on protection of the user wallets now!
I thought bitcoin is about encryption!? So how hard can it be to offer an encryption for the running client and for the client files?
I would love to be able to add a second level of verification with my yubikey also (optional).

The more ppl loose their wallets to hackers and trojans the less people will stick with the bitcoin currency.
Are there not enough topics in the press yet to do something about it?
 

[bbit]

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]

Just wait until the first buffer overflow exploit in the client.  Then things will really get interesting.

[enmaku]

https://github.com/bitcoin/bitcoin/pull/232

Already in the works.

Please google / search forums before posting yet another "OMGZ WE R INSECURR!!1" thread.

[bitlotto]

Just wait until the first buffer overflow exploit in the client.  Then things will really get interesting.

Interested. Explain.

[enmaku]

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]

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

[passerby]

I think the utility of wallet encryption in absence of a smartcard is very limited, if at all exists.

[enmaku]

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]

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]

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]

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]

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

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]

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