Add wallet privkey encryption. #232
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Forum thread: http://forum.bitcoin.org/index.php?topic=8728.0 |
added 2 commits
June 9, 2011 15:11
This commit adds support for ekeys, or encrypted private keys, to the wallet. All keys are stored in memory in their encrypted form and thus the passphrase is required from the user to spend coins, or to create new addresses. Keys are encrypted with AES-256-CBC through OpenSSL's EVP library. The key is calculated via EVP_BytesToKey using AES256 with 1000 rounds. When the user is attempting to call RPC functions which require the password to unlock the wallet, an error will be returned unless they call walletpassword <password> <time to keep key in memory> first. A topupkeypool command has been added which tops up the users keypool (requiring the password via walletpassword first). keypoolsize has been added to the output of getinfo to show the user the number of keys left before they need to specify their password and call topupkeypool. A walletpasswordchange <oldpassword> <newpassword> has been added to allow the user to change their password via RPC. Whenever keying material (unencrypted private keys, the user's password, the wallet's AES key) is stored unencrypted in memory, any reasonable attempt is made to mlock/VirtualLock that memory before storing the keying material. This is not true in several (commented) cases where mlock/VirtualLocking the memory is not possible. Although encryption of private keys in memory can be very useful on desktop systems (as some small amount of protection against stupid viruses), on an RPC server, the password is entered fairly insecurely. Thus, the only main advantage encryption has for RPC servers is for RPC servers that do not spend coins, except in rare cases, eg. a webserver of a merchant which only receives payment except for cases of manual intervention. Thanks to jgarzik for the original patch and sipa for all his input.
|
Instead of using EVP_BytesToKey for key derivation I think scrypt (https://www.tarsnap.com/scrypt.html) should provide a somewhat better security against brute-force attacks. |
|
@sysfrog Im not sure. Though it may claim to be more secure, 1000 rounds on OpenSSL's algorithm is also very secure and I think I'd rather use a more common/well used/well analysed algorithm like OpenSSL's entire code base is. |
|
@dizzyd Ill take a look at updating to your other recommendations when I have a chance. |
|
re: the unused IV -- "may be some kind of crazy issue.." is not a logical argument. Being paranoid about security is good, but there needs to be some basis in reality for it. Otherwise, you wind up with a lot of code that doesn't do anything and may obscure what's really going on. re: calls to SetKey mlocking -- if that's the case, then you really don't need to copy it to vchKey. All that serves to do is increase the number of copies of keys you have in memory and increases your attack surface. Security-wise: careful, minimal code > paranoid code. B0.02 from a random coder. :) |
|
Is there a reason you are not using a random salt? |
|
witkamp:
Yeah, password data should be salted - I mean we DO already have a giant network of people with high-end GPUs and the drivers/software necessary to brute force such things ;) |
|
@TheBlueMatt As far as I understand scrypt the main advantage over older techniques is that it not only adds computational complexity to calculate a given key from a password, but that each calculation also requires a given amount of RAM. So it's much harder to parallelize an attack with, e.g., an ASIC, as you would need lots of RAM to do so. But I agree with you: There have been much more reviews of the SSL code base, and so the chance of critical errors in OpenSSL is much lower compared to scrypt. |
|
@witkamp mostly because it would be a pain to store. This patch already uses the public key as the IV for the encryption of each private key so any kind of brute force/dictionary attack is already ridiculously difficult, I dont see a major advantage to adding a random salt to be used for a given wallet (and then stored in the wallet) as to brute force a wallet, you already need to know some of the information in the wallet (namely the public keys). But maybe others disagree? @sysfrog OK, so its agreed then that OpenSSL key derivation is probably the best way to go? @dizzyd Still planning on updating with some of your original recommendations, but I'm on vacation atm and dont feel like doing much coding. |
|
@TheBlueMatt gotcha, didn't see the public key = IV bit but it makes sense and stops dictionary/BF attacks at least as well as a random salt so I'm happy with it as a solution. |
|
On Thu, Jun 16, 2011 at 11:24 AM, TheBlueMatt <
No worries -- I read your last reply first and was confused. :) D. |
|
It would be best to use AES128 and not AES256. The key schedule in AES256 is known to be weak. http://www.schneier.com/blog/archives/2009/07/another_new_aes.html |
|
Please salt that passphrase properly as suggested in gmaxwell's forum post. |
|
@phantomcircuit That attack is effective against 11-round AES-256, but not full 14-round AES-256. It'd be better to increase the number of rounds (he recommends 28 or more in that article) used instead of using a smaller key size. There are plenty of attacks on AES-128 as well, many of which were published after that article was written. |
|
Closing this in anticipation of the new branch. |
dexX7
pushed a commit
to dexX7/bitcoin
that referenced
this pull request
Dec 11, 2014
Remove UINT64_C
sipa
added a commit
to sipa/bitcoin
that referenced
this pull request
Apr 22, 2015
22f60a6 Merge pull request bitcoin#245 61c1b1e Merge pull request bitcoin#190 d227579 Add scalar blinding and a secp256k1_context_randomize() call. c146b4a Add bench_internal to gitignore. 9c4fb23 Add a secp256k1_fe_cmov unit test. 426fa52 Merge pull request bitcoin#243 d505a89 Merge pull request bitcoin#244 2d2707a travis: test i686 builds with gmp cf7f702 travis: update to new build infrastructure bb0ea50 Replace set/add with cmov in secp256k1_gej_add_ge. f3d3519 Merge pull request bitcoin#241 5c2a4fa Fix memory leak in context unit test 14aacdc Merge pull request bitcoin#239 93226a5 secp256k1.c: Add missing DEBUG_CHECKs for sufficiently capable contexts 6099220 Merge pull request bitcoin#237 6066bb6 Fix typo: avg -> max 9688030 Merge pull request bitcoin#236 d899b5b Expose ability to deep-copy a context 3608c7f Merge pull request bitcoin#208 a9b6595 [API BREAK] Introduce explicit contexts a0d3b89 Merge pull request bitcoin#233 9e8d89b Merge pull request bitcoin#234 65e70e7 Merge pull request bitcoin#235 5098f62 Improve documentation formatting consistency 4450e24 Add a comment about the avoidance of secret data in array indexes. 6534ee1 initialize variable d5b53aa Merge pull request bitcoin#232 c01df1a Avoid some implicit type conversions to make C++ compilers happy. bfe96ba Merge pull request bitcoin#231 33270bf Add a couple comments pointing to particular sections of RFC6979. 41603aa Merge pull request bitcoin#230 2632019 Brace all the if/for/while. git-subtree-dir: src/secp256k1 git-subtree-split: 22f60a6
dexX7
added a commit
to dexX7/bitcoin
that referenced
this pull request
Sep 18, 2015
a9fa833 Add API documentation for "omni_listpendingtransactions" (dexX7) 5bebb81 Add new RPC to list unconfirmed Omni transactions (dexX7)
TheBlueMatt
added a commit
to TheBlueMatt/bitcoin
that referenced
this pull request
Oct 20, 2015
This contains the following two merges, as well as a few other changes: Squashed 'src/secp256k1/' changes from 22f60a6..18f9f08 18f9f08 Pedersen commitments, borromean ring signatures, and ZK range proofs. 5161227 Add benchmark for ECDH multiplication c40cb72 Expose API for constant time point multiplication 40adc7a Add constant-time `secp256k1_ecdh_point_multiply` for ECDH ff9a397 Add zero/one tests to ecmult 729badf Merge pull request bitcoin#210 2d5a186 Apply effective-affine trick to precomp 4f9791a Effective affine addition in EC multiplication git-subtree-dir: src/secp256k1 git-subtree-split: 18f9f0821c5a7795b760763c99d545af96a22775 Squashed 'src/secp256k1/' changes from b0210a9..22f60a6 22f60a6 Merge pull request bitcoin#245 61c1b1e Merge pull request bitcoin#190 d227579 Add scalar blinding and a secp256k1_context_randomize() call. c146b4a Add bench_internal to gitignore. 9c4fb23 Add a secp256k1_fe_cmov unit test. 426fa52 Merge pull request bitcoin#243 d505a89 Merge pull request bitcoin#244 2d2707a travis: test i686 builds with gmp cf7f702 travis: update to new build infrastructure bb0ea50 Replace set/add with cmov in secp256k1_gej_add_ge. f3d3519 Merge pull request bitcoin#241 5c2a4fa Fix memory leak in context unit test 14aacdc Merge pull request bitcoin#239 93226a5 secp256k1.c: Add missing DEBUG_CHECKs for sufficiently capable contexts 6099220 Merge pull request bitcoin#237 6066bb6 Fix typo: avg -> max 9688030 Merge pull request bitcoin#236 d899b5b Expose ability to deep-copy a context 3608c7f Merge pull request bitcoin#208 a9b6595 [API BREAK] Introduce explicit contexts a0d3b89 Merge pull request bitcoin#233 9e8d89b Merge pull request bitcoin#234 65e70e7 Merge pull request bitcoin#235 5098f62 Improve documentation formatting consistency 4450e24 Add a comment about the avoidance of secret data in array indexes. 6534ee1 initialize variable d5b53aa Merge pull request bitcoin#232 c01df1a Avoid some implicit type conversions to make C++ compilers happy. bfe96ba Merge pull request bitcoin#231 33270bf Add a couple comments pointing to particular sections of RFC6979. 41603aa Merge pull request bitcoin#230 2632019 Brace all the if/for/while. 1897b8e Merge pull request bitcoin#229 efc571c Add simple testcases for signing with rfc6979 extra entropy. 1573a10 Add ability to pass extra entropy to rfc6979 3087bc4 Merge pull request bitcoin#228 d9b9f11 Merge pull request bitcoin#218 0065a8f Eliminate multiple-returns from secp256k1.c. 354ffa3 Make secp256k1_ec_pubkey_create reject oversized secrets. 27bc131 Silence some warnings from pedantic static analysis tools, improve compatibility with C++. 3b7ea63 Merge pull request bitcoin#221 f789c5b Merge pull request bitcoin#215 4bc273b Merge pull request bitcoin#222 137a8ec Merge pull request bitcoin#216 7c3771d Disable overlength-strings warnings. 8956111 use 128-bit hex seed 02efd06 Use RFC6979 for test PRNGs ae55e85 Use faster byteswapping and avoid alignment-increasing casts. 443cd4b Get rid of hex format and some binary conversions 0bada0e Merge bitcoin#214: Improve signing API documentation & specification 8030d7c Improve signing API documentation & specification 7b2fc1c Merge bitcoin#213: Removed gotos, which are hard to trace and maintain. 11690d3 Removed gotos, which are hard to trace and maintain. 122a1ec Merge pull request bitcoin#205 035406d Merge pull request bitcoin#206 2d4cd53 Merge pull request bitcoin#161 34b898d Additional comments for the testing PRNG and a seeding fix. 6efd6e7 Some comments explaining some of the constants in the code. ffccfd2 x86_64 assembly optimization for scalar_4x64 67cbdf0 Merge pull request bitcoin#207 039723d Benchmarks for all internal operations 6cc8425 Include a comment on secp256k1_ecdsa_sign explaining low-s. f88343f Merge pull request bitcoin#203 d61e899 Add group operation counts 2473f17 Merge pull request bitcoin#202 b5bbce6 Some readme updates, e.g. removal of the GMP field. f0d851e Merge pull request bitcoin#201 a0ea884 Merge pull request bitcoin#200 f735446 Convert the rest of the codebase to C89. bf2e1ac Convert tests to C89. (also fixes a use of bare "inline" in field) fc8285f Merge pull request bitcoin#199 fff412e Merge pull request bitcoin#197 4be8d6f Centralize the definition of uint128_t and use it uniformly. d9543c9 Switch scalar code to C89. fcc48c4 Remove the non-storage cmov 55422b6 Switch ecmult_gen to use storage types 41f8455 Use group element storage type in EC multiplications e68d720 Add group element storage type ff889f7 Field storage type 7137be8 Merge pull request bitcoin#196 0768bd5 Get rid of variable-length hex string conversions e84e761 Merge pull request bitcoin#195 792bcdb Covert several more files to C89. 45cdf44 Merge pull request bitcoin#193 17db09e Merge pull request bitcoin#194 402878a fix ifdef/ifndef 25b35c7 Convert field code to strict C89 (+ long long, +__int128) 3627437 C89 nits and dead code removal. a9f350d Merge pull request bitcoin#191 4732d26 Convert the field/group/ecdsa constant initialization to static consts 19f3e76 Remove unused secp256k1_fe_inner_{start, stop} functions f1ebfe3 Convert the scalar constant initialization to static consts 50cc6ab Merge pull request bitcoin#178 941e221 Add tests for handling of the nonce function in signing. 10c81ff Merge pull request bitcoin#177 7688e34 Add magnitude limits to secp256k1_fe_verify to ensure that it's own tests function correctly. 4ee4f7a Merge pull request bitcoin#176 70ae0d2 Use secp256k1_fe_equal_var in secp256k1_fe_sqrt_var. 7767b4d Merge pull request bitcoin#175 9ab9335 Add a reference consistency test to ge_tests. 60571c6 Rework group tests d26e26f Avoid constructing an invalid signature with probability 1:2^256. b450c34 Merge pull request bitcoin#163 d57cae9 Merge pull request bitcoin#154 49ee0db Add _normalizes_to_zero_var variant eed599d Add _fe_normalizes_to_zero method d7174ed Weak normalization for secp256k1_fe_equal 0295f0a weak normalization bbd5ba7 Use rfc6979 as default nonce generation function b37fbc2 Implement SHA256 / HMAC-SHA256 / RFC6979. c6e7f4e [API BREAK] Use a nonce-generation function instead of a nonce cf0c48b Merge pull request bitcoin#169 603c33b Make signing fail if a too small buffer is passed. 6d16606 Merge pull request bitcoin#168 7277fd7 Remove GMP field implementation e99c4c4 Merge pull request bitcoin#123 13278f6 Add explanation about how inversion can be avoided ce7eb6f Optimize verification: avoid field inverse a098f78 Merge pull request bitcoin#160 38acd01 Merge pull request bitcoin#165 6a59012 Make git ignore bench_recover when configured with benchmark enabled 1ba4a60 Configure options reorganization 3c0f246 Merge pull request bitcoin#157 808dd9b Merge pull request bitcoin#156 8dc75e9 Merge pull request bitcoin#158 28ade27 build: nuke bashisms 5190079 build: use subdir-objects for automake 8336040 build: disable benchmark by default bccaf86 Merge pull request bitcoin#150 2a53a47 Merge pull request bitcoin#151 5f5a31f Merge pull request bitcoin#149 3907277 Merge pull request bitcoin#142 a3e0611 Enable tests in x86 travis builds 45da235 x86 builder 8bb0e93 Merge pull request bitcoin#155 971fe81 build: fix openssl detection for cross builds f22d73e Explicitly access %0..%2 as 64-bit so we use the right registers for x32 ABI e66d4d6 Avoid the stack in assembly and use explicit registers cf7b2b4 Fix ECDSA message hashes to 32 bytes 056ad31 Really compile with -O3 by default 74ad63a Merge pull request bitcoin#146 9000458 Merge pull request bitcoin#145 1f46b00 build: fix __builtin_expect detection for clang aaba2e0 Merge pull request bitcoin#136 8a0775c Merge pull request bitcoin#144 ee1eaa7 Merge pull request bitcoin#141 c88e2b8 Compile with -O3 by default 6558a26 Make the benchmarks print out stats 000bdf6 Rename bench_verify to bench_recovery 7c6fed2 Add a few more additional tests. 992e03b travis: add clang to the test matrix b43b79a Merge pull request bitcoin#143 e06a924 Include time.h header for time(). 8d11164 Add some additional tests. 3545627 Merge pull request bitcoin#118 6a9901e Merge pull request bitcoin#137 376b28b Merge pull request bitcoin#128 1728806 Merge pull request bitcoin#138 a5759c5 Check return value of malloc 39bd94d Variable time normalize ad86bdf Merge pull request bitcoin#140 54b768c Another redundant secp256k1_fe_normalize 69dcaab Merge pull request bitcoin#139 1c29f2e Remove redundant secp256k1_fe_normalize from secp256k1_gej_add_ge_var. 2b9388b Remove unused secp256k1_fe_inv_all f461b76 Allocate precomputation arrays on the heap b2c9681 Make {mul,sqr}_inner use the same argument order as {mul,sqr} 6793505 Convert YASM code into inline assembly f048615 Rewrite field assembly to match the C version 3ce74b1 Tweak precomputed table size for G git-subtree-dir: src/secp256k1 git-subtree-split: 22f60a6
deadalnix
pushed a commit
to deadalnix/bitcoin
that referenced
this pull request
Jan 19, 2017
c01df1a Avoid some implicit type conversions to make C++ compilers happy. (Gregory Maxwell)
lateminer
pushed a commit
to lateminer/bitcoin
that referenced
this pull request
Dec 9, 2017
Losangelosgenetics
pushed a commit
to Losangelosgenetics/bitcoin
that referenced
this pull request
Mar 12, 2020
cryptapus
pushed a commit
to cryptapus/bitcoin
that referenced
this pull request
May 3, 2021
f77c844 Use stripped-down CBaseMerkleTx for auxpow. (Daniel Kraft) 52dba35 Make CheckMerkleBranch private in CAuxPow. (Daniel Kraft) e607061 Do not inherit CMerkleTx from CAuxPow. (Daniel Kraft) d8c4475 Separate creation and initialisation of auxpow's. (Daniel Kraft) 5fe7f42 Make CAuxPow internals actually private. (Daniel Kraft) Pull request description: This is a collection of code cleanups for the `CAuxPow`-related code. Some internals are made private to enforce better encapsulation, and the dependency-issue of `CMerkleTx` described in bitcoin#231 is fixed by introducing a `CBaseMerkleTx` class. Tree-SHA512: d5ec2e29137f9fca717017fa02f140e666b7c3f266a83f917144d9a4e44b9d979858553f77bf317d0dbeb2744defe72c41afa6912ba392fbc89e8b1fbcc4f438
hebasto
added a commit
that referenced
this pull request
Aug 11, 2021
…let loaded 0237d95 qt: Add Load PSBT functionaliy with nowallet (Prateek Sancheti) Pull request description: This PR provides a fix to the issue mentioned in #232. Currently, the **_Load PSBT_** functionality works well in case a wallet is loaded but does nothing when a wallet isn't loaded. If a function cannot work without a wallet being loaded, it is disabled by default (It is unclickable as shown in the image). For e.g. One cannot `Close Wallet` or `Backup Wallet` or `Sign Messages` without a wallet being loaded. And hence they are disabled. But if you notice, `Load PSBT` options are not disabled by default even when a wallet isn't loaded. >  As mentioned by hebasto in the issue description : ``` <hebasto> achow101: does "File" -> "Load PSBT from {file|clipboard}" make any sense when no wallet is loaded? <achow101> hebasto: yes, for finalize and sending ``` This means **_Load PSBT_** should be working just as similar whether wallets are being loaded or not. After making the required changes to the code, The **_Load PSBT_** works as expected even with no wallet loaded and the PSBT is finalized. | Master | PR | |-------------|---------------| |  |  | Close #232 ACKs for top commit: achow101: re-ACK 0237d95 hebasto: ACK 0237d95, tested on Linux Mint 20.2 (Qt 5.12.8). Tree-SHA512: 8d928c5bfd3c2b286ddcacd0b367c872de8bc3d3d9d82280faeadc60d738b86af328c060b5763ade364c9b386b23f95580c2eb1147b16373fbb713170c100350
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit adds support for ekeys, or encrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC through OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using AES256 with 1000 rounds.
Each RPC command which requires the password in practice has an additional
parameter, namely that password. Due to the need to convert the types of
other parameters before sending them, users who do not use encryption (via
the -nocrypt option) will have to specify a blank string (or any string) as
the first parameter, followed by the command they currently use.
Whenever keying material (unencrypted private keys, the user's password, the
wallet's AES key) is stored unencrypted in memory, any reasonable attempt is
made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa for all his input.