Security Whitepaper

Technical deep-dive into how RocketShare protects your files with zero-knowledge encryption

This document provides a comprehensive technical overview of how RocketShare protects your data. It is intended for security professionals, compliance officers, and anyone who wants to understand exactly how our encryption works.

1. Executive summary

RocketShare is a zero-knowledge encrypted file sharing platform. Files are encrypted client-side using AES-256-GCM before upload, and the encryption key is embedded exclusively in the URL fragment—a part of the URL that browsers never transmit to servers. This architecture means that RocketShare operators cannot access, read, or decrypt user files under any circumstances, including lawful interception requests.

Key properties:

  • Zero-knowledge architecture — the server never possesses decryption keys
  • End-to-end encryption — files are encrypted before leaving the sender's device and decrypted only on the recipient's device
  • No server-side key storage — keys exist only in the share link URL fragment
  • Automatic expiry and deletion — files are permanently deleted after expiry

2. Threat model

What we protect against

  • Server compromise — even if an attacker gains full access to our servers, stored files remain encrypted and unreadable without the per-transfer key
  • Network interception — TLS 1.3 protects data in transit; encryption keys in URL fragments are never sent over the network
  • Insider threats — RocketShare operators have zero access to file contents by design, not policy
  • Lawful interception — we cannot comply with decryption requests because we do not possess the keys; we can only provide encrypted blobs and metadata

What is outside our threat model

  • Compromised sender or recipient device — if malware has access to the user's browser, it could intercept keys or plaintext files
  • Share link interception — anyone who obtains the full share link (including the URL fragment) can decrypt the files; users must share links securely
  • Browser vulnerabilities — we rely on the Web Crypto API provided by the browser; browser-level exploits are outside our control

3. Encryption implementation

Algorithm

All file encryption uses AES-256-GCM (Galois/Counter Mode), a symmetric authenticated encryption algorithm. GCM provides both confidentiality and integrity, meaning any tampering with the ciphertext is detected during decryption.

Key generation

Encryption keys are generated client-side using the browser's Web Crypto API (crypto.subtle.generateKey), which is backed by the operating system's cryptographically secure pseudorandom number generator (CSPRNG).

  • Key size: 256 bits
  • Source: Web Crypto API (crypto.subtle.generateKey), backed by OS-level CSPRNG
  • Scope: one unique key per transfer (file or bundle)

