Wallet Manager

[david4dev]

Wallet Manager is my little project to create a simple GUI for the common tasks of backing up, restoring and encrypting wallets.

The GUI isn't that great at the moment (just a set of buttons) but its simple and it works:

https://i.imgur.com/t5nH4.png

You can download it here or grab the bzr branch

Code:

bzr branch lp:walletmanager

.

Feedback, bug reports, suggestions etc are all welcome

[compro01]

is it just me or does a big "shred wallet" button look like a loaded shotgun pointed downwards?

[mouse]

Your button says 'import' but the text says 'replaces your current wallet with a differnt one'. That doesnt sould like import to me, that sounds like closeing my current wallet and opening a new one. Or does it delete the current one? I would have though it would add in the keys (or however bitcoin works) - kinda like a merge.

Also how does a normal import differ form a decrypting import? Is the the import methaphore being used consistently?

This app *may* need a little work :-)

good luck!

[Rogue Star]

how do you ensure that shred in fact overwrites the physical bytes where the wallet is stored? seems like that would be a problem anywhere that hard drive access is abstracted (any modern file system/OS), especially in the case of solid state drives.

[david4dev]

Your button says 'import' but the text says 'replaces your current wallet with a differnt one'. That doesnt sould like import to me, that sounds like closeing my current wallet and opening a new one. Or does it delete the current one? I would have though it would add in the keys (or however bitcoin works) - kinda like a merge.

Also how does a normal import differ form a decrypting import? Is the the import methaphore being used consistently?

Import just copies the selected wallet stored somewhere else of the disk to ~/.bitcoin/wallet.dat, overwriting ~/.bitcoin/wallet.dat in the process. So this does delete the current one. It doesn't do a merge. Maybe import/export is a bit confusing and I should use a backup/restore metaphor instead.

Decrypt and import is the same as normal import but first it decrypts the file (which needs to have been encrypted using Wallet Manager), prompting the user for the passcode.

Maybe 'Create Backup', 'Create Encrypted Backup', 'Restore Backup' and 'Restore Encrypted Backup' would be more self explanatory.

This app *may* need a little work :-)

It *does* need a little work. Currently its just at the proof of concept stage.

[david4dev]

how do you ensure that shred in fact overwrites the physical bytes where the wallet is stored? seems like that would be a problem anywhere that hard drive access is abstracted (any modern file system/OS), especially in the case of solid state drives.

Put simply, I don't. This is a problem with shredding algorithms in general. All of the limitations of shred(1) are inherent here as well.

However, it is more secure than a normal delete (which itself is more secure than the default delete function of most file managers which send the file to a rubbish bin) and it should stop most simple undelete programs (It won't stop high grade forensic programs).

The only way to be totally secure is to shred the whole file system! 

[XIU]

What would be a cool feature is the ability to create a ramdisk, decrypt the wallet.dat to there, and then use the -datadir option to use the ramdisk or something. This way the decrypted version is never stored on your hdd and would make it alot harder to recover it

[david4dev]

What would be a cool feature is the ability to create a ramdisk, decrypt the wallet.dat to there, and then use the -datadir option to use the ramdisk or something. This way the decrypted version is never stored on your hdd and would make it alot harder to recover it

That's an interesting idea that I may look at in the future. There are some big difficulties in implementing this though - for example, you generally need to be root to create a ramdisk. Although, I could possibly use fuse to do this.

[Rogue Star]

how do you ensure that shred in fact overwrites the physical bytes where the wallet is stored? seems like that would be a problem anywhere that hard drive access is abstracted (any modern file system/OS), especially in the case of solid state drives.

Put simply, I don't. This is a problem with shredding algorithms in general. All of the limitations of shred(1) are inherent here as well.

However, it is more secure than a normal delete (which itself is more secure than the default delete function of most file managers which send the file to a rubbish bin) and it should stop most simple undelete programs (It won't stop high grade forensic programs).

The only way to be totally secure is to shred the whole file system! 

cool, that's what I expected. I mostly wanted to know that you had considered the possibility and don't want people to have a false sense of security when using the shred feature. maybe you can make that clear somehow without being obtrusive.

[david4dev]

Changes to file formats

I've worked on this project for a couple of days now and I now have a clearer picture of where this project is heading and what problems there are currently.  I have concluded that changing the file formats and the file extensions will help with this. For this reason, if you are using any of the current versions, ensure you keep an unencrypted backup (or a backup encrypted using a different program) because the change will break compatibility with the old encrypted files.

Problem 1 - file recognition
Using set file extensions will help both this application and users recognise which files are wallet backups and which files are encrypted wallet backups. Therefore, when I make the change, I will enforce file extensions when saving.

Problem 2 - verifying decryption
Currently, if a user decrypts a wallet but gets the passcode wrong, the application will spit out a garbled file that is no use to anyone. It is currently unable to check if the decryption was successful. To enable this, I will change the file format of encrypted wallets to include the sha256 digest of the original file which will give an easy way to verify the decryption. A side effect of this is breaking compatibility with the current encrypted format.

The file extensions
I will use the following file extensions:

• Unencrypted backups: .bw - bitcoin wallet
• Encrypted backups: .ebw - encrypted bitcoin wallet

As always, feedback is welcome  .

[done]

Best of luck with the development. The community is looking for multiple options in all areas.

[david4dev]

Version 1.0.0 is out

This brings in the new file format and breaks compatibility with previous versions.

I made a video showing some typical use of the application.

[david4dev]

.deb package and PPA available

Installation should now be a lot easier. You can install Wallet Manager from:

• The PPA: ppa:david4dev/walletmanager (for Ubuntu and derivatives)
• .deb files on the downloads page (for Debian and derivatives)

[done]

Demo looks real nice. Great job.