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

THEMIOT Informatique / Version 1.2 / October 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, every PrivCloud account encrypts its files end to end by default, and the key is not sent to our servers: neither PrivCloud nor its own operators can access the plaintext content of these files. The key only passes through them if the user chooses to send it by e-mail. 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: by default, the decryption keys for your content do not transit through our servers and are not accessible to our infrastructure. They only do when you choose to send them by e-mail.

3.2 Encryption Flow

1. The file is encrypted locally in the browser with AES-256-GCM. The encryption key is randomly generated in the browser and, by default, is not 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 combines X25519 with ML-KEM-768. The team key, which encrypts the team's files, reaches each member through a link whose fragment is never sent to the server, then each member stores it encrypted with their own master key. When a member shares team files with other members, a copy of this key is wrapped for each recipient with hybrid X25519 + ML-KEM-768. When a team administrator enables it, the details of notifications for file shares, file requests and signatures are encrypted with the same mechanism, otherwise with X25519 alone. The notifications the server writes itself only carry a generic text, without any name.

The hybrid mode 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 what they protect.

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.
• By default, encryption keys do not transit through our servers (they reside in the URL fragment, not transmitted to the server). They only do when the user chooses to send them by e-mail.
• The details of team notifications for file shares, file requests and signatures are end-to-end encrypted. Server-generated team notifications, their push messages and team service e-mails only carry a generic text, without any member, team, folder or file name.
• 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)
• Previews are included in Starter, Pro and Team shares. DOCX and ODT documents, XLSX, XLS/XLT, XLSB and ODS workbooks, PPTX and ODP presentations, and compatible templates and variants. Formatting, colors, tables, merged cells, number formats and compatible images according to the format. Zoom and sheet or slide navigation. CSV, TSV, RTF, flat OpenDocument XML, text and source code with syntax highlighting are also supported.
• Compatible videos, audio and PDFs progressively load the parts they need, including chunked E2E files. XLSX workbooks and PPTX presentations load the required information, then the selected sheet or slide. These previews have no additional total-file-size cutoff. Plan limits and device capabilities still apply.
• Complex files may produce a partial preview. Missing fonts, charts, equations and advanced objects may differ or be omitted. Legacy DOC and PPT require downloading. XLS/XLT, XLSB, SYLK, DIF, Lotus and DBF spreadsheets show saved values in a local preview limited to 16 MiB, 500 rows and 100 columns per sheet. Macros and formulas are never executed. Saved formula results are displayed. Media playback depends on codecs and browser or WebView Service Worker support. Images and legacy single-block E2E files may need to load completely, within device and format limits.
• Maximum size depends on the plan, no application-level format restriction beyond security controls

7.2 Collaborative Team Workspaces

• E2E encryption with the team key, handed over through a link whose fragment never reaches the server
• Cryptographic grants (AccessGrant) per recipient, with hybrid X25519 + ML-KEM-768
• Details of shares, file requests and signatures E2E encrypted in notifications, no name in the server's own
• 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 External Contractors: View-Only Copies and Verifiable Evidence

The Team plan lets a team entrust a document to an external contractor (expert, auditor, subcontractor) without ever handing over the original file. Two contractor seats are included per team.

• Derived, view-only copy: pages rendered as images of bounded resolution in the administrator's browser, watermarked, encrypted for that contractor alone with hybrid X25519 + ML-KEM-768. Neither the original nor the team key is ever served.
• Passkey approval of the canonical issuance manifest, then RFC 3161 timestamping of its record. A valid TSA chain does not by itself establish historical qualified service status.
• Hash-chained journal of openings and authorized page requests, not human reading. Hourly sealing can leave an unanchored tail. A checkpoint must be retained independently before an incident to compare the retained state.
• Copy-specific invisible mark, searched locally in the browser. A match identifies a compatible pattern, not the person responsible for a leak. Extreme resizing, binarization and copy mixing have measured failures.
• Exportable bundle: certificate, preuve.json, tokens and an offline Python/OpenSSL verifier. Strict mode distinguishes VALID, INVALID and INDETERMINATE and requires independent references, including the original, TSA root and checkpoint.
• Technical three-year retention, including after team deletion, with return on written request through a vault opened by passkey for ten minutes. Every extraction is journaled. The legal necessity of that duration must be documented and erasure requests reviewed.

A screenshot or screen photograph remains possible. Historical failures are retained. A newer private preproduction corpus, supplied with its derived pattern and exact PDF, recovers a vertical photo after local registration at 17.53 and two small crops at 17.99 and 12.86 in the production worker. Absent-candidate and wrong-key controls abstain. Automatic fragment search uses a stronger threshold of 10 and refuses a unique attribution whenever a competitor reaches 8. One actual candidate and seven synthetic candidates do not validate the full register or general attribution. Six actual OCR round trips erase the pattern. Reconstruction from the unmarked source can also remove all copy-specific information. New pages use lossless PNG. Personal access-end reminders remain optional. Certificates, evidence archives and explicit pattern export require a fresh active-administrator passkey. Export remains sensitive and unencrypted, derivation stays client-side. The platform vault remains separate.

7.4 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.5 Connectors, PrivCloud Companion and Native App

• WebDAV import from Nextcloud, ownCloud and compatible NAS
• Local PrivCloud Companion: 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, progressive TypeScript strict mode, Debian 13 distroless production Docker images without a shell or package manager.

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: the content of your files is unreadable on our servers. AES-256 encryption resists known quantum attacks, and the keys shared between team members are wrapped with hybrid X25519 + ML-KEM-768.
• Zero-knowledge architecture: without decryption keys, we cannot access your content. The details of notifications about shares, file requests and signatures are encrypted, and the ones our server writes name nobody.
• 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.
• External contractors under control: view-only copies approved by passkey, timestamped, journaled and invisibly marked. Offline checks require independent references and have documented limitations.
• 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