Encryption process

  1. The user selects files for upload
  2. A 256-bit AES key is generated using crypto.subtle.generateKey()
  3. A unique 96-bit initialization vector (IV) is generated per encryption operation
  4. Files are encrypted in the browser using AES-256-GCM via the Web Crypto API
  5. The encrypted ciphertext is uploaded to the server
  6. The raw key material is Base64url-encoded and placed in the URL fragment (#<base64url-key>)

Streaming encryption

For large files, RocketShare uses a streaming encryption approach. Files are processed in chunks to minimize memory usage, allowing encryption and upload of files that exceed available RAM.

Each chunk is encrypted with its own randomly generated 96-bit IV (crypto.getRandomValues), ensuring unique ciphertext for each chunk even if file contents repeat.

4. Key management

URL fragment approach

The decryption key is embedded in the URL fragment (the portion after #). This is the critical security property of the system:

  • Browsers never transmit URL fragments to servers in HTTP requests (RFC 3986, Section 3.5)
  • The fragment stays entirely client-side — in the browser's address bar, history, and when shared by the user
  • The server only receives the path and query parameters, never the #... key portion

Key lifecycle

  1. Generation — created in the sender's browser using CSPRNG
  2. Use — used immediately for client-side encryption
  3. Embedding — placed in the share link URL fragment
  4. Transmission — the user shares the link via their preferred secure channel (email, messenger, etc.)
  5. Decryption — the recipient's browser reads the fragment and decrypts the file
  6. No storage — keys are never stored on the server; they exist only in the share link

What the server stores

The server stores only:

  • Encrypted file blobs (ciphertext)
  • Transfer metadata: file name, file size, MIME type, expiry date
  • Transfer settings: download limit, password protection hash (if enabled)
  • Account-level data: email, auth tokens (not related to file encryption)

The server never stores: encryption keys, plaintext file contents, or any data that could be used to derive the key.

5. File lifecycle

Upload

  1. User selects files → encryption key generated client-side
  2. Files encrypted with AES-256-GCM in the browser
  3. Encrypted blobs uploaded to server via TLS 1.3
  4. Server stores ciphertext + metadata, returns transfer ID
  5. Share link constructed: https://rocketshare.app/d/{id}#{base64url-key}

Storage

  • Encrypted files are stored on S3-compatible object storage hosted in the EU (Amsterdam)
  • Files are stored as opaque encrypted blobs — the storage provider cannot read them
  • Metadata is stored in PostgreSQL with encryption-at-rest on the database volume

Download

  1. Recipient opens the share link
  2. Browser extracts the key from the URL fragment (never sent to server)
  3. Encrypted blob is downloaded from the server
  4. Decryption happens entirely in the recipient's browser
  5. Plaintext file is presented to the user for download

Expiry and deletion

  • Transfers have a configurable expiry (3 days to 90 days depending on plan)
  • After expiry, a scheduled cleanup task permanently deletes the encrypted blobs from object storage and the file records from the database
  • The transfer metadata record (file names, sizes, timestamps) is retained in an expired state for accounting and audit purposes, but all encrypted file data is irreversibly removed
  • No backups are kept of expired file data

6. Infrastructure

Hosting

  • Application: deployed on Cloudflare Workers (edge compute)
  • Database: PostgreSQL, hosted in the EU
  • Object storage: S3-compatible, EU (Amsterdam) region
  • Cache: Cloudflare KV (key-value store), for session and rate-limiting data only — never used for file content
  • CDN: Cloudflare global network for static assets and edge routing

Data residency

All file storage and database servers are located within the European Union. We do not replicate file data outside the EU.

Network security

  • TLS 1.3 enforced on all connections (HTTP and database)
  • HSTS with preloading — browsers are instructed to always use HTTPS
  • HTTP security headers — CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy
  • No mixed content — all resources loaded over HTTPS

7. Authentication and access control

User authentication

  • Email/password — passwords hashed with scrypt (N=16384, r=16, p=1), minimum 8-character length enforced
  • OAuth — Google and Microsoft SSO via industry-standard OAuth 2.0 / OpenID Connect
  • Session management — secure HTTP-only cookies with proper SameSite attributes

Transfer access controls

  • Link-based access — anyone with the complete share link can decrypt (the key is in the URL)
  • Optional password protection — transfers can require an additional password; the password hash is verified server-side before delivering the encrypted blob
  • Download limits — configurable maximum number of downloads before the link is disabled
  • Expiry — automatic time-based expiry after which encrypted file data is permanently deleted

8. Data minimization and retention

Principle of least data

We collect only what is necessary to operate the service:

  • Account data: email address, name (if provided via OAuth), hashed password
  • Transfer metadata: file names, sizes, MIME types, timestamps, expiry dates
  • Usage data: transfer counts and storage used (for plan enforcement)
  • Analytics: anonymized usage patterns via PostHog (EU-hosted, privacy-focused configuration)

What we do not collect

  • File contents (we cannot access encrypted blobs)
  • Encryption keys
  • IP addresses in long-term storage (access logs are ephemeral)
  • Browsing history or cross-site tracking data

Retention

  • Transfers: encrypted file data deleted automatically at expiry; transfer metadata retained in expired state
  • Account data: retained while account is active; deleted upon account deletion request
  • Access logs: ephemeral, not persisted beyond the request lifecycle

9. Incident response

In the event of a security incident:

  1. Containment — isolate affected systems immediately
  2. Assessment — determine scope and impact; thanks to zero-knowledge architecture, a server breach does not expose file contents
  3. Notification — affected users are notified within 72 hours as required by GDPR
  4. Remediation — fix root cause, improve defenses
  5. Disclosure — public disclosure of the incident and our response

Security issues can be reported to us via our Responsible Disclosure policy.

10. Limitations and transparency

We believe in being transparent about what our security architecture does and does not protect:

  • We cannot recover lost links — if a user loses the share link (including the URL fragment), the encrypted files cannot be decrypted. We do not have the key.
  • Link security is the user's responsibility — the share link is the sole access credential. If it is intercepted (e.g., sent over an insecure channel), the interceptor can decrypt the files.
  • CSP with nonce-based script policy — we use Content Security Policy with strict-dynamic and nonce-based script sources, which is the recommended approach for SSR applications. Inline styles still require unsafe-inline due to Tailwind CSS.
  • Browser trust — our encryption relies on the Web Crypto API. If the browser is compromised, all bets are off.
  • Metadata visibility — while file contents are encrypted, file names, sizes, and timestamps are visible to the server for operational purposes.

This whitepaper is current as of February 2026. We update this document when our security architecture changes. For questions, contact us.