End-to-End Encrypted File Sharing: Architecture, Security and Sovereignty

THEMIOT Informatique / Version 1.1 / August 2026

1. Executive Summary

PrivCloud is a European platform for secure file sharing, encrypted collaborative workspaces, and electronic signatures, developed and operated by THEMIOT Informatique, an independent French company specializing in cybersecurity and systems architecture. It rests on three inseparable pillars: end-to-end encryption with quantum-threat-resistant mechanisms, zero-knowledge architecture, and hardened sovereign infrastructure.

In a context marked by intensifying cyber threats, growing geopolitical tensions, the strengthening European regulatory framework (GDPR, NIS2, DORA), and awareness of risks linked to American extraterritorial legislation (Cloud Act, FISA), organizations need solutions whose confidentiality rests on cryptographic guarantees, not merely contractual commitments.

By design, PrivCloud makes any access to plaintext content impossible, including by its own operators. Files are encrypted locally on the user's device before any upload to our servers. Only authorized recipients have decryption keys. The infrastructure itself is deployed on a hardened environment, segmented into isolated VLANs, protected by five security layers, and monitored in real time.

2. The Challenge: Protecting Sensitive Data in a Hostile Digital World

2.1 A Strengthening European Regulatory Framework

The General Data Protection Regulation (GDPR, 2016/679) has imposed strict obligations on personal data processing since 2018. Compliance is no longer optional: penalties can reach 4% of annual global turnover.

• NIS2 (Network and Information Security Directive, 2022): extends cybersecurity obligations to many sectors.
• DORA (Digital Operational Resilience Act, 2022): imposes digital resilience requirements for the financial sector.
• Professional secrecy (lawyers, accountants, physicians): deontological obligation reinforced by disciplinary and legal sanction risks.

2.2 The Real Threat to File Transfers

• Data exposed on provider servers: mainstream sharing platforms encrypt data in transit (HTTPS/TLS) and sometimes at rest, but retain decryption keys. Unauthorized server access, legal requisitions, or data breaches expose your content entirely.
• Exposure to extraterritorial legislation: providers hosted by American companies (even when data centers are physically in the EU) are subject to the Cloud Act (2018) and FISA, which authorize US authorities to access data without necessarily informing affected individuals.
• Lack of traceability: informal solutions (email, instant messaging) provide no access audit trail and no rights revocation after sending.
• Future threats to current data: the "harvest now, decrypt later" strategy involves capturing encrypted data today in anticipation of hardware advances (particularly quantum computers) that could enable decryption in the coming years.

2.3 The Limits of Contractual Approaches

A contractual commitment can frame usage. It does not eliminate the technical possibility of accessing the data. The most robust protection rests on the cryptographic architecture itself: when content is encrypted client-side and decryption keys are not accessible to the provider, confidentiality no longer depends on a promise, an internal procedure, or a contractual framework. It rests on a verifiable technical constraint.

3. Technical Architecture and Security Model

3.1 Fundamental Principle

The architecture of PrivCloud is designed to prevent any operator access to plaintext content, including by the service publisher. This is not a matter of trust in our teams or the robustness of our internal policies. It is a cryptographic constraint imposed by our architecture: the decryption keys for your content never transit through our servers and are never accessible to our infrastructure.

3.2 Encryption Flow

