feat: zeroize cryptographic secrets on drop #988

Merged

vnprc merged 1 commit from zeroize_on_drop into main

2025-08-21 20:53:26 +00:00

vnprc commented

2025-08-21 15:48:34 +00:00

(Migrated from github.com)

implement zeroize on Drop for Secret, Wallet, and MultiMintWallet
this erases sensitive memory addresses before deallocation

Description

Minor security improvement that prevents a memory dump, swap file, or process memory inspection attack from exposing secrets left in deallocated memory addresses.

This is good hygiene and could be useful as part of a defense in depth strategy. Currently, it doesn't accomplish much because the master seed is kept in Wallet memory for the duration of the process.

A more meaningful security improvement would be to encrypt the seed on disk and load it into memory only when actively deriving keys. This would have a high performance impact due to the high frequency of ecash operations. Perhaps a better approach would be to focus on device architectures with a secure computing environment such as a secure enclave on a mobile phone and using something like VLS on mint servers.

In any case this PR has very low performance impact and it's better than nothing.

Notes to the reviewers

Suggested CHANGELOG Updates

CHANGED

ADDED

REMOVED

FIXED

Checklist

I followed the code style guidelines
I ran just final-check before committing

implement zeroize on Drop for Secret, Wallet, and MultiMintWallet this erases sensitive memory addresses before deallocation ### Description Minor security improvement that prevents a memory dump, swap file, or process memory inspection attack from exposing secrets left in deallocated memory addresses. This is good hygiene and could be useful as part of a defense in depth strategy. Currently, it doesn't accomplish much because the master seed is kept in Wallet memory for the duration of the process. A more meaningful security improvement would be to encrypt the seed on disk and load it into memory only when actively deriving keys. This would have a high performance impact due to the high frequency of ecash operations. Perhaps a better approach would be to focus on device architectures with a secure computing environment such as a secure enclave on a mobile phone and using something like [VLS](https://github.com/lightning-signer) on mint servers. In any case this PR has very low performance impact and it's better than nothing. ----- ### Notes to the reviewers  ----- ### Suggested [CHANGELOG](https://github.com/cashubtc/cdk/blob/main/CHANGELOG.md) Updates  #### CHANGED #### ADDED #### REMOVED #### FIXED ---- ### Checklist * [x] I followed the [code style guidelines](https://github.com/cashubtc/cdk/blob/main/CODE_STYLE.md) * [x] I ran `just final-check` before committing

crodas (Migrated from github.com) reviewed

2025-08-21 15:48:34 +00:00

vnprc commented

2025-08-21 15:53:43 +00:00

(Migrated from github.com)

#979