Bip draft: Bitcoin Encrypted Backup

[pythcoiner]

This is a bip for encrypted backup, an encryption scheme for bitcoin wallet related metadata.

Mailing list post: https://groups.google.com/g/bitcoindev/c/5NgJbpVDgEc

[pythcoiner]

thanks for the review! will address comments tmr!

[Sjors]

Open questions

• Deterministic nonce: Currently the nonce is generated randomly. Is it safe to produce a deterministic nonce, e.g. hash("NONCE" || plaintext || key_1 || … || key_n), or are there known security concerns with this approach?

In general nonce reuse is unsafe because if you make multiple backups over time, e.g. as you add more transaction labels, you would be reusing the nonce with different message. By including the plaintext in the nonce, you do address that concern.

However it still seems unwise to mess with cryptographic standards. It doesn't seem worth the risk for saving 32 bytes on something that's going to be at least a few hundred bytes for a typical multisig.

[shocknet-justin]

Concept ACK, seems adjacent to how some lightning tools enable users to recover SCB's with just their seed to identify and decrypt the backup. Makes sense for descriptors to have something similar.

[Sjors]

Concept ACK

[pythcoiner]

(not yet finish addressing comments)

[KeysSoze]

Hi @pythcoiner,

By coincidence, two weeks ago I started working on a proposal for a "Standard Encrypted Wallet Payload" to be placed inside an "Encrypted Envelope". The "Wallet Payload" contains descriptors and metadata but can also act as a full wallet backup including transactions, UTXOs and addresses. The proposal is very much a work in progress.

I only just found this discussion so am reading through it to compare it to my proposal. The descriptor backup in the "Wallet Payload" of my proposal seems to have some overlap with the BIP proposed here. If there is too much overlap I may reconsider progressing with my proposal.

As mentioned, my proposal is very much a work in progress but the wallet payload proposal can be found here:

https://gist.github.com/KeysSoze/7109a7f0455897b1930f851bde6337e3

Maybe jump to the test vector section to see what a basic backup of a descriptor and some meta data would look like prior to encryption.

https://gist.github.com/KeysSoze/7109a7f0455897b1930f851bde6337e3#test-vectors

As my proposal is designed to be modular and extensible the encryption envelopes may be extended to offer Multiparty Encryption and Authentication. See:

https://gist.github.com/KeysSoze/7109a7f0455897b1930f851bde6337e3#user-content-Expanding_the_Security_Model

I have already started documenting an encryption envelope that uses AES-256-GCM and password protection:

https://gist.github.com/KeysSoze/866d009ccd082edf6802df240154b20d

I have not written a reference implementation yet but there are well established python and Rust libraries for CBOR and COSE that should make implementing the BIPs relatively simple.

[pythcoiner]

Hi @pythcoiner,

By coincidence, two weeks ago I started working on a proposal for a "Standard Encrypted Wallet Payload" to be placed inside an "Encrypted Envelope". The "Wallet Payload" contains descriptors and metadata but can also act as a full wallet backup including transactions, UTXOs and addresses. The proposal is very much a work in progress.

Hi @KeysSoze, this work seems more related/parallel to the wallet_backup specs I've work on few month ago.

But I've adopted a slightly different approach by simply using JSON.

FYI we already implemented this wallet backup format in Liana wallet and I plan to work on a BIP proposal relatively soon.

[Sjors]

I vibe coded an implementation on top of Bitcoin Core: Sjors/bitcoin#109

It's nice to see how we can mostly reuse existing tooling. It still adds over 1000 lines of non-test code though.

Doing so brought up some issues to reconsider:

• should we just use VarInt everywhere to simplify parsing at the expense of a few extra bytes?
• tagged hashes seem to deviate from how they work in BIP340, so we can't use TaggedHash(): (I didn't investigate), LLM says:

