Trust & Security
EDH is designed so that you do not have to trust anyone — not the storage provider, not the network operator, not even Ever. Security is enforced by architecture and mathematics, not by policy or promises.
Zero-Trust Architecture
Every layer of EDH is built on the principle that no single party — including the infrastructure operator — can access your health data.
| Layer | How It Works |
|---|---|
| Encryption | All data is encrypted on your device before it leaves. The server only ever sees ciphertext. |
| Key Management | Your keys are derived locally from your password and never transmitted. We do not hold them, escrow them, or have a backdoor to recover them. |
| Storage | Files are stored on content-addressed decentralized storage. The storage layer cannot read what it stores. |
| Identity | Your account is a smart contract on a public blockchain. No central authority issues or revokes your identity. |
| Access Control | Sharing permissions are enforced by smart contracts and cryptographic key exchange — not by server-side access control lists that an admin could override. |
| Audit Trail | Access logs are Merkle-anchored on-chain. They cannot be tampered with, deleted, or silently modified. |
Technology Agnosticism
EDH is not married to any single blockchain or storage network. The architecture is designed around open standards and protocols, not specific vendors:
| Component | Current Implementation | Can Be Replaced With |
|---|---|---|
| Blockchain | Any EVM-compatible chain | Any chain supporting smart contracts and meta-transactions |
| Decentralized Storage | IPFS, S3-compatible (Filebase) | Arweave, Filecoin, Sia, or any content-addressed storage |
| Encryption | NaCl (TweetNaCl) | Any authenticated encryption scheme with equivalent security properties |
| Identity | Wallet-based + did:bio | Any DID method with biometric binding |
What matters is not the specific technology, but the properties it guarantees: client-side encryption, content-addressed storage, permissionless identity, and on-chain auditability. If a better protocol emerges tomorrow, EDH can adopt it without changing the trust model.
Two Editions, Same Cryptography
EDH exists in two editions. The cryptographic core — the part that protects your data — is identical in both.
| Feature | EDH Open Source | Ever Healthcare |
|---|---|---|
| Encryption | Identical | Identical |
| Smart contracts | Identical | Identical |
| Key management | Identical | Identical |
| Access log anchoring | Identical | Identical |
| AI health insights | Not included | Included |
| Gamification | Not included | Included |
| Telehealth | Not included | Included |
The open-source edition exists so that anyone — security researchers, hospitals, regulators, patients — can independently verify that the encryption works as documented. The proprietary features (AI, telehealth, gamification) are application-layer additions that never touch the cryptographic pipeline.
Cryptographic Guarantees
| Property | Mechanism |
|---|---|
| Confidentiality | NaCl Box (Curve25519 + XSalsa20-Poly1305) — server never sees plaintext |
| Integrity | SHA-256 digest on every file chunk — any modification is detectable |
| Authentication | NaCl Box provides authenticated encryption — forged ciphertext is rejected |
| Non-repudiation | Merkle-anchored access logs on-chain — provable record of who accessed what |
| Forward secrecy | Key rotation with re-encryption — compromising a current key does not expose past data |
How to Verify
You do not have to take our word for any of this. Every claim above is independently verifiable.
1. Same Contract Addresses
Both editions deploy to the same on-chain smart contracts:
ever status
# Shows deployed contract addresses — compare with Ever Healthcare's published addresses
2. Deterministic Encryption
Given identical inputs, both editions produce identical ciphertext:
npm run test:all -- --grep "deterministic"
3. Merkle Root Verification
Access logs produce the same Merkle roots regardless of which edition wrote them:
ever wallet verify
# Fetches logs, rebuilds tree, compares with on-chain anchor
4. Reproducible Builds
git clone https://github.com/ever-network/edh-central.git
cd edh-central
npm run edh setup
npm run contract:compile
# Compare bytecode with on-chain deployment
5. Key Derivation
import { deriveAccountSecrets } from '@ever-healthcare/ever-edh-core';
const { encryptionKeyPair } = await deriveAccountSecrets(yourSeed);
// Compare publicKey with what's registered on-chain
What We Do Not Guarantee
Honest security documentation includes honest limitations:
- Availability: Depends on storage network uptime. If every storage node goes offline, your encrypted data is temporarily unreachable (but not lost — it can be re-pinned from any backup).
- Metadata privacy: On-chain transactions are public. When you registered, when you added a device, and the structure of your sharing permissions are visible — though the content of your data is not.
- Endpoint security: If your device is compromised (malware, physical access), encryption cannot protect data that is already decrypted in memory. Use device-level security (screen lock, full-disk encryption) as your first line of defense.
- Quantum resistance: Current encryption (Curve25519, XSalsa20) is not quantum-resistant. When post-quantum cryptography matures, EDH will migrate. The architecture supports algorithm rotation by design.
Data Policy
We do not use your health data. We do not sell your health data. We do not aggregate your health data. We are architecturally incapable of reading your health data.
This is not a policy choice that could be reversed by a new CEO or a change in business model. It is a consequence of the encryption architecture: your data is encrypted with keys we do not possess. There is no server-side switch to flip, no admin panel to access, no database query that returns plaintext.
If Ever were acquired, subpoenaed, or breached, the attacker would find encrypted blobs that are computationally worthless without your keys. This is the difference between a privacy policy and a privacy architecture.