PrivCloud Security

Overview

PrivCloud is built on the zero-knowledge principle. End-to-end encryption is the default mode of every account: the decryption key stays in the URL fragment and is not sent to the server, so neither our team nor our storage provider can read the content of your files. It only passes through our servers if you choose to send it by e-mail. 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.

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=...). Under the HTTP protocol, the browser does not send this fragment to the server: it stays on your device and does not appear in any of our infrastructure logs.
• The recipient decrypts directly in their browser. By default, the key does not pass through our infrastructure: it only does when you choose to send it by e-mail.

Algorithms used

Zero-knowledge architecture means our system is designed so that we cannot access the contents of your end-to-end encrypted files, even if we wanted to or were compelled to: by default, the key is not sent to our servers. It only passes through them if you choose to send it by e-mail.

• Your account's files are encrypted before upload
• By default, your key does not pass through our servers
• Our logs contain no decryption keys
• Even full access to our database would not allow reading your files

What our server sees

End-to-end encryption protects the content. To work, the service still keeps the following readable:

• your e-mail address, your username, recipient addresses and the members of your teams
• file sizes, counts and dates, and connection IP addresses
• labels from shares created without end-to-end encryption
• the names of teams, of their folders and of documents submitted for signature

Shamir's Secret Sharing is only used to recover your E2E key if you lose it. It is optional: without fragments or a passkey vault, a lost key leaves your encrypted files permanently unreadable, and PrivCloud cannot recover it for you. PrivCloud uses its own implementation, running entirely in your browser: the fragments are shown on your screen and are not sent to the server.

Principle

When you create them, you choose the number of fragments and the threshold needed to rebuild the key (for example 3 fragments of which 2 are enough). With fewer fragments than this threshold, recovering the key is mathematically impossible: they reveal nothing about it.

Why it matters

• 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.

A passkey uses a cryptographic key managed by an authenticator, potentially synced depending on the provider. With the Team plan, it also approves issuing a copy to an external contractor, with verifiable evidence and documented limitations.

• Passkey sign-in: WebAuthn with user verification (PIN, fingerprint or face). Adding a passkey takes the password or a fresh sign-in through the linked provider, plus the 2FA code when enabled, and you are told by e-mail.
• View-only copy: the contractor receives watermarked page images, encrypted for them alone. Neither the original file nor the team key is ever served to them.
• Approved and timestamped hand-over: the administrator's passkey binds approval to the page manifest. RFC 3161 timestamping covers a hash. Verifying its chain against an independent root does not by itself establish historical qualified service status.
• Hash-chained viewing journal: authorized requests are recorded before pages are sent, without proving human reading. A checkpoint retained outside the application before an incident lets you compare the anchored portion, not events never recorded or the unanchored tail.
• Invisible mark: each copy carries a pattern to search for a compatible issued copy. Cropping, recompression and other changes can prevent detection. A match does not identify the person responsible. The team keeps the pattern key locally.
• Evidence kept three years: the register and journal have a technical three-year retention and can be exported from the passkey-protected vault. The offline verifier distinguishes valid, invalid and indeterminate bundles. This duration is not an automatic legal justification. Document title and content do not appear in this register.

• 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.

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

Testing rules and data handling

• Test only with your own accounts and your own data.
• Do not perform denial-of-service, spam, social engineering, large-scale brute force, or destructive testing.
• If a vulnerability accidentally exposes third-party data, stop testing immediately and report it without investigating further or retaining, modifying, or sharing that data.

Public verification of read-only sharing

Review the proof format, reproducible tests and measured watermark results, including limitations and failures.

Review the tests and download the tools