← Dropfleet·Legal & policies·Français

Informational page describing the Service's technical security measures. In case of any discrepancy, the (French) Terms and Privacy Policy prevail.

File transfer security

Last updated: 2026-06-05

This page explains, transparently, how Dropfleet protects your files and which libraries provide that protection. It is informational and complements the Terms of Service and the Privacy Policy (both in French).

In short

The transfer, step by step

  1. Preparation (browser). In Confidential mode your files are encrypted on your device before anything is sent. In Standard mode they are sent as-is to storage.
  2. Direct upload. The browser uploads the bytes directly to object storage via short-lived presigned URLs — the application never relays the bytes itself.
  3. Storage. The bytes live in object storage (Garage) on a disk encrypted at rest (LUKS). In Confidential mode they are already end-to-end encrypted.
  4. Scanning (Standard mode). An antivirus scans the files before they become downloadable (see "Antivirus").
  5. Download & decryption. The recipient fetches the bytes via a presigned URL; in Confidential mode, decryption happens in their browser.

Confidential mode (zero-knowledge)

In Confidential mode a master key is generated randomly in your browser and placed in the URL fragment (the part after the # of the share link). Browsers never send that fragment to the server, so the key stays with you and with whoever you give the link to.

The direct consequence: the operator cannot read your files in this mode — but anyone holding the full link (including the #) can decrypt them. Share the link over a trusted channel.

Technical details

End-to-end encryption (Confidential mode)

Item Detail
Library libsodium (libsodium-wrappers-sumo 0.8.4), bundled into the application (no external CDN)
Content encryption XChaCha20-Poly1305 in secretstream mode, in 64 KiB chunks, with a final marker (anti-truncation: a truncated stream is rejected)
Master key 256-bit, generated by a cryptographic RNG (CSPRNG, randombytes_buf), carried as base64url in the #
Per-file subkeys derived with BLAKE2b — every file has its own key
File names & types encrypted separately with crypto_secretbox (XSalsa20-Poly1305) — the server never sees the real names
Authentication & integrity every chunk carries a Poly1305 tag: any tampering or truncation is detected on decryption

Multi-file archives are zipped with fflate, which has no cryptographic role — decryption always precedes archiving.

Transfer passwords

An optional password can lock a transfer. It is hashed with Argon2id (OWASP parameters: 19 MiB memory, 2 iterations, parallelism 1, 16-byte random salt), in PHC format, and verified in constant time. The password is a server-side lock: in Confidential mode it does not replace the decryption key.

In transit & at rest

Antivirus

In Standard mode, all files are scanned by ClamAV before they become downloadable, regardless of size. For very large files the scan can take time: the recipient sees a "scan in progress" state, and the download is unlocked only once a clean scan completes; a file flagged as infected is deleted. In Confidential mode, because files are end-to-end encrypted, they cannot be scanned server-side.

Lifecycle & isolation

Libraries and components

Component Version Role
libsodium-wrappers-sumo 0.8.4 end-to-end encryption (browser)
fflate 0.8.x browser-side ZIP archiving (non-cryptographic)
Argon2id (golang.org/x/crypto) hashing of transfer passwords
ClamAV 1.4 antivirus scanning (Standard mode)
Garage v2 S3-compatible object storage (encrypted at rest via LUKS)
MongoDB / Valkey metadata (TTL expiry) / sessions & rate limiting
Caddy / Traefik TLS termination, security headers

What this security does not cover (transparency)

Reporting & contact

To report illegal content, see Reporting & takedown (DSA / DMCA). For questions about personal data, see the Privacy Policy.