1. The file is encrypted locally in the browser with AES-256-GCM. The encryption key is generated locally and is never transmitted to the server.
2. The encrypted file is sent in adaptive 6-50 MB chunks. The server preinitializes multipart state and authorizes each part, the browser page shares a bounded 12-request window across two S3 origins. We only see unreadable data.
3. The recipient receives a link containing the key in the URL fragment (after the # character), which is never sent to the server by the browser.
4. The recipient downloads the encrypted file through ordered S3 ranges and decrypts it locally. A dropped connection resumes at the exact byte when the browser supports streamed disk writes.

3.3 What We Can and Cannot See

4. End-to-End Encryption with Post-Quantum Mechanisms

4.1 Three Levels of Protection

4.2 Cryptographic Primitives

4.3 Hybrid Post-Quantum Scheme for Teams

For team collaborative workspaces, PrivCloud uses a hybrid scheme combining X25519 and ML-KEM-768. The file encryption key (DEK) is wrapped for each authorized recipient with their public key pair. Team notifications are also end-to-end encrypted with this mechanism: no metadata (sender name, file name, folder context) is visible to the server.

This hybrid approach protects against two scenarios: a mathematical breakthrough against elliptic curves (X25519), and a weakness discovered in ML-KEM-768. Both mechanisms must be compromised simultaneously to break confidentiality.

4.4 Key Management and Rotation

• The master key is generated locally on first upload and stored in the browser's sessionStorage (survives page reload, cleared on browser close).
• The team key is generated by the owner and wrapped with their personal master key. Each member receives the key wrapped with their own master key.
• Team key rotation atomically invalidates other members' copies via Prisma transaction.
• Full re-encryption available: download with old key, re-encrypt with new key, re-upload in chunks. Integrated WAF protection with exponential backoff.

5. Zero-Knowledge Architecture: Privacy by Design

A zero-knowledge architecture means that the service provider has no knowledge of the content of the data it processes. This property is guaranteed by cryptographic construction.

• We lack the elements to access plaintext file content.
• Encryption keys never transit through our servers (they reside in the URL fragment, not transmitted to the server).
• Team notifications are end-to-end encrypted: neither the sender name nor the file name are visible to the server.
• If a user loses their master key, we cannot recover it or decrypt associated data.

Compliance Implications

• GDPR: encrypted data for which we do not possess the keys is inaccessible to us in plaintext. We cannot exploit it for unauthorized purposes.
• Professional secrecy: the zero-knowledge architecture provides cryptographic reinforcement that we cannot circumvent.
• Legal requisitions: in case of access request by an authority, we can only deliver unreadable encrypted data and connection logs.

6. Sovereign and Hardened Infrastructure

6.1 European Infrastructure and Storage

Application infrastructure operated in France, E2EE content stored in France, with a backup replica in the European Union (Germany).

6.2 Tracked Security Measures

6.3 Defense in Depth (5 Layers)

The infrastructure rests on 12 isolated VLANs, a default DROP policy on all machines (INPUT/FORWARD/OUTPUT), and Zero Trust SSH access (Ed25519 key + 80-character passphrase + 2FA).

6.4 Data Residency and Key Control

PrivCloud's application infrastructure is operated in France. E2EE content is stored in France with a backup replica in Germany. European data residency alone does not determine every jurisdiction that may apply to a provider. The zero-knowledge model reduces this exposure: object storage receives encrypted content without its decryption key.

7. Features

7.1 Secure File Sharing

• Client-side AES-256-GCM encryption before any upload
• Preinitialized, resilient upload with fair server-side allocation
• Parallel ordered-range downloads with byte-accurate resume
• Configurable expiration, password protection, download limits
• E2E reverse shares: encrypted file reception from third parties
• Download notifications (instant push + email)
• E2E video preview (up to 100 MB) and source code with syntax highlighting
• Maximum size depends on the plan, no application-level format restriction beyond security controls

7.2 Collaborative Team Workspaces

• E2E encryption with hybrid post-quantum keys (X25519 + ML-KEM-768)
• Cryptographic grants (AccessGrant) per recipient
• E2E encrypted notifications (zero metadata leak)
• Granular roles: OWNER, ADMIN, MEMBER
• Per-folder permissions (canDownload, canDelete) and per-file (READ/WRITE/ADMIN/DENY)
• Dynamic storage pool: 500 GB + 100 GB per additional member
• Instant cryptographic revocation when removing a member

7.3 Electronic Signature

• Electronic signatures: explicit consent, level-specific controls, document binding, audit trail and evidence retention
• Standard level with mandatory email OTP, reinforced level with an assigned account and transaction-bound passkey, without claiming qualified civil identity
• PAdES-B-T PDF sealing: only the signature imprint is submitted to the RFC 3161 TSA, the response is cryptographically validated before its token is embedded in the PDF
• Multi-signer workflow: SIGNER, APPROVER, CC
• Standard signing tokens for external signatories (no account required)
• E2E support: documents encrypted during the signing workflow
• SHA-256 hash-chained audit trail and automatic evidence page
• QES not included, future extension through a qualified provider and Cloud Signature Consortium (CSC) interface

7.4 Connectors, PrivCloud Companion and Native App

• WebDAV import from Nextcloud, ownCloud and compatible NAS, directly from the browser when CORS is allowed
• Local PrivCloud Companion to avoid CORS limits: remote cloud -> user device -> encrypted PrivCloud upload
• Native Android app: dedicated authentication, built-in WebDAV connector and encrypted transfers handled on the device
• Short-lived Bridge tokens scoped to the current share for managed imports
• Unsigned beta artifacts for Linux (.deb/.rpm/portable), Windows, macOS, browser extension, Thunderbird, Outlook and Google Workspace
• Signed publication and store review are planned, no official store status is claimed in this version

8. Operational Transparency

• Open source code: open source project under BSD 2-Clause license. Complete code (backend + frontend) available on GitHub for audit.
• Vulnerability management: hardened dependency tree, regular audits with npm audit, Snyk and image scans, targeted overrides and runtime dependency reduction where possible.
• Zero AI policy: no artificial intelligence in the product. Your files do not serve to train models. We cannot analyze what we cannot read.
• Secure pipeline: private GitLab CI/CD, Renovate for automatic updates, progressive TypeScript strict mode, minimal Alpine Docker images.

9. Use Cases

10. Plans and Deployment

11. Conclusion

Facing growing cybersecurity, independence, and regulatory compliance challenges, European organizations need file sharing solutions that offer superior security and do not rely solely on contractual commitments. PrivCloud delivers this guarantee by combining:

• End-to-end encryption: your files are unreadable on our servers, today and against future threats (hybrid scheme X25519 + ML-KEM-768).
• Zero-knowledge architecture: without decryption keys, we cannot access your content. Notifications themselves are encrypted.
• Hardened sovereign infrastructure: French hosting, network segmentation, restrictive policies, monitoring and defense in depth.
• Integrated electronic signature: standard email-OTP and reinforced account/passkey evidence with native E2E encryption, future QES through a qualified provider and CSC.
• Transparency: open and auditable source code, active vulnerability management, zero AI policy.

Contact

THEMIOT Informatique

• Website : www.stprive.net
• Contact : simon.themiot@informatiquenevers.fr
• Source code : github.com/Simthem/PrivCloud_Sharing

This document is provided for informational purposes. The information it contains reflects the state of the platform at the time of writing. THEMIOT Informatique reserves the right to evolve its architecture and features.

- THEMIOT Informatique, June 2026