Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Secure deletion of keyshares #1121

Open
ameba23 opened this issue Oct 21, 2024 · 2 comments
Open

Secure deletion of keyshares #1121

ameba23 opened this issue Oct 21, 2024 · 2 comments

Comments

@ameba23
Copy link
Contributor

ameba23 commented Oct 21, 2024

When we delete our keyshare because we are leaving the signer set, we want to be sure it no longer exists on disk, rather than just being removed as an entry in the key-value database. That is - it should be overwritten by zero bytes.

My hunch is that we can achieve this by overwriting the value with a vector of zero bytes of the same length. We could do this in our wrapper to sled's remove method in the entropy-kvdb crate:

let prev_val = self.kv.remove(&key)?;

But without knowing how sled represents values internally, we cannot be sure that this will reliably overwrite the original value.

I have made an issue in the sled repo asking this question, and if we don't hear back i would write a test and / or read the code to investigate.

@ameba23
Copy link
Contributor Author

ameba23 commented Oct 22, 2024

Related issue: spacejam/sled#1512

@ameba23
Copy link
Contributor Author

ameba23 commented Nov 4, 2024

Since i have not heard anything back on that issue, i did some experimenting myself - writing / overwriting / removing string values to a sled db, and checking what i am able to read out of the db directly by using strings, eg: strings <dbfile>.

It appears that neither overwriting, nor removeing values guarantee that they are removed from disk. In my experiments they were always still present. Even if the operations were followed by a call to flush().

Im not sure if we can come up with a workaround for this, or if this means we should not use sled for storing keyshares.

Worth noting that sled is optimized for fast read and writes, not for optimal storage usage - maybe thats why things get left lying around forever.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: 📋 Backlog
Development

No branches or pull requests

2 participants