Threat Model – VitalSend (Client-side E2EE)

Version: 2, 2026-06-12

This document describes the threat model, assumptions, and security goals of VitalSend.
It is intended to make security claims explicit, scoped, and reviewable.

This document reflects the current design and may evolve as the system changes.

1. Assets to Protect

• Plaintext file contents
• Encryption keys (symmetric)
• Integrity of transmitted files
• Recipient authenticity (only intended recipients can decrypt)
• Optional extra password (shared out-of-band)

2. Primary Security Goal

Protect file contents against:

• The service operator (including malicious or coerced operation)
• Network adversaries (passive and active)

VitalSend is designed so that the server cannot access plaintext file contents or encryption keys.

3. Adversaries Considered

Service Operator

• Can run arbitrary server-side code
• Can inspect, modify, replay, delay, or drop encrypted data
• Can access all server-side state and infrastructure
• Cannot access plaintext or encryption keys by design

CDN / Edge Proxy (Cloudflare)

• vitalsend.eu is served through Cloudflare, which terminates TLS at its edge
• Traffic between Cloudflare and the origin is re-encrypted over a separate TLS connection; this protects against network adversaries on that path, but does not reduce the trust placed in Cloudflare itself
• Can observe and modify all traffic between browsers and the origin, including the delivered client code
• Treated as part of the untrusted server: everything the service operator is assumed capable of, this layer is too
• Cannot access plaintext file contents or encryption keys by design: files are encrypted on the client before upload, so what transits this layer is E2EE ciphertext carried inside TLS. Terminating TLS exposes the transport, not the file. Neither Cloudflare nor the origin ever holds the link key needed to decrypt
• Traffic that transits this layer in decrypted form includes the optional extra password (sent once for attempt limiting) and, only when the sender requests email delivery of the link, the full link including the key

Network Adversary

• Can observe, intercept, modify, replay, or drop network traffic
• Cannot break standard cryptographic primitives

Malicious Sender or Recipient

• Can upload malformed or malicious encrypted payloads
• Can attempt replay, duplication, or resource-exhaustion attacks

4. Adversaries Explicitly Out of Scope

• Compromised client devices (OS-level malware)
• Compromised browsers or malicious browser extensions
• Modified or malicious client builds
• Hardware attacks or side-channel attacks
• Nation-state endpoint compromise

E2EE guarantees rely on the assumption of an honest client running in a non-compromised browser environment.

5. Trust Assumptions

• Encryption and decryption occur entirely on the client
• Cryptographic primitives are secure as implemented
• Randomness sources used by the client are cryptographically strong
• The server is untrusted for confidentiality, but trusted for availability and message routing
• Users are responsible for endpoint security and recipient verification where applicable

6. Cryptographic Boundaries

• Plaintext exists only in client memory
• Keys are generated, used, and destroyed on the client
• The server processes only encrypted payloads and required metadata
• Encryption keys are not transmitted to the server unless the user chooses to let the server send mail with link and key to the receiver.
• If extra protection is enabled, the password is sent once to store a bcrypt hash for attempt limiting

7. Data Retention and Operational Logging

VitalSend is designed to minimize server-side data retention.

• The server does not store plaintext file contents or encryption keys
• Application-level logging of user data is intentionally avoided
• Only the minimum data required to facilitate upload and download of already encrypted payloads is retained
• Encrypted payloads and routing metadata are stored only for the duration required to complete a transfer
• Password hashes and attempt counters are stored only while the transfer is active
• Infrastructure-level logs (e.g. system, network, or hosting provider logs) may exist outside the application’s control

The absence of server-side logs is an operational policy, not a cryptographic guarantee, and does not change the assumption that the server may be malicious or coerced.

8. Threats Considered and Mitigations

Malicious Server Attempting Content Access

• Mitigation: Client-side encryption; server never receives plaintext or keys

Traffic Interception or Tampering

• Mitigation: Authenticated encryption ensuring confidentiality and integrity

Replay Attacks

• Mitigation: Message identifiers, nonces, or timestamps where applicable
• Accepted risk where replay has no semantic impact (explicitly documented)

Protocol Downgrade / Rollback

• Mitigation: Explicit protocol versioning and rejection of unsupported versions

Malformed Encrypted Payloads

• Mitigation: Strict input validation before decryption
• Bounded resource usage to limit denial-of-service impact

Password Guessing or Brute Force

• Mitigation: Server-side attempt limits delete the file after repeated wrong attempts
• Optional passwords must be high entropy; short passwords are rejected client-side

Metadata Leakage

• Accepted: File size, timing, and recipient identifiers may be visible to the server
• Metadata confidentiality is not a goal of the E2EE design

9. Non-Goals

• Protecting against malicious or modified clients
• Protecting against compromised endpoints
• Preventing user error (wrong recipient, lost keys)
• Hiding communication patterns or access metadata
• Guaranteeing availability or resistance to denial-of-service

10. Security Claims (Precise)

VitalSend provides end-to-end encryption that protects file contents against the service operator and network adversaries, assuming an honest client running in a non-compromised browser environment.

11. Review and Disclosure

• This threat model documents intended security properties and limitations
• The client-side encryption implementation is published at github.com/vitalsend/crypto and is in scope for review and disclosure
• Vulnerability reports should be sent through the documented disclosure channel
• Security claims are limited to the scope described in this document