Hybrid key establishment
ML-KEM-768 and an ephemeral P-256 ECDH exchange produce independent shared secrets. A domain-separated derivation binds them to the intended vault, devices, trusted-device-list version, object, algorithm suite, and purpose.
MystSafe overview
Cryptographic architecture
Beta architecture — coming soon
Hybrid protection, verified by every device.
MystSafe treats cloud storage as a transport layer, not as a trusted vault. Every device creates its own independent encryption and signing keys, encrypts secret payloads locally, and verifies what it receives before accepting an update.
This page describes the current beta architecture reflected in the app solution. Protocol details and algorithm-suite identifiers are versioned so clients can reject unsupported or altered data as the design evolves.
Post-quantum layerLattice-based protection
Classical layerEstablished cryptography
One authenticated envelopeEncrypted device-to-device update
Two independent cryptographic paths
Post-quantum and classical protection work together.
Classical cryptography is not a fallback. Key establishment combines both shared-secret paths, and security-sensitive envelopes require both signature paths to verify.
Current beta cipher suite
- Key establishment
- ML-KEM-768 + P-256 ECDH
- Digital signatures
- ML-DSA-65 + ECDSA P-256
- Payload encryption
- AES-256-GCM
- Protocol hashing
- SHA3-256
Hybrid authentication
ML-DSA-65 and ECDSA P-256 sign the same canonical security context. Verification requires both signatures and the expected device key identities.
Authenticated encryption
AES-256-GCM protects payloads and wrapped content keys with fresh nonces and authenticated context. SHA3-256 commits to protocol content and key identities.
Encrypted update lifecycle
Storage carries the envelope. Devices decide whether to trust it.
An update is more than ciphertext. It is a versioned, signed object with enough bound context for a receiving device to detect substitution, replay, tampering, and unauthorized senders.
- 1
Create local keys
Each device generates independent ML-KEM, P-256 ECDH, ML-DSA, and ECDSA identities. Existing private device keys are not transferred to a new device.
- 2
Encrypt for an active recipient
The sender creates a fresh 256-bit content key, encrypts the payload, and protects that key specifically for another Active trusted device through both key-establishment paths.
- 3
Bind and sign the envelope
The envelope identifies its protocol and suite, vault, exact object path and type, signer, trusted-device-list version, timestamps, encryption details, and payload hash.
- 4
Publish ciphertext, not vault keys
The chosen storage provider receives the signed encrypted object. It does not receive the private device keys required to unwrap its secret payload.
- 5
Verify before decrypting
The recipient checks the expected path and vault, supported suite, active signer, expiration, payload hash, and both signatures. A failed check rejects the object.
Trust boundaries
Clear claims. Clear limits.
MystSafe is designed to reduce centralized trust without pretending that cryptography makes every surrounding system invisible.
Protected by the protocol
Secret payloads and private device keys
- Secret contents are encrypted before provider storage.
- Content keys are wrapped for individual Active devices.
- Unexpected, expired, altered, or unauthorized envelopes are rejected.
- Pairing creates a short-lived, transcript-bound session and does not introduce a vault master key.
Not an anonymity claim
Provider and protocol metadata
- A storage provider can observe its account identity, IP addresses, timing, object sizes, counts, and access patterns.
- Some signed routing, manifest, and trust metadata is intentionally not secret.
- Deletion from a provider cannot prove that previously downloaded ciphertext was erased everywhere.
- The current beta architecture is not presented as formally verified or independently audited.
Device-bound access
Your device protects the keys that protect your vault.
On supported Apple release builds, a random device-storage key is protected with device-only Keychain policy and local user presence. Face ID, Touch ID, a device passcode, or macOS authentication authorizes the operating system to release protected key material; biometrics are not used as cryptographic keys.
Post-quantum private keys are software-protected beneath that device security layer. MystSafe does not claim they are natively hardware-backed.
Want to help test the beta architecture?
Join the early-access list or send the MystSafe team a security question.