Security Whitepaper & Threat Model
ShareMySecret protects secrets — crypto seed phrases, passwords, vital documents — by encrypting them on-device and splitting the encryption key among people you trust, so that no single person, device or failure can expose or lose them.
This document describes the cryptographic design, the threat model, and — just as importantly — what the app does not protect against.
1. Zero-knowledge by construction
- All cryptography happens on your device. Secrets, encryption keys and key shares are generated and processed locally.
- No secret material ever reaches our servers. The only network calls the app makes are App Store purchase verification and anonymized crash reporting; both are scrubbed of any secret content, keys or IVs.
- We could not read your secrets even if compelled to. There is no account, no cloud copy, and no recovery backdoor.
2. Cryptographic design
2.1 Encryption
| Property | Value |
|---|---|
| Cipher | AES-256 in CBC mode |
| Key | 256-bit, generated with the platform CSPRNG (Random.secure()) |
| IV | Random per encryption, stored alongside the ciphertext |
The secret content (text and/or files) is packaged into a ZIP archive and encrypted with a fresh, random AES-256 key.
2.2 Key splitting — Shamir's Secret Sharing
The AES key is split using Shamir's Secret Sharing over GF(256):
- A random polynomial of degree
threshold − 1is generated per key byte, with the key byte as the constant term. - Each recipient receives one share — a distinct point on the polynomial — packaged as a
.sharemysecretfile together with the encrypted archive. - Any
thresholdshares reconstruct the key via Lagrange interpolation; fewer thanthresholdshares reveal mathematically nothing about the key (information-theoretic security, not merely computational).
This is the same scheme used by Trezor's Shamir Backup (SLIP-39) and enterprise key-escrow systems.
2.3 Randomness
All cryptographic material (keys, IVs, polynomial coefficients) is generated with Random.secure(), which delegates to the operating system's CSPRNG.
3. Threat model
What ShareMySecret protects against
| Threat | Mitigation |
|---|---|
| A single trusted person leaks their share | Fewer than threshold shares reveal nothing |
| A share is lost or destroyed | Any threshold of n shares recovers the secret |
| Server breach / subpoena of our infrastructure | No secret material exists server-side |
| Interception of one share in transit | One share is useless below the threshold |
| Death or incapacity of the owner | Recipients can combine their shares independently |
What ShareMySecret does NOT protect against
Honesty here matters more than marketing.
- A compromised device. If malware can read your screen or storage while you create or decrypt a secret, no cryptography helps.
- Collusion of
thresholdor more recipients. Choose your trustees and threshold accordingly. - Losing more than
n − thresholdshares. The secret is then unrecoverable — by design, there is no backdoor. - Weak operational choices, e.g. sending all shares to the same person or over the same compromised channel.
4. Data handling
- Local storage: secrets are stored in the app sandbox; deleted secrets are overwritten with random data before deletion (multi-pass).
- Logging & crash reports: a centralized logger redacts keys, secrets, receipts and IVs before anything leaves the device; secret content is never logged.
- Analytics: only purchase-funnel events (e.g. "paywall viewed") are recorded — never secret content, names of secrets, or recipient identities.
5. Verifiability
The cryptographic core of ShareMySecret (Shamir scheme, GF(256) arithmetic, Lagrange interpolation, AES wrapper) ships with a public test suite and is maintained in the open so its claims can be independently audited.
Found a vulnerability? Please report it responsibly: security@sharemysecret.app
Protect your first secret free →
This document is updated with every release that changes security-relevant behavior. Last reviewed: June 2026.