Bitcoin Core encryption questions

[apogio]

Encrypting a wallet for me is crucial. People underestimate it, but encryption can literally save us, especially with digital files (like wallet.dat etc).

I have specific questions regarding encryption with Bitcoin Core, but please notice that I know the answers to some of them, I just ask for clarity and certainty.

1. Bitcoin Core uses AES-256 to encrypt the wallet.dat file, correct?

2. If I use GPG (AES-256) to encrypt the wallet.dat file, without encrypting with the native feature of Bitcoin Core, essentially it will be like encrypting the entire file, not being able to load it, nor use it at all, unless decrypted. Whereas encrypting within Bitcoin Core, allows me to encrypt only the private keys, which means decryption is needed only for sensitive functionalities, like signing etc. Correct?

3. If the (2) is correct, which I 've tried multiple times and I know it is, then is it recommended to store the wallet.dat file with double encryption?

4. Is the BIP-38 functionality completely removed from Bitcoin Core?

5. Does Bitcoin Core support or approve (in general) the physical paper backup of the private wallet descriptors? Is there a way to export my private descriptors from my Bitcoin Core wallet and print them in an encrypted format? What I thought about doing was to:
    (a) export the descriptors in a json file
    (b) encrypt it with GPG
    (c) convert the encrypted cipher into QR code
    (d) print the QR code
But, you can guess that I don't really like this kind of manual effort. Is there any possibility that Bitcoin Core ever accepts this and does this within the app? Isn't it really important to backup a wallet physically rather than digitally?

[BattleDog]

I always appreciate it when others take encryption seriously and want to learn more.

1) "Core encrypts wallet.dat with AES-256, right?"
Core encrypts the key material, not the whole file. Each private key/seed is encrypted with a random master key using AES-256-CBC. The master key is encrypted with your passphrase via EVP_BytesToKey(SHA-512 + salt + iterations). Metadata (labels, txs, watch-only, etc.) stays readable so the wallet can load while locked.

2) If I GPG-encrypt wallet.dat externally…
Correct: you'll encrypt the entire file and Core can't open it until you decrypt it first. Native encryption lets Core load/receive/watch while keeping spends locked.

3) Should I "double-encrypt"?
For backups, yes--keeping a copy of the Core-encrypted wallet.dat additionally wrapped in GPG/VeraCrypt/LUKS is fine. Just keep at least one copy you know you can restore (test a restore!), and don't overwrite the only good backup with a failed re-encryption.

4) BIP-38?
Core does not support BIP-38 (and never did). If you export WIF keys you'd need an external tool to BIP-38 them. Recommended path today is descriptor/seed backups, not BIP-38.

5) Paper/descriptors backup
Core already lets you export the descriptor set (including privkeys) via RPC:

listdescriptors true --> JSON of descriptors with xprv.

dumpwallet <file> --> legacy: all keys + metadata in text.

You can take that JSON/text offline and GPG-encrypt it. Printing a QR is your choice (be mindful of QR size; you'll likely split across multiple QRs). Core doesn't do the QR/encryption for you in the GUI; you'd script this yourself on an air-gapped machine.

Use a long, unique wallet passphrase; Core's KDF has an iteration count but passphrase quality dominates. Make multiple offline backups (wallet.dat and/or listdescriptors true) in separate locations.

If you want extra protection at rest, put the backup inside an encrypted container or GPG it--in addition to Core's native encryption. Test your restore procedure once, then seal the backups.

The above setup gives you: usable day-to-day wallet (locked), plus verifiable offline backups with defense-in-depth.

[apogio]

5) Paper/descriptors backup
Core already lets you export the descriptor set (including privkeys) via RPC:

listdescriptors true --> JSON of descriptors with xprv.

dumpwallet <file> --> legacy: all keys + metadata in text.

