End-to-End Encryption Framework

1. Abstract

Project Evan implements a layered end-to-end encryption (E2EE) framework that ensures messages, plan content, and optional calendar data can only be decrypted by the intended recipient devices. Project Evan's servers act as a blind relay: they route and store ciphertext but possess no cryptographic material that would allow them to decrypt user content, even under legal compulsion or in the event of a server-side breach.

This document describes the key-agreement protocols, symmetric encryption schemes, group key distribution mechanism, and key-recovery strategy employed by Project Evan. It is intended for security researchers, independent auditors, and technically informed users who wish to verify our security claims independently.

2. Threat Model

2.1 Adversaries we protect against

• Network attacker: passive eavesdropper or active man-in-the-middle on the transport layer. All API traffic uses TLS 1.3 with certificate pinning in the mobile client. Even if TLS were broken, the encrypted payload remains opaque.
• Compromised server: a Project Evan server operator, rogue employee, or attacker who gains full read access to server-side databases and message queues. Servers store only ciphertext; no private key material is ever uploaded.
• Legal compulsion: a government order compelling Project Evan to produce message content. Because the server does not hold decryption keys, compliance with such an order cannot yield plaintext message content.
• Metadata analysis: an adversary studying communication patterns. We acknowledge metadata (who communicates with whom, and when) is visible to the server. Mitigations include sealed-sender envelopes and padding.

2.2 Adversaries outside scope

• Compromised device: if an attacker has physical or software-level access to a user's unlocked device, they can read decrypted content. Device security is the user's responsibility.
• Compromised recipient: if a message recipient intentionally forwards or screenshots content, E2EE cannot prevent disclosure.
• Rubber-hose cryptanalysis: physical coercion of key holders is outside our technical scope.

3. Cryptographic Primitives

4. Identity & Device Keys

Each Project Evan user has a long-term identity key pair generated locally on first account creation:

• IK_pub / IK_priv: Ed25519 signing key pair. The public key is published to the Project Evan key server and signed by the user's device attestation.

Each enrolled device additionally generates:

• SPK: a signed pre-key (X25519), rotated every 30 days, signed by IK_priv.
• OPK_1..n: a batch of one-time pre-keys (X25519, typically 100 per batch) uploaded to the key server. Each OPK is consumed in exactly one key agreement and then discarded, providing forward secrecy at session establishment.

Private keys never leave the device. The key server holds only public components: IK_pub, SPK_pub (with signature), and the available OPK_pub pool.

5. Initial Key Agreement (Extended Triple Diffie-Hellman)

When Alice sends the first message to Bob, Project Evan uses the X3DH protocol (Signal Protocol specification) to establish a shared secret:

1. Alice fetches Bob's key bundle from the server: IK_B, SPK_B, one OPK_B.
2. Alice generates an ephemeral key pair EK_A.
3. Alice computes four Diffie-Hellman outputs:
   • DH1 = DH(IK_A, SPK_B)
   • DH2 = DH(EK_A, IK_B)
   • DH3 = DH(EK_A, SPK_B)
   • DH4 = DH(EK_A, OPK_B) (if OPK is available)
4. A master secret is derived: SK = HKDF(DH1 || DH2 || DH3 || DH4)
5. Alice deletes EK_A_priv immediately after deriving SK.
6. The initial message is encrypted using the symmetric keys derived from SK and sent along with IK_A_pub, EK_A_pub, and the OPK identifier used.

Bob, upon receiving the initial message, re-derives SK from the same inputs and discards OPK_B_priv. The OPK is never reused.

6. Double Ratchet Messaging

After session establishment, all messages use the Double Ratchet Algorithm, combining a Diffie-Hellman ratchet for forward secrecy and break-in recovery with a symmetric key ratchet for per-message key derivation:

6.1 Diffie-Hellman Ratchet

Each message round-trip advances the DH ratchet: the sender generates a new ephemeral ratchet key pair, performs a DH exchange with the recipient's ratchet public key, and derives new root and chain keys via HKDF. This ensures that compromise of a ratchet key cannot decrypt past messages.

6.2 Symmetric Key Ratchet

Within a sending chain, each message consumes one message key derived from the chain key. Message keys are derived as:

MK_n  = HKDF(CK_n, info="message_key")
CK_n+1 = HKDF(CK_n, info="chain_key")

Message keys are deleted immediately after use (encryption or decryption). A bounded window of out-of-order message keys may be cached, then discarded.

6.3 Message Format

Each encrypted message envelope contains:

• Ratchet public key for this step
• Previous chain message count (for out-of-order handling)
• Current chain message counter
• AES-256-GCM ciphertext + authentication tag (96-bit random nonce per message)

7. Plan Content Sealing

Plans (title, description, location, date/time, notes) are treated as structured documents sealed with a plan content key:

1. At plan creation, a random 256-bit Plan Content Key (PCK) is generated on the creator's device.
2. Plan content is encrypted with AES-256-GCM(PCK, plaintext).
3. The PCK is distributed to attendees using the Double Ratchet sessions established with each attendee (see Section 8).
4. The server stores only the ciphertext blob and the plan's public metadata (attendee list pseudonyms, encrypted event time bucket).

8. Group Plan Key Distribution

