Gavin Andresen [ARCHIVE] on Nostr: š Original date posted:2011-07-04 šļø Summary of this message: Gavin Andresen ...
š
Original date posted:2011-07-04
šļø Summary of this message: Gavin Andresen suggests encrypting unencrypted keys to prevent attackers from accessing them and recommends creating an encrypted wallet to protect against backup script failures. He also proposes adding a minimum version requirement to future-proof wallet upgrades.
š Original message:RE: "You have some unencrypted keys, should I encrypt them for you?"
That re-opens an "attacker packs the keypool with keypairs that they
know about" (if I can read/write wallet.dat, then I can delete
encrypted keypool keys and insert a bunch of unencrypted keypool keys
that I know how to spend, and rely on the user to click "OK" because
users are trained to just click "OK").
RE: breaking backup scripts: if they use the backupwallet RPC
command, then they will Just Work.
0.4 and later could, on wallet encryption, create a wallet_e.dat
(encrypted wallet). Then truncate wallet.dat and set its
file-permissions to 000, so if old versions of bitcoin OR any dumb
wallet backup scripts try to read it they fail.
RE: future-proofing: wallet.dat contains nFileVersion (version of
bitcoin that last wrote the wallet). Adding a nMinVersion that
specifies "you must be at least THIS version to read this file" seems
like a good idea so if you have version 0.4 or later future wallet
upgrades give you a reasonable message if you try to downgrade after
an incompatible change.
--
--
Gavin Andresen
šļø Summary of this message: Gavin Andresen suggests encrypting unencrypted keys to prevent attackers from accessing them and recommends creating an encrypted wallet to protect against backup script failures. He also proposes adding a minimum version requirement to future-proof wallet upgrades.
š Original message:RE: "You have some unencrypted keys, should I encrypt them for you?"
That re-opens an "attacker packs the keypool with keypairs that they
know about" (if I can read/write wallet.dat, then I can delete
encrypted keypool keys and insert a bunch of unencrypted keypool keys
that I know how to spend, and rely on the user to click "OK" because
users are trained to just click "OK").
RE: breaking backup scripts: if they use the backupwallet RPC
command, then they will Just Work.
0.4 and later could, on wallet encryption, create a wallet_e.dat
(encrypted wallet). Then truncate wallet.dat and set its
file-permissions to 000, so if old versions of bitcoin OR any dumb
wallet backup scripts try to read it they fail.
RE: future-proofing: wallet.dat contains nFileVersion (version of
bitcoin that last wrote the wallet). Adding a nMinVersion that
specifies "you must be at least THIS version to read this file" seems
like a good idea so if you have version 0.4 or later future wallet
upgrades give you a reasonable message if you try to downgrade after
an incompatible change.
--
--
Gavin Andresen