/ Current implementation (14 lines):
uint256 ComputeDecryptionSecret(const std::vector<uint256>& keys)
{
    HashWriter hasher{};
    hasher << std::span{reinterpret_cast<const uint8_t*>(BIP_DECRYPTION_SECRET_TAG.data()),
                        BIP_DECRYPTION_SECRET_TAG.size()};
    for (const auto& key : keys) {
        hasher << std::span{key.data(), 32};
    }
    return hasher.GetSHA256();
}

// With BIP340-style tags (could become):
uint256 ComputeDecryptionSecret(const std::vector<uint256>& keys)
{
    HashWriter hasher = TaggedHash("BIP_XXXX_DECRYPTION_SECRET");
    for (const auto& key : keys) hasher << key;
    return hasher.GetSHA256();
}

(that seems like a fairly trivial difference anyway)

[pythcoiner]

This proposal makes multiple references to BIP 380 as defining wallet descriptors. This is incorrect - BIP 380 defines output script descriptors. Since we may have a need to define wallet descriptors as specific format in future (including, for example, a wallet birthday) I believe these references should be corrected.

@craigraw Right, I'll change this

I vibe coded an implementation on top of Bitcoin Core: Sjors/bitcoin#109

@Sjors Thanks for looking on this!

I'm ok to change stuff if it make integration in core simpler

[pythcoiner]

adressed @Sjors & @craigraw comments:

• wallet descriptor => output script descriptor
• dropped AES_GCM_256 encryption algo
• use BIP340 tagged hash

[pythcoiner]

• should we just use VarInt everywhere to simplify parsing at the expense of a few extra bytes?

@Sjors I'm not sure it simplify the parsing for fixed length integers?

[Sjors]

Thanks for the updates. I plan to update my branch as well, but might be some time.

Regarding varint, it might slightly simplify a function like DecodeContent, but it's not a big deal.

[pythcoiner]

Thanks for the updates. I plan to update my branch as well, but might be some time.

Regarding varint, it might slightly simplify a function like DecodeContent, but it's not a big deal.

I not yet take time to look at your implem, but I plan to do so soon as I'm quite done with implem update on the rust implem and want to try tests vectors on both implem before finalizing the spec

[Sjors]

My implementation should be taken with a grain of salt, since I haven't had time to polish it.

[jonatack]

A few updates for BIP 3.

[pythcoiner]

@jonatack thanks for the review, addressed your comments

[pythcoiner]

I've done some work on top of @Sjors implem & updated the rust implem, both have tests passing on the same set of test vectors and follows the actual version of this spec

[murchandamus]

I’m afraid that I was not able to complete follow your specification. Could you please describe in more detail how the keys are extracted from descriptor/wallet policy?
It’s also not obvious to me how initial use of the descriptor would not reveal the decryption secret to third parties.

The document is missing a Backwards Compatibility section.

[murchandamus]

It seems to me that for a single-sig policy this would always result in $c_i$ = 0x0…0.

If single-sig wallets are not eligible for this scheme, I must have missed where this was stated.

[pythcoiner]

single sig descriptor are elligible to this format as sha256(sha256("BIPXXX_DECRYPTION_SECRET") | sha256("BIPXXX_DECRYPTION_SECRET") | $p_1$ )!= sha256(sha256("BIPXXX_INDIVIDUAL_SECRET") | sha256("BIPXXX_INDIVIDUAL_SECRET") | $p_1$ ) as the tag differ, but maybe I miss something?

[murchandamus]

No, I missed that! I’m gonna take another look at your recent updates and then see whether that was just me reading too quickly, or whether it could perhaps be stated more explicitly why the scheme is applicable to any set of public keys.

[murchandamus]

I’m not sure that I correctly understood which public keys are being used to encrypt the data, but if it is the zeroth keys in the derivation sequence, wouldn’t any UTXO received to the zeroth address and later spent give a surveillant the information to decrypt the backup?

[pythcoiner]

Good catch, you raise an important point, we must disallow key expressions w/o a trailing derivation!

[pythcoiner]

Thanks @murchandamus for the review, I addressed your comments and reworked the spec:

• Better specification of which key is selected
• Disallowed keys that dont have a trailing derivation
• Updated test vectors