Encryption of the content of PSBT files

[takuma sato]

I would like to know if there are any plans or progress being made in protecting the contents of a PSBT file. Because the contents of a PSBT file may have sensible information, couldn't it be encrypted and only decrypted during the signing/broadcast while your wallet is unlocked for the task? This could solve the whole problem of having to carry the file encrypted with some software. You may forget doing this and leave some trace of the transaction along the way. The idea is to maintain an enclosure system where everything is contained inside the software. I have sometimes even thought about being able to encrypt the debug.log file because it also leaves traces of what you are doing inside the wallet.

[Charles-Tim]

Not necessary at all.

Anyone can import a bitcoin address belonging to another person and use it to make bitcoin partially signed transaction. There is nothing special about it at all than only the person that has the private key of the address that can sign the transaction.

Or you mean after the transaction has been signed? I also think it is not necessary.

[Antidote47k]

The only sensitive information I can think that anyone can get from PSBT is financial information and maybe wallet metadata which I can understand if one wants to keep that private, else standard PSBT don’t contain private keys themselves.
The main purpose of PSBT is to allow different applications and devices to cooperate which includes offline signers and hardware wallets, if we’re considering encryption we also have to consider how both parties securely establish and exchange said encryption key, I’m not saying it’s impossible it just have to fit the workflow, now is this worthwhile?? personally I’m not sure, the file itself doesn’t pose much security risk depending on the context, it’s more of a privacy exposure rather than a direct theft of private keys

[nc50lc]

Because the contents of a PSBT file may have sensible information, -snip-

Does the previously suggested arg bip32derivs false when creating, processing or signing the PSBT not enough for this?
I saw others suggested you this before.

Because with the arg's value set to "false", it'll only contain as much info as the nodes will get once you broadcast the finalized transaction.

e.g. (5th arg is bip32derivs):

Code:

walletcreatefundedpsbt "[]" '[{"bc1_address":0.1235}]' 0 "{}" false

[Danish Ali]

Does the previously suggested arg bip32derivs false when creating, processing or signing the PSBT not enough for this?

It only fixes a small part of the privacy leak (derivation paths and associated wallet info). It does not fix what the OP describes, since transaction values, destination scripts and UTXOs being spent are all details the signer would need to check. While you can ditch some metadata, stripping out the actual transaction details does not really fix the privacy issue across the board, which is that anyone who gets their hands on an unencrypted PSBT can read the information it contains.

couldn't it be encrypted and only decrypted during the signing/broadcast while your wallet is unlocked for the task?

My guess would be interoperability. Thats the whole purpose of the format, to allow different wallets, signers and other devices to interact using common transaction format. Encryption adds a lot of complications in terms of key management and how different devices/tools would need to deal with that. Again thats just my guess, as I am not intimately familiar with the format or its development.

That's not to say that encryption in the PSBT format would necessarily preclude interop, but it would add complication. I think encryption using other tools is probably a good workaround though - be it a GPG-encrypted file or storing the file on an encrypted USB stick/SD card. This gives some security in transit and at rest (although I havent looked into whether Bitcoin Core logs anything PSBT/transaction-related in its debug.log, so can't comment on whether that would leak info) without placing the burden of implementing built-in encryption on all wallet developers. Obviously, an encrypted volume does not protect logs from processes when the volume is decrypted, but it at least protects data at rest.

[takuma sato]

Because the contents of a PSBT file may have sensible information, -snip-

Does the previously suggested arg bip32derivs false when creating, processing or signing the PSBT not enough for this?
I saw others suggested you this before.

Because with the arg's value set to "false", it'll only contain as much info as the nodes will get once you broadcast the finalized transaction.

e.g. (5th arg is bip32derivs):

Code:

walletcreatefundedpsbt "[]" '[{"bc1_address":0.1235}]' 0 "{}" false

I remember reading some stuff about not using that because it added another risks, also what the user above said, it does not really hide amounts and so on.

Does the previously suggested arg bip32derivs false when creating, processing or signing the PSBT not enough for this?

