af0da2fce2146a005f54b900a1fd545a6278173a crypto: Use `secure_allocator` for `AES256CBC*::iv` (David Gumberg)
d53852be316dd2322a7e621a81ee33e1b234c530 crypto: Use `secure_allocator` for `AES256_ctx` (David Gumberg)
8c6fedaa81882be1e2db4a9a2291205d774fa4c6 build: `lockedpool.cpp` kernel -> crypto (David Gumberg)
51ac1abf6fdb6340110397a959681d52e29f73f7 bench: Add wallet encryption benchmark (David Gumberg)
9a158725161f726eb6747811e9e9335eef83f616 wallet: Make encryption derivation clock mockable (David Gumberg)
ae5485fa0d258f060a22c399a4e257eaf96e67b5 refactor: Generalize derivation target calculation (David Gumberg)
Pull request description:
Fixes#31744
Reuse `secure_allocator` for `AES256_ctx` in the aes 256 encrypters and decrypters and the `iv` of `AES256CBC` encrypters and decrypters. These classes are relevant to `CCrypter`, used for encrypting wallets, and my understanding is that if an attacker knows some or all of the contents of these data structures (`AES256_ctx` & `iv`) they might be able to decrypt a user's wallet.
Presently the `secure_allocator` tries to protect sensitive data with `mlock()` on POSIX systems and `VirtualLock()` on Windows to prevent memory being paged to disk, and by zero'ing out memory contents on deallocation with `memory_cleanse()` which is similar to `OPENSSL_cleanse()` by scaring compilers away from optimizing `memset` calls on non-Windows systems, and using `SecureZeroMemory()` on Windows.
ACKs for top commit:
achow101:
ACK af0da2fce2146a005f54b900a1fd545a6278173a
furszy:
utACK af0da2fce2146a005f54b900a1fd545a6278173a
theStack:
re-ACK af0da2fce2146a005f54b900a1fd545a6278173a
Tree-SHA512: 49067934fd2f2b285fc7b1a7c853fd2d4475431b3a811ae511f61074dc71a99a0826c3ab40ab4a5dfc84b2b9914a90c920d2484b38ac19502e3bd6170ad27622
abaadc3d5b