For multi-participant plans, Project Evan uses a Sender Keys mechanism (analogous to Signal's group messaging protocol):

1. The plan creator generates a Sender Key Record containing a random chain key and a signing key pair.
2. The Sender Key Record is distributed to each participant by encrypting it individually with each participant's established Double Ratchet session key.
3. Subsequent plan content updates are encrypted once with the sender key's current chain state and distributed as a single ciphertext, rather than encrypting separately for each participant — reducing server-side traffic analysis exposure.
4. When a participant leaves a plan, a new Sender Key is generated and distributed to remaining participants. The departing participant cannot decrypt future updates (post-compromise plan security).

9. Calendar Data Encryption

When a user connects an external calendar, the OAuth token references (access token and refresh token references) are stored in a KMS (Key Management Service) under per-user envelope encryption:

• Each user's calendar data is encrypted with a unique Calendar Data Key (CDK) derived via HKDF from a KMS-managed root key and the user's identifier.
• Availability signals extracted for recommendation purposes are stored as binary busy/free vectors — no event titles, descriptions, or attendee data are persisted on the recommendation path.
• KMS keys are hardware-backed where infrastructure supports it (HSM-backed key material). Key access is logged and auditable.

10. Key Backup & Recovery

Because Project Evan holds no private keys, users must have a recovery mechanism to restore access to their encrypted history on new devices:

10.1 Recovery Key

During onboarding, users are prompted to save a Recovery Key: a 128-bit random secret encoded as a 24-word BIP-39 mnemonic. This key is never transmitted to Project Evan and is the user's sole responsibility.

10.2 Encrypted Key Backup

The device's identity key, signed pre-keys, and ratchet state are serialised, encrypted with AES-256-GCM using a key derived from the Recovery Key via Argon2id, and uploaded as an opaque blob to Project Evan's key backup service. Project Evan cannot decrypt this blob.

Argon2id parameters: m=64 MiB, t=3 iterations, p=4 lanes. These parameters are stored alongside the ciphertext to allow future upgrades.

10.3 Multi-Device Sync

Linking a new device requires either scanning a QR code from an existing active device (which transfers keys over an authenticated, ephemeral E2EE channel) or entering the Recovery Key mnemonic and decrypting the key backup blob.

11. Server Trust Model

Project Evan servers are honest-but-curious in the protocol model: they correctly route messages but are assumed to log and inspect everything they receive. Our protocol is designed so that this does not compromise content privacy:

• Servers receive only ciphertext payloads and encrypted key bundles.
• Servers do not participate in key agreement and do not hold private keys.
• Servers cannot inject forged messages without detection, because messages are authenticated under the sender's ratchet signing key.
• Key server responses (public key bundles) are signed by user identity keys; a client can detect if the server substituted a different key (a key substitution attack).

12. Forward Secrecy & Break-In Recovery

Forward secrecy ensures that compromise of long-term keys does not expose past messages. Achieved by:

• Ephemeral keys in X3DH, deleted immediately after session establishment.
• Per-message keys derived by the symmetric ratchet, deleted after use.
• DH ratchet key advancement on every reply, ensuring a key compromise only exposes a bounded window of messages.

Break-in recovery (post-compromise security) ensures that after a compromise is healed, future messages return to confidentiality. The DH ratchet provides this: once a compromised device generates a new ratchet key pair and exchanges it with the other party, the attacker — even holding the previously compromised chain keys — cannot derive future message keys without the new DH output.

13. External Audit Commitment

Project Evan is committed to subjecting this encryption framework to independent third-party security audits before reaching 10,000 active users and on a recurring annual basis thereafter. Audit reports, including finding summaries and remediation status, will be published at projectevan.app/security-audits.

We welcome responsible disclosure of security vulnerabilities. Please report findings to security@projectevan.app. We operate a coordinated disclosure programme with a 90-day remediation window before public disclosure.

14. Known Limitations

• Metadata: the server can observe communication patterns (who talks to whom and when), though not content. Sealed-sender mitigations are planned for v1.1.
• Key verification: users must manually verify safety numbers (key fingerprints) to protect against a key substitution attack at the server. In-app safety number comparison is supported; key transparency logging is targeted for v1.2.
• Backup compromise: if both the encrypted key backup and the Recovery Key mnemonic are compromised, an attacker can restore access to historical messages. Users should store Recovery Keys securely (password manager or offline).
• Device compromise: E2EE cannot protect against a fully compromised operating system or device.

15. References

• Marlinspike, M. & Perrin, T. (2016). The X3DH Key Agreement Protocol. Signal Foundation.
• Marlinspike, M. & Perrin, T. (2016). The Double Ratchet Algorithm. Signal Foundation.
• Perrin, T. & Marlinspike, M. (2016). The Signal Protocol: A Specification.
• Bernstein, D.J. (2006). Curve25519: New Diffie-Hellman Speed Records. LNCS 3958.
• Biryukov, A., Dinu, D. & Khovratovich, D. (2015). Argon2: The Memory-Hard Function for Password Hashing. RFC 9106.
• NIST SP 800-38D: Recommendation for Block Cipher Modes: Galois/Counter Mode (GCM).
• Beurdouche, B. et al. (2020). A Formal Security Analysis of the Signal Messaging Protocol. IEEE EuroS&P.