You can take that JSON/text offline and GPG-encrypt it. Printing a QR is your choice (be mindful of QR size; you'll likely split across multiple QRs). Core doesn't do the QR/encryption for you in the GUI; you'd script this yourself on an air-gapped machine.

Use a long, unique wallet passphrase; Core's KDF has an iteration count but passphrase quality dominates. Make multiple offline backups (wallet.dat and/or listdescriptors true) in separate locations.

If you want extra protection at rest, put the backup inside an encrypted container or GPG it--in addition to Core's native encryption. Test your restore procedure once, then seal the backups.

The above setup gives you: usable day-to-day wallet (locked), plus verifiable offline backups with defense-in-depth.

I think we both described the same process for step (5). What I am actually asking is whether there is a good, recommended by Core's developers, in order to back up the wallet.dat in a physical medium, rather than a digital one. But, writing an XPRV isn't the optimal way, because it lacks encryption. So, I am wondering if they do it, if they recommend it and if they endorse it in general as a concept.

[BattleDog]

5) Paper/descriptors backup
Core already lets you export the descriptor set (including privkeys) via RPC:

listdescriptors true --> JSON of descriptors with xprv.

dumpwallet <file> --> legacy: all keys + metadata in text.

You can take that JSON/text offline and GPG-encrypt it. Printing a QR is your choice (be mindful of QR size; you'll likely split across multiple QRs). Core doesn't do the QR/encryption for you in the GUI; you'd script this yourself on an air-gapped machine.

Use a long, unique wallet passphrase; Core's KDF has an iteration count but passphrase quality dominates. Make multiple offline backups (wallet.dat and/or listdescriptors true) in separate locations.

If you want extra protection at rest, put the backup inside an encrypted container or GPG it--in addition to Core's native encryption. Test your restore procedure once, then seal the backups.

The above setup gives you: usable day-to-day wallet (locked), plus verifiable offline backups with defense-in-depth.

I think we both described the same process for step (5). What I am actually asking is whether there is a good, recommended by Core's developers, in order to back up the wallet.dat in a physical medium, rather than a digital one. But, writing an XPRV isn't the optimal way, because it lacks encryption. So, I am wondering if they do it, if they recommend it and if they endorse it in general as a concept.

There isn't an "official paper-backup format" for Bitcoin Core and the project doesn't endorse one.
Core only guarantees an encrypted wallet.dat file (your day-to-day wallet), and the ability to export the key material in plaintext if you ask for it (listdescriptors true, or legacy dumpwallet).

Once you export keys/descriptors they are not encrypted by design. Core intentionally doesn't invent a special "paper-encryption" scheme or mnemonic. If you want a physical backup you have to add the protection yourself.

Core devs generally recommend encrypting the wallet (encryptwallet), then keep multiple offline copies of the encrypted wallet.dat in different places (USB/offline disk, etc.).

On top of that, keep a verifiable text backup of descriptors (listdescriptors true) offline and protect it yourself (e.g., GPG-encrypt and print the ASCII-armored text; or split with Shamir/SSKR if you like). Test a restore once, then seal the backups.


So the practical, supported path is: keep the encrypted wallet.dat (digital) + store the passphrase and an offline, operator-protected descriptor dump (physical if you wish). There is no Core-endorsed "paper wallet.dat" because any exported key material is necessarily plaintext and must be protected by you.

Hope this solves your issue.

[apogio]

Core intentionally doesn't invent a special "paper-encryption" scheme or mnemonic. If you want a physical backup you have to add the protection yourself.
Core devs generally recommend encrypting the wallet (encryptwallet), then keep multiple offline copies of the encrypted wallet.dat in different places (USB/offline disk, etc.).

I am not sure about the "intentional" part. Perhaps they've found some ways to do it manually that aren't standardized and that's why they're not featured in Bitcoin Core.

I am not a fan of digital backups. If you have 3 media in which you store your wallet.dat, chances are you'll be ok, but I prefer trusting paper.

The problem is, that the easiest way I 've found so far for doing a proper backup is the following:

1. Export the private descriptors in a JSON file.
2. GPG-encrypt the json file.
3. Print the encrypted cipher.

The cipher though looks like this:

Code:

-----BEGIN PGP MESSAGE-----

jA0ECQMIIiJ2eY6Wilzn0sC+AQ+TSmnY/IYTZxx7CnBRml1IqfuW/+KTjUB6vFr7
loFOkll20FVtaCKpXcOBWVe4N20AoqnKCfP7E0pAl2BBa2GIPYZy5uOryUfsUpol
AZmqaqMImzvjo1mrWqmGqf7XVDwQfoZH25qByzSqLauZp6N32Toi3DksDmguhsnM
hNERCsIKkPKjjCIn03plHEktl3ZfRdDzgeZePAxQKsya85NwM4ycePDhQPKNNfxT
IlzITWbmNyj4ebWUXw7qdy/vxsyItv0KjCO6384oR8+5l8x0ZUPplzjKcMNLBv69
ikiAuQfWY2Yc/r6CvsUkMbkAsgjEEF5zQttz0f5jeXIJmZO/bH8boiSn+UNwgaUX
7XKcX0aCCbKzSnKNcZfgIQmJYqdbZNHE/o7+J87Cdq+eGYpzwsKq5WSTr57J8jpZ
pRiIqcQGyuftMqktnUUlo4o7/V8/nog1tpdm1Nei/z/NakA2cajLoqP4k7js/xkw
Q10BmaYZZ3w5FWVnUa0ACw==
=Wqxk
-----END PGP MESSAGE-----

Easy to print, but very difficult to write down in order to decrypt it.

So, getting a QR code out of this is, perhaps, easier.

Anyway, I guess I am asking primarily because I want to see if anyone has a good way to backup a Bitcoin Core wallet on a physical medium (paper ideally).

[Forsyth Jones]

Easy to print, but very difficult to write down in order to decrypt it.

So, getting a QR code out of this is, perhaps, easier.

Anyway, I guess I am asking primarily because I want to see if anyone has a good way to backup a Bitcoin Core wallet on a physical medium (paper ideally).

If you prefer paper backups (encrypted with a QR Code), the easiest and most secure way for you is to import a wallet with an existing recovery seed (created outside of Bitcoin Core, obviously) via descriptors, extracting the BIP32 root key (which is what I did in my case).

But even so, you might prefer to encrypt the descriptors extracted from Core using gpg/aes, and then convert them into a Qr Code format. It would be an interesting experiment to follow.

I'll tell you what I would do in my case:

*Let's assume I created a native wallet in Core. I'll encrypt it with my password/passphrase before transferring funds, obviously. For me, just backing up the wallet.dat file is enough, but to prevent snoopers from accessing my wallet.dat and seeing the balance and transactions but not being able to spend, I'll add additional encryption, perhaps using gpg or aes, or perhaps something simpler like moving the file to a Veracrypt container or (even easier) to a KeePass database file.

This would make a great topic (about additional encryption in the core).

*Of course, I would do the entire procedure in an offline air-gapped environment, the same for any of the encryption methods mentioned.

I wouldn't make any physical backups, at least for now.

[apogio]

*Let's assume I created a native wallet in Core. I'll encrypt it with my password/passphrase before transferring funds, obviously. For me, just backing up the wallet.dat file is enough, but to prevent snoopers from accessing my wallet.dat and seeing the balance and transactions but not being able to spend, I'll add additional encryption, perhaps using gpg or aes, or perhaps something simpler like moving the file to a Veracrypt container or (even easier) to a KeePass database file.

So what I am trying to achieve is to have a physican backup of a core wallet, but being encrypted I am putting this emoji because it looks like nobody has done it, or hasn't seen this thread yet.

Your approach looks like what I currently do, more or less and it's a common method. To be honest, encrypting the wallet.dat and the disc where it lies with another password is more than enough. It doesn't need extra gpg encryption on the file itself.