Upgrade VSS encryption and obfuscation scheme #627
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
👋 Thanks for assigning @jkczyz as a reviewer! |
tnull
force-pushed
the
2025-08-upgrade-vss-encryption-obfuscation-scheme
branch
from
ac8ae88 to
3490f2a
Compare
tnull
force-pushed
the
2025-08-upgrade-vss-encryption-obfuscation-scheme
branch
2 times, most recently
from
bec8829 to
e977a6d
Compare
tnull
force-pushed
the
2025-08-upgrade-vss-encryption-obfuscation-scheme
branch
3 times, most recently
from
c7fc423 to
dd9a9e0
Compare
tnull
force-pushed
the
2025-08-upgrade-vss-encryption-obfuscation-scheme
branch
6 times, most recently
from
96db24d to
e248dc5
Compare
We introuce an `enum VssSchemaVersion` that will allow us to discern differnent behaviors based on the schema version based on a backwards compatible manner.
We bump our `vss-client` dependency to include the changes to the `StorableBuilder` interface. Previously, we the `vss-client` didn't allow to set `ChaCha20Poly1305RFC`'s `aad` field, which had the `tag` not commit to any particular key. This would allow a malicious VSS provider to substitute blobs stored under a different key without the client noticing. Here, we now set the `aad` field to the key under which the `Storable` will be stored, ensuring that the retrieved data was originally stored under the key we expected, if `VssSchemaVersion::V1` is set. We also now obfuscate primary and secondary namespaces in the persisted keys, if `VssSchemaVersion::V1` is set. We also account for `StorableBuilder` now taking `data_decryption_key` by reference on `build`/`deconstruct`.
While having it in `VssStoreInner` makes more sense, we now opt to construt the client (soon, clients) in `VssStore` and then hand it down to `VssStoreInner`. That will allow us to use the client once for checking the schema version before actually instantiating `VssStoreInner`.
We previously attempted to drop the internal runtime from `VssStore`, resulting into blocking behavior. While we recently made changes that improved our situation (having VSS CI pass again pretty reliably), we just ran into yet another case where the VSS CI hung (cf. https://github.com/lightningdevkit/vss-server/actions/runs/19023212819/job/54322173817?pr=59). Here we attempt to restore even more of the original pre- ab3d78d / lightningdevkit#623 behavior to get rid of the reappearing blocking behavior, i.e., only use the internal runtime in `VssStore`.
Now that we rely on `reqwest` v0.12.* retry logic as well as client-side timeouts, we can address the remaining TODOs here and simply drop the redundant `tokio::timeout`s we previously added as a safeguard to blocking tasks (even though in the worst cases we saw they never actually fired).
To avoid any blocking cross-runtime behavior that could arise from reusing a single client's TCP connections in different runtime contexts, we here split out the `VssStore` behavior to use one dedicated `VssClient` per context. I.e., we're now using two connections/connection pools and make sure only the `blocking_client` is used in `KVStoreSync` contexts, and `async_client` in `KVStore` contexts.
We bump our `vss-client-ng` dependency to the latest release.
tnull
force-pushed
the
2025-08-upgrade-vss-encryption-obfuscation-scheme
branch
from
e248dc5 to
70f30cc
Compare
Since we just made some breaking changes to how exactly we persist data via VSS (now using an `aad` that commits to the key and also obfuscating namespaces), we have to detect which schema version we're on to ensure backwards compatibility. To this end, we here start reading a persisted `vss_schema_version` key in `VssStore::new`. If it is present, we just return the encoded value (right now that can only be V1). If it is not present, it can either mean we run for the first time *or* we're on V0, which we determine checking if anything related to the `bdk_wallet` descriptors are present in the store. If we're running for the first time, we also persist the schema version to save us these rather inefficient steps on following startups.
tnull
force-pushed
the
2025-08-upgrade-vss-encryption-obfuscation-scheme
branch
from
70f30cc to
85fd473
Compare
Collaborator
Author
|
Oh, seems when we also obfuscate the namespaces we might end up with keys that are too long. Will need to get back to the drawing board once more. |
tnull
force-pushed
the
2025-08-upgrade-vss-encryption-obfuscation-scheme
branch
from
173bfbc to
c84a361
Compare
tnull
force-pushed
the
2025-08-upgrade-vss-encryption-obfuscation-scheme
branch
from
c84a361 to
795e0f2
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Based on lightningdevkit/vss-client#40
In this PR we account for
vss-clientbeing renamed tovss-client-ng, upgrade to the latest v0.4.0 release, as well as fix minor issues with the data encryption and key obfuscation scheme currently employed byVssStore.As these are breaking changes, we'll also include a migration procedure as part of this PR.