For a pull after new wallet crypto.
Minor non-blocker updates to Crypto. #360
pull TheBlueMatt wants to merge 6 commits into bitcoin:master from TheBlueMatt:timecryptorounds changing 23 files +1372 −114-
TheBlueMatt commented at 3:04 PM on June 28, 2011: member
-
Prepare CKeyStore for Encrypted Keys. a5da9b978c
-
3ad5c11f73
mlock() all private keys in memory
Inline comment and idea come from the encprivkeys branch by Matt Corallo <matt@bluematt.me>.
-
c5b9127f2c
Add wallet privkey encryption.
This commit adds support for ckeys, 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 SHA512 with (by default) 25000 rounds and a random salt. By default, the user's wallet remains unencrypted until they call the RPC command encryptwallet <password> or, from the GUI menu, Options-> Encrypt Wallet. 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 keypoolrefill 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. When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool returns vchDefaultKey, meaning miners may start to generate many blocks to vchDefaultKey instead of a new key each time. 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.
-
Set the number of SHA512 rounds based on the speed of the computer. 31e18587e0
-
Push unlocked_until in getinfo. 5522447412
-
Dynamically remove/insert the Options for encryption in the menus. 06b09e3067
-
TheBlueMatt commented at 12:03 AM on June 29, 2011: member
This grew way to quick, so I merged it into the Crypto pull.
- TheBlueMatt closed this on Jun 29, 2011
- jtimon referenced this in commit 91ee21c024 on Mar 11, 2016
- laanwj referenced this in commit 0ffb3bd95f on Aug 4, 2016
- laanwj referenced this in commit b2135359b3 on Aug 16, 2016
- MarcoFalke referenced this in commit 64dfdde0aa on Dec 13, 2016
- deadalnix referenced this in commit c18b869e58 on Jan 19, 2017
- deadalnix referenced this in commit 87392b4489 on Mar 20, 2017
- classesjack referenced this in commit d81ca26646 on Jan 2, 2018
- lateminer referenced this in commit a83e9efbb1 on Oct 16, 2019
- DrahtBot locked this on Sep 8, 2021
Contributors