[mip-001] envelope: per-owner vault-envelope key so hardware co-owners can open shares - #4
Open
ganymedio wants to merge 2 commits into
Open
[mip-001] envelope: per-owner vault-envelope key so hardware co-owners can open shares#4ganymedio wants to merge 2 commits into
ganymedio wants to merge 2 commits into
Conversation
…s can open shares The dk[Vault] envelope encrypted to the birational map of each co-owner's on-chain Ed25519 key, openable only with the Ed25519 private scalar — which hardware wallets never expose. Since multisig treasuries are a primary hardware use case, replace the recipient key with a per-owner vault-envelope key (vek): - private half reconstructable per backing (device signature on hardware, mnemonic path on software, pepper HKDF on keyless), never persisted at rest; - public half published to a vault-envelope-key registry and authenticated with an Ed25519 ownership signature the dealer verifies against the owner's on-chain key before sealing. No version bump — nothing has shipped, so v1 is redefined in place. The payload (dk[Vault]) and the store's end-to-end-encryption trust model are unchanged.
rubujubi
reviewed
Jul 16, 2026
| ``` | ||
| { ownerAddress, vekPub, ownerSig } | ||
| ownerSig = Ed25519-Sign(ownerSigningKey, | ||
| utf8("MovementConfidentialAsset/VaultEnvelopeKey/v1") ‖ vekPub) |
There was a problem hiding this comment.
Here I think ownerAddress should also be included in the signed payload, so that when the key pair is lost or leaked, the existing ownerSig can't be replayed to register that vekPub under a different address
Contributor
Author
There was a problem hiding this comment.
Thanks, updated payload to include ownerAddress.
…/TOC + envelope appendix - ownerSig now signs domain ‖ ownerAddress ‖ vekPub so a valid signature cannot be replayed to register a vekPub under a different address (one Ed25519 key can be authoritative for more than one account via key rotation or reuse). Updated in the registry definition, the dealer verification, the SDK signVaultEnvelopeKey/verifyVaultEnvelopeKey spec, and the Security Considerations trust model. - Add a bulleted TL;DR and a table of contents after the title. - Move the mv-dk-vault-v1 wire format, per-recipient sealing, and opening into Appendix A; leave a one-line pointer in Multisig accounts and fix the affected cross-references.
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
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.
Problem
MIP-001's
dk[Vault]envelope encrypts to the birational map of each co-owner's on-chain Ed25519 key, which opens only with the Ed25519 private scalar. A hardware wallet never exposes that scalar and has no ECDH/decryption primitive (it only signs), so a Ledger co-owner cannot open the envelope — leaving only the manualmv-dk-vault-raw-v1:copy-paste fallback. Multisig treasuries are a primary hardware use case, so this is a real UX gap.Fix: per-owner vault-envelope key (
vek)Replace the recipient encryption key with a per-owner vault-envelope key — an X25519 keypair where:
…/2'/0'); keyless → pepper HKDF;ownerSigthe dealer verifies against the owner's on-chain key before sealing.This lets hardware co-owners open envelopes using only the device's signing capability — no key export — while keeping the store's end-to-end-encryption trust model intact (a malicious store can't substitute a recipient key without forging the owner's signature).
Notes
v1is redefined in place rather than introducingv2.dk[Vault]still travels only inside the envelope; only the recipient encryption key changed.