feat: confidential asset wallet integration#1
Conversation
|
|
||
| - A `ca_*` dApp ↔ wallet method namespace (read and write) advertised through the wallet-standard `features` map. | ||
| - Canonical `dk` derivation policies for software, hardware, and keyless backings, each binding the token's FA metadata address into the derivation input. | ||
| - Per-`(account, token)` `dk` isolation, in-wallet proof construction, and an explicit-authorization model for rollover/normalization (no silent acceptance of incoming funds). |
There was a problem hiding this comment.
This (and L76, L86, L210–212, L501) hard-codes "rollover is always a separate user action." My understanding from prior discussion was the opposite direction: combined balance display + atomic rollover_and_{withdraw,transfer} entries.
- update TEMPLATE.md placeholders and mip-001 created field from mm/dd/yyyy to yyyy-mm-dd
| "mv-dk-enc-v1" // 12-byte ASCII version tag, also included in AAD | ||
| ‖ ephemeralX25519Pub // 32 bytes — proposer's per-share ephemeral X25519 public key | ||
| ‖ nonce // 12 bytes — AES-GCM nonce, all-zero (safe: ephemeral key unique per envelope) | ||
| ‖ ciphertextWithTag // 48 bytes = 32-byte dk + 16-byte GCM tag |
There was a problem hiding this comment.
L376 hard-codes the AES-GCM nonce to all-zero. AES-GCM stays safe only if (aesKey, nonce) never repeats — with the nonce fixed, that means aesKey must be unique across every envelope ever produced. The spec doesn't actually guarantee this.
aesKey = HKDF-SHA256(sharedSecret, info) at L385:
sharedSecretvaries per envelope only if the ephemeral keypair is fresh per envelope — L374's "per-share" doesn't pin that down.info = "mv-dk-share-v1" ‖ multisig ‖ token ‖ sender ‖ recipientrepeats whenever the same proposer re-shares to the same recipient for the same(multisig, token)— exactly the case for redelivery after a failed event index, or a re-share afterrotate_encryption_key.
If both happen, the second envelope encrypts a different dk under the same (aesKey, nonce=0). AES-GCM doesn't tolerate nonce reuse — both plaintexts become recoverable and the GCM tag can be forged.
Two options to consider:
- Random 12-byte nonce per envelope: eliminates the failure class outright; matches standard AES-GCM usage.
- Drop the nonce field and close the
inforepetition gap: explicitly forbid identical(multisig, token, sender, recipient)across envelopes, e.g. by mixing a rotation epoch or share counter intoinfo.
The middle path the spec is on today could be a vulnerability.
There was a problem hiding this comment.
Thanks, updated with fresh random 12-byte nonce per envelope.
2 participants
No description provided.