It only fixes a small part of the privacy leak (derivation paths and associated wallet info). It does not fix what the OP describes, since transaction values, destination scripts and UTXOs being spent are all details the signer would need to check. While you can ditch some metadata, stripping out the actual transaction details does not really fix the privacy issue across the board, which is that anyone who gets their hands on an unencrypted PSBT can read the information it contains.

Does the previously suggested arg bip32derivs false when creating, processing or signing the PSBT not enough for this?

It only fixes a small part of the privacy leak (derivation paths and associated wallet info). It does not fix what the OP describes, since transaction values, destination scripts and UTXOs being spent are all details the signer would need to check. While you can ditch some metadata, stripping out the actual transaction details does not really fix the privacy issue across the board, which is that anyone who gets their hands on an unencrypted PSBT can read the information it contains.

couldn't it be encrypted and only decrypted during the signing/broadcast while your wallet is unlocked for the task?

My guess would be interoperability. Thats the whole purpose of the format, to allow different wallets, signers and other devices to interact using common transaction format. Encryption adds a lot of complications in terms of key management and how different devices/tools would need to deal with that. Again thats just my guess, as I am not intimately familiar with the format or its development.

That's not to say that encryption in the PSBT format would necessarily preclude interop, but it would add complication. I think encryption using other tools is probably a good workaround though - be it a GPG-encrypted file or storing the file on an encrypted USB stick/SD card. This gives some security in transit and at rest (although I havent looked into whether Bitcoin Core logs anything PSBT/transaction-related in its debug.log, so can't comment on whether that would leak info) without placing the burden of implementing built-in encryption on all wallet developers. Obviously, an encrypted volume does not protect logs from processes when the volume is decrypted, but it at least protects data at rest.

I think im just going to keep using encrypted compressed volumes for files and that's about it. But as far as compatibility, they could make it work at least when working within Bitcoin Core (one Bitcoin Core node in laptop 1 and another Bitcoin Core wallet in airgap laptop 2, so it's all within the same software). But I guess it's easier if you just encrypt the file yourself. The problem is well, when you decrypt the file, it has been on the SSD. Now if it was an HDD you could shred it, but SSDs suck for that, so that is a problem. Like I said ideally the contents would never be decrypted except in RAM for the required amount of time to perform the transaction, so this is worth researching a solution for.

[Danish Ali]

The problem is well, when you decrypt the file, it has been on the SSD. Now if it was an HDD you could shred it, but SSDs suck for that, so that is a problem.

This is another reason why I dont think ignoring encrypted volumes is a good option. Due to things like over-provisioning and wear-leveling, its entirely possible that "overwriting" or deleting the file will actually result in the FTL writing that data in a different location and remapping the block rather than actually "overwriting" the data in the original location.

And as has been pointed out, the OS-level shredding tools are only going to deal with logical addresses and can do nothing about blocks that may have been remapped. So any remnants left in the flash should still be encrypted if the PSBT was in a suitably encrypted volume. Of course, whole encrypted volume thing only helps if you avoid ever writing a cleartext copy somewhere, such as temp files or swap on unencrypted filesystems, but depending on setup, FDE can cover lot of that as well.

they could make it work at least when working within Bitcoin Core (one Bitcoin Core node in laptop 1 and another Bitcoin Core wallet in airgap laptop 2, so it's all within the same software)

That does resolve one issue, "both ends speak the same software" instead of "how do two different wallets agree on a key", assuming of course that you have to physically transfer the transaction, say on a USB/SD card between laptop 1 and laptop 2. Whether it resolves the encrypted volume issue is less clear to me.

If you have encrypted transaction that is only ever decrypted in RAM, then arguably it is much less important to have the removable volume itself be encrypted, though probably still good idea as defence in depth.

[nc50lc]

Does the previously suggested arg bip32derivs false when creating, processing or signing the PSBT not enough for this?
I saw others suggested you this before.

I remember reading some stuff about not using that because it added another risks, also what the user above said, it does not really hide amounts and so on.

I don't know any risk introduced by stripping those from your PSBT, perhaps it's a misunderstanding.
A reference would be nice.

AFAIK, it'll just make some signers unable to sign or finalize the transaction if they require such information, e.g.: Coldcard requires it.