Security

Built so your files are encrypted before they ever leave your browser.

Proofix uses client-side AES-256 encryption, Swiss data residency, and a cryptographically signed proof of delivery. This page explains exactly how it works, and where the limits are.

file encryption
AES-256
in transit
TLS 1.3
data residency
Swiss
proof retention
Indef.

The three pillars

Client-side encryption

Your file is encrypted in the browser with AES-256-GCM before upload. With link-only sharing, the decryption key never reaches our servers.

Swiss-hosted

Data stays in Switzerland on infrastructure protected by one of the strongest data protection laws in the world.

Signed proof of delivery

Proof-tier transfers include a signed timestamp token and a signed canonical hash, useful as supporting evidence of delivery.

How encryption works

When you attach a file, Proofix generates a fresh random AES-256 key in your browser. The file is encrypted locally using AES-256-GCM (authenticated encryption). Only the ciphertext is uploaded to our Swiss object storage.

The recipient receives a link containing the AES key in the URL fragment (the part after #). Browsers do not transmit URL fragments to servers, so on the link-only sharing path the key stays between you and your recipient.

Important limit:if you ask us to email the link to your recipient, our server briefly composes that email and therefore briefly sees the full URL including the fragment. This path is not strict zero-knowledge. Choose “I’ll share the link myself” for strict key separation.

  1. 1

    Generate key (browser)

    256-bit random key via WebCrypto subtle API.

  2. 2

    Encrypt (browser)

    AES-256-GCM with a fresh 96-bit IV. The ciphertext is authenticated.

  3. 3

    Upload (server)

    Ciphertext streamed to S3-compatible storage in Switzerland.

  4. 4

    Share (client or server email)

    Link-only: key stays in the URL fragment, never sent to our servers. Email delivery: server briefly composes the email and sees the full URL.

  5. 5

    Decrypt (browser)

    Recipient downloads ciphertext, decrypts locally, and verifies the SHA-256 hash.

Password-protected transfers

Optionally, the AES key itself is wrapped with a password-derived key using PBKDF2-HMAC-SHA256 (100,000 iterations) and AES-KW. The wrapped key blob is stored alongside the ciphertext. Without the password, the wrapped blob cannot be unwrapped: we cannot decrypt the file server-side. Note that this is PBKDF2-based password wrapping, not pure zero-knowledge — a weak password reduces effective protection.

The proof (proof tier only)

For the proof tier, we build a canonical string — a pipe-delimited record of the transfer ID, sender, recipient, file hash, file name, size, timestamps, download limit, and verification ID — prefixed with PROOFIX-V1 for versioning. We hash that with SHA-256 and submit the hash to an internal Swiss-hosted time-stamping service that signs the imprint.

The signed token we receive back demonstrates that the hash — and therefore every field in the transfer — existed at a specific moment. Proof records are retained indefinitely for legal reference.

Scope note: the current time-stamping service is an internal, Proofix-operated signer. Integration with a third-party RFC 3161 Time-Stamping Authority under a public certificate chain is on our roadmap.

Data we handle

Encryption at rest
AES-256 (server-side, redundant to client-side E2EE)
Encryption in transit
TLS 1.3 only
File cipher
AES-256-GCM, 96-bit IV, fresh per file
Key derivation (password)
PBKDF2-HMAC-SHA256, 100,000 iterations, 16-byte salt
Key wrapping
AES Key Wrap (RFC 3394)
Integrity
SHA-256 hash of plaintext compared after decryption
Timestamping
Internal Swiss-hosted signer; SHA-256 imprint (public RFC 3161 TSA on roadmap)
Session tokens
SHA-256 of UUID stored server-side; raw token only in HttpOnly cookie
IP and User-Agent
HMAC-SHA256 (peppered with HMAC_SECRET); raw values never stored, leaked logs cannot be rainbow-tabled

Operational security

  • Least-privilege access to production; no shared credentials.
  • All requests carry a correlation ID for audit tracing.
  • Structured JSON logs, sensitive values scrubbed before write.
  • Daily encrypted backups; blob lifecycle enforced by scheduled worker.
  • Content Security Policy with strict origins, no inline scripts.
  • HttpOnly, Secure, SameSite=Strict cookies for sessions.
  • Dependencies pinned; supply-chain reviewed on every release.

Compliance

  • EU General Data Protection Regulation (GDPR, 2016/679).
  • Swiss Federal Act on Data Protection (revFADP / nDSG, 2023).
  • Operational controls informed by ISO/IEC 27001 guidance. Proofix is not ISO 27001 certified.
  • Swiss Code of Obligations — 10-year retention for payment documents.
  • No SOC 2, HIPAA, or equivalent third-party certification is currently held.

Responsible disclosure

If you believe you’ve found a security issue, please email info@proofix.ch. We commit to acknowledging reports within 48 hours, providing a status update within 7 days, and coordinating a fix and disclosure timeline with you. Good-faith security research is welcome and will not be met with legal action.

Questions

For architectural questions and enterprise security reviews, email info@proofix.ch. For data protection topics, see the Privacy policy.