You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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 theentropy-kvdb
crate:entropy-core/crates/kvdb/src/encrypted_sled/kv.rs
Line 191 in 3e87482
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.
The text was updated successfully, but these errors were encountered: