PrivCloud Sharing Security
At PrivCloud, security isn't a feature -- it's the architecture.
Overview
PrivCloud Sharing is built on the zero-knowledge principle: neither our servers, nor our team, nor our storage provider can read your files. Encryption happens in your browser, before your data even leaves your device. This page transparently describes the cryptographic mechanisms, infrastructure choices and honest limitations of the system.
End-to-End Encryption (E2EE)
How it works
- An AES-256 key is generated locally in your browser via the Web Crypto API.
- Your files are encrypted client-side before upload -- we only receive opaque ciphertext.
- The decryption key is embedded in the share link as a URL fragment (#key=...). By HTTP protocol definition, this fragment is never sent to the server -- it stays in your browser and never appears in any of our infrastructure logs.
- The recipient decrypts directly in their browser, without the key passing through our infrastructure.
Algorithms used
| Component | Standard |
|---|---|
| File encryption | AES-256-GCM |
| Network transport | TLS 1.3 |
| Storage at rest | AES-256 |
| Key sharing | SSKR / Shamir |
Why AES-256-GCM?
GCM (Galois/Counter Mode) provides not only confidentiality (nobody can read) but also authenticity (nobody can tamper with encrypted data without detection). It's the standard used by governments and financial institutions to protect classified data.
Zero-knowledge architecture
Zero-knowledge architecture means our system is designed so that it is technically impossible for us to access your file contents, even if we wanted to -- or were compelled to.
- Your files are encrypted before upload
- Your key never passes through our servers
- Our logs contain no decryption keys
- Even full access to our database would not allow reading your files
Shamir's Secret Sharing (SSKR)
To prevent permanent loss of access to your files if you lose your key, PrivCloud implements Shamir's Secret Sharing (via SSKR -- Sharded Secret Key Reconstruction).
Principle
Your E2E key is split into multiple fragments (e.g. 3 fragments of which 2 are sufficient to reconstruct the key). Each fragment alone is useless -- only the combination of a minimum number of fragments allows reconstruction.
Why it matters
| Scenario | Without SSKR | With SSKR |
|---|---|---|
| Loss of primary key | Files permanently inaccessible | Reconstruction via fragments |
| Theft of one fragment | — | Useless on its own |
| Server compromised | Key exposed if centralized | No complete fragment present |
Best practice:
Store your fragments in separate, secure locations (password manager, offline encrypted media, physical safe).
Infrastructure & compliance
French hosting -- native GDPR
- No data transfers outside the EU
- Native compliance with the General Data Protection Regulation (GDPR)
- No disclosure obligation under the US Cloud Act
- Right to erasure and data portability applicable
Zero tracking, zero analytics
PrivCloud does not collect any behavioral data. No tracking cookies, no advertising pixels, no third-party analytics tools are loaded on our pages. What you share is none of our business -- literally.
Object storage provider (S3-compatible)
Even our object storage provider cannot read your files. With E2E enabled, it only stores opaque ciphertext -- no context, no readable metadata, no possibility of decryption.
Share link security
- Automatic expiration: each link has a configurable lifetime. After expiry, the link is revoked and files deleted.
- Password protection: add an extra authentication layer to each share.
- Download limit: set a maximum number of allowed downloads per link. Once reached, the link is automatically revoked.
- Download notifications: get real-time alerts when a recipient downloads your file, to detect any unexpected access. Note: if you have the preview option and would also like to receive a notification for that type of access, feel free to let us know directly via the GitHub repository.
Open Source & auditability
- Any security researcher can audit our code
- Cryptographic implementations are publicly verifiable
- No backdoor can be hidden without being detected by the community
- Transparency is structural, not marketing
If you are a security researcher or auditor and wish to perform a formal code review, we are open to any independent audit process. Contact us via the GitHub repository.
View source code on GitHub ->Report a vulnerability
Discovered a security flaw? We encourage you to disclose it responsibly.
Contact: security@stockageprive.net or via a private issue on the GitHub repository.
- Acknowledge receipt within 48 hours
- Keep you informed of applied fixes
- Mention your contribution (if you wish) in our hall of fame
We do not file complaints against security researchers who act in good faith.
Ready to send files securely?
Create a free account and enjoy end-to-end encryption, password protection and French hosting - no compromises.
Page maintained by the PrivCloud team -- Infrastructure secured by THEMIOT Informatique, Cybersecurity Consultant.