Data Sharing and Encryption
Zyphe shares data between users and organizations using Proxy Re-Encryption (PRE). The user always encrypts data with their own key. When they choose to share with an organization, a re-encryption key lets a proxy (Zyphe) transform the user's ciphertext into ciphertext that the organization can decrypt, without the proxy ever seeing the plaintext or learning either party's private key.
This page explains how the scheme works in Zyphe, the two key-management models we offer, and what an attacker would actually obtain in the worst-case breach scenario.
How Proxy Re-Encryption Works in Zyphe
Three properties make this safe:
- Plaintext never reaches Zyphe. The proxy only ever handles ciphertext and a transformation key.
- The re-encryption key is one-way and pair-specific. It only converts ciphertext from
userKey → orgKey. It cannot decrypt anything on its own and cannot be inverted to recover either private key. - Sharing is consent-driven. A re-encryption key only exists for an
(identity, document, organization)pair after the user has explicitly granted access. Revoking access removes the key, ending the proxy's ability to transform new requests.
This is the cryptographic mechanism behind every "access grant" referenced in the One-Click KYC and KYC Passport flows.
Key Management: Two Models
The user's private key is the only key that can encrypt data into the vault and produce re-encryption keys. Zyphe supports two ways to manage it, with different trade-offs between user control and convenience.
BYOK with Passkey (Advanced Users)
Bring-your-own-key mode binds the user's private key material to a FIDO2/WebAuthn passkey on the user's device. The key is derived client-side using the WebAuthn PRF extension and never leaves the user's authenticator.
- Custody: the user's device (Secure Enclave, TPM, hardware key) holds the secret. Zyphe has no copy at any point.
- Re-encryption keys: generated locally on the user's device when sharing is granted, then uploaded to Zyphe.
- Recovery: governed entirely by the passkey backup story (platform sync, hardware-key replication, etc.). Losing all passkey copies means losing access; Zyphe cannot recover the vault.
- Best for: users and organizations that require provable cryptographic isolation from Zyphe.
See Passkey Authentication for the registration and authentication flow.
Managed Key with No-Log Paradigm (Default)
For users who prefer a traditional flow, Zyphe generates and operates the key on the user's behalf under a strict no-log paradigm.
- Generation: the key is generated inside an isolated execution context, used to perform the requested operation (encrypting a vault entry, producing a re-encryption key), and discarded.
- No-log guarantee: the key is never persisted to disk, never written to logs, never included in telemetry, and never exposed to other internal services. Only ephemeral, in-memory use is permitted.
- User unlock: the user authenticates with their account credentials (passphrase, Vault Access Key, or other supported method) before any key operation runs.
- Best for: users who want decentralized, end-to-end encrypted storage without managing cryptographic material themselves.
Both models produce the same on-the-wire artefact stored at Zyphe: a re-encryption key. The difference is where the user's private key lives.
What an Attacker Would Get From a Breach
The threat model is explicit: assume Zyphe's infrastructure is fully compromised. What can the attacker actually do with what they find?
| Asset stored at Zyphe | What it is | What an attacker can do with it |
|---|---|---|
| Encrypted vault data | Ciphertext encrypted under the user's public key, sharded across decentralized storage | Nothing. Without the user's private key, the ciphertext is opaque. |
| Re-encryption keys | One-way transformation keys for specific (user → organization) pairs | Nothing on their own. They transform ciphertext between two public keys but cannot decrypt anything and cannot be inverted to recover either private key. |
| User private keys (BYOK) | Not present | N/A (never uploaded). |
| User private keys (Managed) | Not persisted | N/A (generated ephemerally and discarded after use under the no-log paradigm). |
To actually decrypt a user's data, an attacker would need the organization's private key (held by the organization) and the corresponding ciphertext and the re-encryption key. Even then they would only obtain data the user had already explicitly consented to share with that organization.
A breach of Zyphe alone yields encrypted data and re-encryption keys. Neither, separately or together, is sufficient to decrypt anything.
Why This Matters
- No central honeypot. Zyphe physically cannot decrypt user data: there is no master key, no "break-glass" decryption path, and no plaintext cache.
- Granular, revocable sharing. Each shared document corresponds to a distinct re-encryption key. Revocation simply deletes that key; no further requests can be transformed.
- Compliance posture. Because the proxy never sees plaintext, the system aligns with data-minimization principles in GDPR and similar frameworks by construction, not by policy.
- Operational simplicity for organizations. Recipients use standard public-key decryption against ciphertext they receive: no need to integrate with a key escrow or run a decryption service against Zyphe's storage.