Bitcoin Forum
December 14, 2024, 04:58:25 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: [SUGGESTION] New wallet.dat format  (Read 1986 times)
rme (OP)
Hero Member
*****
Offline Offline

Activity: 756
Merit: 504



View Profile
July 05, 2013, 12:15:35 PM
 #1

Suggestion to Bitcoin-QT client


New wallet.dat format, featuring:

  • Default wallet.dat file size is now 21MB
Stealing bitcoins via Java Applets is common, uploading a 80KB file is fast and easy, uploading a 21MByte with a 1Mbit upload connection means 210 seconds (3 minutes and a half), if you execute a Java Applet you maybe close it before it has uploaded your wallet.dat to the remote server.

Also, this size allows to store all the addresses that you want without revealling how many you have just by looking at the size of the .dat file. (All wallets start with a 21MByte file.)

  • Better encryption
With actual encryption anyone can take a look into an encrypted .dat file and he knows that is a Bitcoin wallet file because of the unencrypted strings ("pool", "minversion", "ckey"...).

With this new format if you rename your encrypted wallet.dat file no one will know that is a Bitcoin wallet file.
Also adding some extra rounds to the encryption so making bruteforcing impossible.

For example if actual encryption on a average PC takes 0.001 seconds we can do 250 rounds so that takes 0.25 seconds (small time) but to a cracker it takes 250 times longer to bruteforce.
jackjack
Legendary
*
Offline Offline

Activity: 1176
Merit: 1280


May Bitcoin be touched by his Noodly Appendage


View Profile
July 05, 2013, 12:40:45 PM
 #2

Drawbacks:

  • Default wallet.dat file size is now 21MB
Unnecessary. People with poor connections wouldn't be able to put a backup on internet (mail/dropbox/etc) or uploading it to blockchain.info.
Why not 21GB?

  • Better encryption
Impossible to look for your wallet on your harddrive if you/windows deleted it... There are regularly such cases in the tech forum.
Why does it even matter that people see it's a wallet? That's the point of the passphrase to take care of that.

Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2
Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
rme (OP)
Hero Member
*****
Offline Offline

Activity: 756
Merit: 504



View Profile
July 05, 2013, 12:42:41 PM
 #3

Drawbacks:

  • Default wallet.dat file size is now 21MB
Unnecessary. People with poor connections wouldn't be able to put a backup on internet (mail/dropbox/etc).
Why not 21GB?
Please tell me a example of poor connection.

  • Better encryption
Impossible to look for your wallet on your harddrive if you/windows deleted it... There are regularly such cases.
Why does it even matter that people see it's a wallet? That's the point of the passphrase to take care of that.
In the future maybe if your computer has a wallet.dat backup you are forced to tell the password.

Answered
Rannasha
Hero Member
*****
Offline Offline

Activity: 728
Merit: 500


View Profile
July 05, 2013, 01:41:05 PM
 #4

Padding the wallet-file to become 21 MB (or larger) is mostly useless.

If the wallet is unencrypted (which is the target demographic for wallet-stealing trojans), then a trojan or malicious java applet can simply open the file, locate the relevant segments of data (since the structure of the wallet will be public knowledge as Bitcoin is opensource) and only transmit those. The attacker can then construct a new, padded wallet file at his leisure using the stolen data and afterwards access the funds.
Mahn
Full Member
***
Offline Offline

Activity: 140
Merit: 100


View Profile
July 05, 2013, 02:09:09 PM
 #5

Padding the wallet-file to become 21 MB (or larger) is mostly useless.

If the wallet is unencrypted (which is the target demographic for wallet-stealing trojans), then a trojan or malicious java applet can simply open the file, locate the relevant segments of data (since the structure of the wallet will be public knowledge as Bitcoin is opensource) and only transmit those. The attacker can then construct a new, padded wallet file at his leisure using the stolen data and afterwards access the funds.

I was about to post this. Unless you change the way private keys are generated and work, which would 1) invalidate existing private keys, and 2) make brain wallets, online generators and paper wallet generators useless, there's not much one can do to increase the file size short of padding it which wouldn't really protect it from an attacker.

rme (OP)
Hero Member
*****
Offline Offline

Activity: 756
Merit: 504



View Profile
July 05, 2013, 03:57:22 PM
 #6

Padding the wallet-file to become 21 MB (or larger) is mostly useless.

If the wallet is unencrypted (which is the target demographic for wallet-stealing trojans), then a trojan or malicious java applet can simply open the file, locate the relevant segments of data (since the structure of the wallet will be public knowledge as Bitcoin is opensource) and only transmit those. The attacker can then construct a new, padded wallet file at his leisure using the stolen data and afterwards access the funds.

I was about to post this. Unless you change the way private keys are generated and work, which would 1) invalidate existing private keys, and 2) make brain wallets, online generators and paper wallet generators useless, there's not much one can do to increase the file size short of padding it which wouldn't really protect it from an attacker.

Nope, the "unencrypted default wallet" can be simply a wallet encrypted with the password "bitcoin".

I mean, the java applet cannot open and locate the relevant segments of data without decrypting.
So the Bitcoin-QT client by default encrypts wallet with "bitcoin" but to the user is unencrypted.

If you dont setup a password the wallet is still encrypted (by a know password "bitcoin") so the client dont prompt for a password.
Rannasha
Hero Member
*****
Offline Offline

Activity: 728
Merit: 500


View Profile
July 05, 2013, 04:34:46 PM
 #7

Padding the wallet-file to become 21 MB (or larger) is mostly useless.

If the wallet is unencrypted (which is the target demographic for wallet-stealing trojans), then a trojan or malicious java applet can simply open the file, locate the relevant segments of data (since the structure of the wallet will be public knowledge as Bitcoin is opensource) and only transmit those. The attacker can then construct a new, padded wallet file at his leisure using the stolen data and afterwards access the funds.

I was about to post this. Unless you change the way private keys are generated and work, which would 1) invalidate existing private keys, and 2) make brain wallets, online generators and paper wallet generators useless, there's not much one can do to increase the file size short of padding it which wouldn't really protect it from an attacker.

Nope, the "unencrypted default wallet" can be simply a wallet encrypted with the password "bitcoin".

I mean, the java applet cannot open and locate the relevant segments of data without decrypting.
So the Bitcoin-QT client by default encrypts wallet with "bitcoin" but to the user is unencrypted.

If you dont setup a password the wallet is still encrypted (by a know password "bitcoin") so the client dont prompt for a password.

1 day after such a change goes live, malware writers will have included a function to decrypt using the default password and then try to read it. If someone isn't encrypting his wallet today, he won't bother changing the default encryption password.

The only real way around this issue is to prompt users to provide an encryption password whenever Bitcoin-qt is launched with an unencrypted wallet.dat. Basically force users to use encryption. But if that's desirable is debatable.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!