[security.protocols]

Last updated: July 2026

Back to HomepageView Pricing

Security Philosophy

Quilon uses client-held keys and client-side encryption for protected content payloads. Core relays ciphertext without persistent payload storage; Ops stores encrypted message bodies and file bytes plus the account, room, membership, file, and audit metadata required to operate the service. “Zero knowledge” here refers to protected content and key custody, not to all service metadata.

End-to-End Encryption

Encryption Algorithm

Clipboard/text envelopes use AES-256-CBC with HMAC-SHA256(Encrypt-then-MAC). File-transfer and Ops content envelopes use AES-256-GCM. Both contracts provide confidentiality and integrity verification, and malformed or unauthenticated envelopes are rejected.

Encryption Format

CBC/HMAC payloads use Base64(salt[16] + iv[16] + ciphertext + hmac[32]). GCM payloads use versioned envelopes with a nonce, ciphertext, and authentication tag. Each encryption operation uses fresh random material so identical plaintext does not produce identical ciphertext.

Encryption Location

Encryption and decryption of protected content happens on your device. Clipboard bodies, screenshots, transferred file bytes, Ops message bodies, and Ops file bytes reach the service only as validated ciphertext. Ops room names, file names/types/sizes/digests, membership, invites, audit records, and account/routing data remain readable operational metadata.

Key Derivation

  • Sync payload keys are derived using PBKDF2-HMAC-SHA256 with 310,000 iterations and a random 16-byte salt
  • Private Share link keys are generated locally and passed via URL fragment (#key)
  • HMAC comparison uses timing-safe equality to prevent timing attacks

Zero-Knowledge Architecture

Quilon runs in a Zero-Knowledge model. Sync and sharing payloads are encrypted client-side and key custody remains on your devices.

What Quilon Can See

  • Your email address (for authentication)
  • Device identifiers (for Socket.io routing)
  • Encrypted blobs (unreadable without your key)
  • Ops room names, membership, invites, audit events, and expiry metadata
  • Ops file names, MIME types, sizes, and ciphertext digests (not file bytes)
  • Data volume — chunk count reveals approximate file size

What Quilon Cannot See

  • Clipboard bodies covered by the encrypted sync contract
  • Core transfer, Private Share, Secure Drop, or Ops file bytes in plaintext
  • Ops message bodies in plaintext
  • Screenshot content (encrypted before transmission)
  • Device pairing keys, Private Share fragment keys, or Ops room keys

Live Tunnel

Live Tunnel is disabled for the Core + Ops launch because the previous HTTP proxy terminated request and response plaintext at the backend. Ops does not advertise the feature, tunnel session creation is rejected, and every request to /t/* fails closed with HTTP 404.

Device Pairing (Zero-Knowledge)

Current pairing uses a versioned QR payload. The content key is encrypted for the receiving client and decrypted locally; the backend confirms the short-lived pairing session without receiving the content key.

  1. The sending client creates a short-lived, versioned pairing payload
  2. The receiving client decrypts the protected key material locally with the pairing PIN
  3. The backend receives only the session identifier and pairing secret needed for confirmation
  4. The receiving client stores the key only after the pairing session completes

Private Share Security

Private Share lets you send files to anyone via a link. The file is streamed directly from your desktop through our server to the recipient — nothing is stored on the server. The server acts as a blind relay for encrypted chunks.

How It Works

  1. Desktop generates a unique AES-256 key for each share
  2. Share link format: quilon.dev/s/<sessionId>#<key> — key in URL fragment, never sent to server
  3. File is split into encrypted chunks and streamed through the relay
  4. Chunks are relayed through server RAM only — zero disk storage
  5. Recipient decrypts chunks in browser using the key from the URL fragment

Security Properties

  • Zero-storage (Private Share / Secure Drop): No file data touches disk on the server
  • One receiver: Maximum one receiver per session prevents hijacking
  • Time-limited: Sessions auto-expire after 30 minutes
  • Rate-limited: Anonymous join attempts limited to 20/min per IP
  • Wormhole model: Sender must be online — no server-side buffering

Data Storage Policy

Quilon uses a relay-only architecture for clipboard sync, Private Share, and Secure Drop. Quilon Ops deal rooms store end-to-end encrypted blobs and metadata on our servers until room expiry or kill-switch.

What We Don't Store

  • Clipboard content (encrypted and relayed in real-time, then discarded)
  • Core file transfer data (streamed through server RAM only)
  • Private Share / Secure Drop file data (zero-storage, relay-only)
  • Screenshots or images in transit
  • Plaintext clipboard, message-body, or file-byte payloads

What We Do Store

  • Account information (email, hashed password)
  • Quilon Ops ciphertext plus readable room, membership, invite, file, expiry, and audit metadata; room content is purged on expiry or kill-switch
  • Subscription status (via Apple App Store / Google Play through RevenueCat)
  • App release metadata (version numbers and release download references)

Rate Limiting

Quilon enforces rate limits to prevent abuse:

  • Clipboard sync: 30 clips/min per user
  • File transfer chunks: 200 chunks/min per user
  • Private Share join: 20 attempts/min per IP
  • Share link creation API: 30 requests/min per IP

Authentication Security

Password Hashing

Passwords are hashed using bcrypt with a cost factor of 12. We never store plaintext passwords.

Session Management

  • JWT tokens for API and Socket.io authentication
  • Socket connections require valid JWT before any data relay
  • Anonymous access limited to Private Share receiver (sessionId-scoped)

Network Security

HTTPS/TLS

  • All data in transit is encrypted with HTTPS/TLS
  • Web and API endpoints are served over secure transport
  • WebSocket connections upgraded over TLS

API Security

  • All authenticated endpoints require valid JWT
  • Rate limiting on all endpoints
  • Input validation on all parameters

Vulnerability Disclosure

Responsible Disclosure Policy

If you discover a security vulnerability in Quilon, please report it responsibly to security@quilon.dev.

Reporting Guidelines

  • Don't: Post vulnerabilities publicly or in issues/comments
  • Do: Email detailed information to security@quilon.dev
  • Do: Allow us 90 days to fix and release a patch before public disclosure

Contact Us

For security concerns or questions, please contact:

Email: security@quilon.dev

Website: quilon.dev

Security