Vault Messaging
Overview
Vault Messaging is Unolock’s secure data‑movement system for address‑based exchange. It is not a chat app. Messages move between cryptographic endpoints, not identities. Unlike conventional “private” messengers that stop at content encryption, Vault Messaging minimizes metadata that can be used to construct relationship graphs over time.
- Receive Address: a shareable address with its own keypair and policy controls.
- UnoLock Drop: the anonymous sender client for Receive Addresses.
- Known Addresses: a local address book (saved addresses + names) inside your Safe.
Unolock lets Safe owners create multiple independent Receive Addresses, each acting as a separate compartment for intake. Addresses are isolated from one another and are not tied to identities, inboxes, or accounts. Each address can be configured with its own limits—attachments, usage count, and throttling—so you can control exposure, reduce abuse, and limit correlation. If an address is leaked or abused, it can be disabled or discarded without impacting other addresses.
How It Works
- Address‑based sending: messages and files are sent to a Safe through an address, not to a global identity.
- Client‑side hashing: Receive Addresses are hashed on the client and sent as
vaultxAddressHash. - Per‑address keys: each Receive Address has its own keypair, limiting blast radius.
- Address policies: set usage limits, throttling, and attachment permissions per Receive Address.
- Address authenticity hint: set a sender message (code word) so senders can confirm they reached the intended Receive Address.
- Policy enforcement: limits are enforced server‑side and reflected in the client before send.
- Reply‑only addresses: replies are bound to a specific sender to prevent reuse.
- Anonymous intake: external senders can use the UnoLock Drop client to message a Receive Address without creating a Safe.
Security Implications
- Zero‑knowledge routing: the server routes encrypted payloads and sees only hashed Receive Addresses.
- Post‑quantum ready: messages use ML-KEM-1024 for key encapsulation and AES-256-GCM for payload encryption.
- Compartmentalization: per‑address keys prevent one leaked key from exposing other conversations.
- Metadata hardening: outbox destination addresses are encrypted at rest; receive‑side linkage is hashed.
Use Cases
- Secure coordination: exchange sensitive files and messages between Safes without exposing a global identity.
- Anonymous intake: publish a Receive Address for tips or disclosures via UnoLock Drop.
- One‑off communications: create short‑lived addresses with strict limits for high‑risk interactions.
Why It Matters
Most messaging tools protect content but not anonymity, exposing relationships. Vault Messaging is built to eliminate those relationship graphs by default. By making addresses disposable, policy‑driven, and compartmentalized, you can move messages and files between Safes without building a map of real-world relationships.
Tiering Summary
- Sovereign / HighRisk: create and manage Receive Addresses with policies.
- Free / Inheritance: receive messages and reply using bound reply‑only addresses; cannot create new Receive Addresses.
FAQs
Do senders need a Safe account?
No. The UnoLock Drop client lets anyone send to a Receive Address without creating a Safe. https://drop.unolock.com
Can I revoke a Receive Address?
Yes. You can disable or delete a Receive Address at any time to stop new messages.
Compliance & Privacy Regulations
- GDPR Alignment: Vault Messaging avoids storing raw destination addresses and keeps message contents client‑side encrypted.
Integration with Other Features
- Post‑Quantum Encryption: ML-KEM-1024 + AES-256-GCM protect messages against future cryptographic threats.
- Threat Detection: Runtime monitoring helps detect tampering during sensitive messaging flows.
