Encrypt wallet #3

issue gavinandresen openend this issue on December 19, 2010
  1. gavinandresen commented at 4:24 pm on December 19, 2010: contributor
    Often requested feature: encrypt private keys in the wallet.dat file, so a password is required for a send transaction.
  2. fabianhjr commented at 11:08 pm on January 13, 2011: none
    I think we can be creative about the way to input the password. IMHO it should be similar to the Android. It is really awesome and forces you into thinking about something more abstract. :)
  3. dooglus commented at 0:48 am on January 25, 2011: contributor
    How does Android do it? Got a reference?
  4. gavinandresen commented at 7:48 pm on January 30, 2011: contributor
    I jotted down some thoughts here: https://gist.github.com/803170
  5. RytisLT commented at 7:56 am on February 11, 2011: none
    I think this is a key feature. Manually backing up and securing your wallet really sucks, I think this keeps a lot of users from using BitCoin. Also there should be possible to specify wallet location. This way I would keep my wallet in my dropbox and therefore would take care of backing up.
  6. jeffWelling commented at 5:22 am on February 14, 2011: none

    The Andriod way of inputting your passcode (assuming you mean what you think I mean) is kind of a ‘connect the dot’ system, where you slide your finger from the first digit directly to the second. This has the implication of actually being less secure than using the traditional tap per digit system, because it limits the number of neighboring digits to 8 as opposed to the full 10. With the andriod way, if the first digit for your password is 5, then your possible choices for a second digit are 1,2,3, 4 and 6, and 7,8,9. However, consider what happens when your starting digit is 1, your next available digits become 2, 4 and 5. With the traditional method, no matter what key you start on, you may choose any other 0-9 number. I do applaud the creativity and innovation, but I think the security implications need to be pointed out.

    I would like if my wallet was encrypted taking advantage of my already existing GnuPG key. :)

  7. ghost commented at 8:56 am on February 24, 2011: none

    Suppose we encrypt keys with the public key of a separate private key. That private key is encrypted with a symmetric algorithm, whose key is derived from the passphrase. I believe this is how GnuPG works. When we store this encrypted key in the wallet, we also store a reference to the associated private key. (Or, perhaps have it elsewhere on the file system… usb drive? smart card? keyring?) With this functionality, we could prompt the user for a password once and decrypt multiple keys. It also means that a wallet could be separated into virtual partitions with different encryption keys. I think it would allow a smooth transition, but would it be backwards compatible?[1]

    Here’s the way I imagine interacting with this. I would keep a small amount of bitcoin in the clear. This allows me to easily spend the small amount while assuring I won’t lose much if my device is compromised (good for mobile devices). I can easily encrypt/decrypt keys by entering a target amount to “transfer”. The actual amount is determined by picking keys with transactions (outputs?) summing to approximately the target. In order to spend more than is in the clear, I must enter one (or more) passphrases, but the rest is automated.

    [1]Can the structure of the wallet be modified for encrypted keys and a reference to the encrypting private key without causing a breaking change?

  8. jhyslop commented at 8:16 am on March 6, 2011: none

    Fnordsoft, I hope the GPG mechanism is simpler - the pass phrase is hashed into a symmetric key, and that key is used to encrypt the sensitive data in the wallet. Much simpler, and you don’t have to worry about storing a private key anywhere. The user enters the pass phrase, and the program checks it by encrypting something with the public key, then decrypting it with the private key, and ensuring that the resulting ‘something’ matches the original ‘something’.

    As for the input, keep it simple: there’s nothing wrong with the plain ol’ keyboard. The Android style may work well on a mobile device, but would be a royal pain in the *** anywhere else.

  9. jeffWelling commented at 8:40 am on March 6, 2011: none

    jhyslop, but many of us already use GnuPG with public key cryptography, so we’re already storing private keys which we use for other purposes. Adding one more key is trivial.

    I see no reason why both symmetric and public key cryptography couldn’t be available as an option. Aside from the obvious “who will program it” part.

  10. jhyslop commented at 4:27 pm on March 6, 2011: none
    OK, I see what you’re getting at, Jeff. Yeah, that could be an option. The default, I think, should be to use the hashed pass phrase as a symmetric key, with an option to allow advanced users to provide a public key.
  11. jhyslop commented at 4:55 pm on March 6, 2011: none
    By the way, just to clarify - when I said “the default should be to use the hashed pass phrase as a symmetric key” (HPPASK) I wasn’t necessarily pushing HPPASK as The Solution. To generalize my statement, what I meant was “the default should be some password mechanism that keeps the wallet self-contained, and by the way the HPPASK seems to me a simple solution that meets the needs.”
  12. genjix commented at 3:56 am on March 9, 2011: none
    Couldn’t find how to assign myself tickets, but I’m working on this. So give me a couple of weeks (focus on other issues) if possible ;) (don’t like duplicating work). BTW I’m using a symmetric key (AES now, but easy to switch to blowfish .etc) with the passphrase hashed with RSA using OpenSSL. If you’re interested then run ‘man evp_sealinit’ or man evp_openinit.
  13. thiloplanz commented at 7:48 am on March 24, 2011: none
    An alternative (or stop-gap measure) to encrypting the wallet could be to allow the user to specify where the file should be. This way, he can place it on an encrypted volume (that he may already have for other important documents).
  14. borneq commented at 6:37 pm on April 28, 2011: none
    My proposal: wallet.dat zipped and encrypted. How effective is break password by brute force? One step can require verify all file?
  15. benlake commented at 5:40 am on May 3, 2011: none

    First time user experience. I am a developer, but would like to shed light on what I encountered when discovering the world of Bit Coins.

    After reading a taste of what BCs were I download the client (developer side) and fired it up (OSX). I was met with a string of characters not too frightening for a developer and especially not when expecting crazy encryption fun times to be going on. However, I didn’t quite know what I was looking at or what it meant to me. I stumbled onto Bit Faucet and it introduced the notion that these characters were an address used to receive BC. So I learned something. At some point I clicked “New…” and my string of characters changed; this befuddled me a bit. Some more reading calmed me as it was “good practice” to generate these new addresses and use them liberally.

    As I continued to learn about what I had gotten myself into it came to light that the client I had downloaded was the key to whatever BTC I began to acquire. So as a developer, my first questions were, “where is the secret key?”, “how do I protect it?”, and “how do I move it and still use this client?”. All of these questions are being touched on in IRC and in this thread. So I’m glad to see the discussion is taking place. However, I have yet to see reasonable discourse that talks about what sort of experience our target end-user should see. When starting a conversion in IRC #bitcoin-dev about the above questions I quickly received answers such as: “just backup your wallet.dat file”, “use truecrypt”, “use gpg”, “use a USB stick or dropbox”, et cetera. My response is… DUH! The point of the discourse was not to get an answer I am perfectly capable of doing as a developer. It was to discuss how to make Bit Coins and the associated software accessible to our girlfriends, mothers, and fathers. So, with all of that context, and as a development brother looking at my experience as a first time user (while it is still fresh, I discovered BC two days ago and now have 40BTC, yay), I’d like to suggest the following:

    • Do NOT generate the secret magic sauce upon the client first loading, instead, provide an introduction screen that says, “Hey, welcome to the world of Bit Coins! Let’s walk through a few concepts before you get started”. Introduce the high-level concepts of: 1) you will be creating a wallet, 2) you generate “addresses” which others use to send you Bit Coins 3) your wallet is the key to accessing your Bit Coins, if you create another wallet on a different device, you will have two different “accounts” (like at a different bank)
    • Prompt the user to create a wallet, have the default directory available, but at least introduce them to where this super sensitive information is. Then show a generating magic sauce message with a repeated explanation that THIS IS IMPORTANT
    • I personally suggest integrating TrueCrypt as a sub-system of the BC client. Use a true crypt volumes to store either just the sensitive files or everything (good when using a portable USB key). Prompt the user to enter a passphrase so the true crypt volume can be created and used. People are used to passwords, opening the BC client and being prompted for a password by default won’t alarm anyone.
    • True Crypt has done work to be used on portable devices. I recommend Bit Coin do the same and be completely runnable via a USB stick.
    • Provide a GUI level option to “backup your wallet” (ie. make a copy of the true crypt volume somewhere else). It would also be handy to be able to name your wallets and prominently display it in the client. When backing up the name would default to “Wallet Backup 2011-02-16” and the wallet would be marked as a backup. If a client opens a backup wallet, a warning could be issued stating as much and asking if this should now be considered a primary wallet (in the event of a restore)

    My suggestions focus on education and features crucial to the adoption of Bit Coins, in my opinion. I cannot feel good about telling a non-techy about Bit Coins without these features. I want to be able to tell my girlfriend and her be able to make sense of the experience on her own. Thanks for all of the hard work thus far and I’m really enjoying my foray into the Bit Coins community.

    Cheers,

  16. borneq commented at 7:57 am on May 3, 2011: none
    If TryCrypt give anything? It joins file as disk. This disk is readable to other programs (trojans), only advantage TryCrypt is defense against read wallet.dat when someone steals computer.
  17. benlake commented at 1:58 pm on May 3, 2011: none

    As far as I see, this discussion was not about malicious software on the device in which the wallet.dat file was being stored. Trojans could be a problem now, and you are correct, they could be a problem when using True Crypt. To clarify, the goal of using True Crypt is as you said, to protect against theft when one no longer has access to their device OR when the bit coin client is not running (in this case, trojans mean nothing).

    Not to derail the conversation onto malware, but I see no reason to have the wallet.dat file (or other sensitive files) open when not needed. I cannot speak to the internals of how the wallet.dat file is used, but I would summise there could be a way of “locking” or un-mounting the True Crypt disk when the client is not using it and prompting when necessary. That could get annoying, but more discussion on real-time protections should be in another thread. As I see it, this discussion concerns some level of inherent encryption built into the client. To be fair, my mentions of “backups” should be in another thread as well, but the topics tend to be mentioned together.

    Thank you for the opportunity to clarify.

  18. TheBlueMatt referenced this in commit 2747af05a9 on May 24, 2011
  19. alexgenaud commented at 1:13 am on May 27, 2011: none

    Encrypted or not, I strongly advocate a plaintext wallet. Encryption DOES NOT help backup the wallet. It does mean (to a minor extent) that you don’t need to be quite as careful with where you backup, but you should ALWAYS backup.

    As it is, I’ve got multiple copies of three wallet files on the same media because I am too scared to delete some of them, despite the fact that the addresses are redundant. I can not ‘diff’ the files, so my backup solution is just copy copy copy. If I ever need to recover, I’ll probably have to load a hundred versions of all my wallets looking for loose change. If the wallet were plain text, I’d keep ONLY the key pairs I need and never duplicate them (on the same media).

    For similar reasons I disagree with the keypool=100 hack because it presents a false sense of security. Eventually (after the 100th key pair) a restoration from backup will blow away real money.

    And yes, you can have plain text and encryption as a radix64 key block.

  20. wherget commented at 5:21 pm on June 17, 2011: none
    I’d love to see a scheme like in SSH, where the private keys can be encrypted, and a password is then required for using them. Make it optional for all I care, but personally if someone should be able to obtain my wallet.dat it should be useless to them without an extensive amount of work (say brute-forcing my password). Keep private keys encrypted on disk, decrypt for usage (where usage is “signing an outgoing transaction”), and wipe the memory area after use. To be a bit more technical; HPPASK is pretty much the scheme of choice, with a resource-intensive hash like PBKDF2 with lots of rounds… +1
  21. gavinandresen commented at 4:25 pm on August 9, 2011: contributor
    Encrypting private keys pulled. Closing this request.
  22. gavinandresen closed this on Aug 9, 2011
  23. khalahan referenced this in commit 85a7f5e06d on Jun 4, 2012
  24. luke-jr referenced this in commit aa93b8ea71 on Jul 24, 2012
  25. sipa referenced this in commit bbc0684cbb on Jun 2, 2013
  26. namecoin-qt referenced this in commit cc77584df7 on Jun 13, 2013
  27. mhirki referenced this in commit 7e98db4de9 on Aug 9, 2013
  28. nelisky referenced this in commit f672348440 on Mar 20, 2014
  29. rebroad referenced this in commit 0779d048f1 on Jun 22, 2014
  30. rebroad referenced this in commit 9a2e5dee9f on Jun 22, 2014
  31. kac- referenced this in commit 35f0a4e2e9 on Oct 8, 2014
  32. jtimon referenced this in commit cbefc787e5 on May 13, 2015
  33. ptschip referenced this in commit 33342ccc25 on Jan 16, 2016
  34. destenson referenced this in commit 25af8c9260 on Jun 26, 2016
  35. MarcoFalke referenced this in commit 2ca7faab42 on Sep 30, 2016
  36. sipa referenced this in commit 9346f84299 on Nov 17, 2016
  37. practicalswift referenced this in commit 9c184a7b41 on Feb 28, 2017
  38. deadalnix referenced this in commit c9e06dca40 on Mar 3, 2017
  39. sanch0panza referenced this in commit 7a0bb44c93 on May 5, 2017
  40. nomnombtc referenced this in commit 52b4b4fdc9 on May 14, 2017
  41. AkioNak referenced this in commit a3bbec3aa7 on Jul 24, 2017
  42. MarcoFalke referenced this in commit 18394e0ca5 on Sep 29, 2017
  43. MarcoFalke referenced this in commit 16a1f7f6e9 on Sep 29, 2017
  44. MarcoFalke referenced this in commit 619bb05037 on Sep 29, 2017
  45. laanwj referenced this in commit 16fff80257 on Nov 30, 2017
  46. MarcoFalke referenced this in commit 351fadd68a on Dec 19, 2017
  47. MarcoFalke referenced this in commit 88411e98e5 on Dec 19, 2017
  48. classesjack referenced this in commit 73520f45f8 on Jan 2, 2018
  49. nining referenced this in commit 5dc5f5d2e3 on Jan 3, 2018
  50. nining referenced this in commit c029f8ca4c on Jan 3, 2018
  51. hkjn referenced this in commit 3aab98f8dc on Jan 13, 2018
  52. hkjn referenced this in commit 7e80175d2b on Feb 23, 2018
  53. HashUnlimited referenced this in commit b84bc05530 on Mar 12, 2018
  54. HashUnlimited referenced this in commit 5467d4bb7e on Mar 14, 2018
  55. dagurval referenced this in commit fa86efa95b on Mar 28, 2018
  56. dagurval referenced this in commit 6331a251a4 on Mar 28, 2018
  57. sanch0panza referenced this in commit 9f77923b2b on May 17, 2018
  58. NickyYangYang commented at 9:59 am on July 16, 2018: none
    When unlock wallet , the decrypted mater key is stored in memory. Why use the mater key to encrypt private key ? Why not use the key derived based passphrase. Why the decrypted mater key is stored in memory, why not decrypted privated key?
  59. MarcoFalke referenced this in commit 4d550ffab6 on Jul 30, 2018
  60. Empact referenced this in commit 7cb8d6d9fd on Aug 1, 2018
  61. hashtobewild referenced this in commit 526b02a467 on Aug 26, 2018
  62. dooglus referenced this in commit d309f8089f on Oct 19, 2018
  63. cryptapus referenced this in commit 710058ce12 on Jan 4, 2019
  64. MarcoFalke referenced this in commit 6899ef3f0e on Jun 11, 2019
  65. MarcoFalke referenced this in commit 98958c81f5 on Jun 17, 2019
  66. MarcoFalke referenced this in commit 4aaeb04497 on Oct 22, 2019
  67. laanwj referenced this in commit 89e93135ae on Nov 10, 2019
  68. MarcoFalke referenced this in commit cf43f3f0a8 on Dec 5, 2019
  69. MarcoFalke referenced this in commit bb03765e2d on Dec 8, 2019
  70. fanquake referenced this in commit c8e65ade09 on Dec 9, 2019
  71. Warchant referenced this in commit 7958da26e8 on Dec 31, 2019
  72. velesnetwork referenced this in commit 32d06f3e2a on Jan 12, 2020
  73. velesnetwork referenced this in commit cd8ced0d6f on Jan 12, 2020
  74. Bushstar referenced this in commit 5091ab5bcc on Apr 8, 2020
  75. freedom1372 commented at 0:56 am on July 10, 2020: none

    Often requested feature: encrypt private keys in the wallet.dat file, so a password is required for a send transaction.

    I dowlanded bitcoin core but without create account and encrypt private keys i send small amount btc now I can’t send btc what is the reason? If i encrypt keys will I lose my bitcoin please help!

  76. MarcoFalke locked this on Jul 10, 2020
  77. DrahtBot added the label CI failed on Apr 2, 2023
  78. DrahtBot removed the label CI failed on Apr 2, 2023
  79. DrahtBot added the label CI failed on Apr 2, 2023
  80. DrahtBot removed the label CI failed on Apr 3, 2023
  81. DrahtBot added the label CI failed on Apr 5, 2023
  82. MarcoFalke removed the label CI failed on Apr 5, 2023
  83. DrahtBot added the label CI failed on Apr 11, 2023
  84. MarcoFalke removed the label CI failed on Apr 11, 2023


gavinandresen fabianhjr dooglus RytisLT jeffWelling ghost jhyslop genjix thiloplanz borneq benlake alexgenaud wherget NickyYangYang freedom1372

Labels
Brainstorming Wallet

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-11-21 12:12 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me