LinkSilo's privacy posture is defined by what reaches our servers as ciphertext, what reaches our servers not at all, and what reaches our database under role-restricted access only. This page describes the security model, the cryptographic primitives in use, and the procedures by which independent parties verify both.
Last reviewed 2026-05-11
Security claims on this page refer to four concrete properties: (1) data encrypted in the user's browser before transmission, (2) data stored at rest under role-restricted database access, (3) data in transit over hardened TLS, and (4) data we deliberately do not collect. Each claim is mapped to specific code paths in our open-source repository, with privacy-sensitive routes flagged for security review at merge time.
Threats explicitly in scope: external network attackers, database compromise of LinkSilo infrastructure, mass surveillance by hosting-provider personnel, and adversarial third-party services. Threats explicitly out of scope: compromise of the user's own device or browser, attacks against the user's password by a party with that password, and physical access to an unlocked session.
The following primitives are used for data that must remain confidential to the user. Key derivation, symmetric encryption, and public-key encryption all execute in the browser via the RustCrypto crate family compiled to WebAssembly. The server never holds the plaintext for any data protected under these flows.
Symmetric authenticated encryption with associated data (AEAD). 256-bit key, 192-bit nonce. The extended nonce length provides sufficient margin for random nonce generation without the structural pairing required by AES-GCM, eliminating a class of nonce-reuse failures observed in deployed AES-GCM systems.
Password-to-key derivation. Minimum parameters m=64MB and t=2. Parameters are recalibrated against current commodity GPU capacity. The derived key never leaves the user's browser.
Anonymous public-key encryption used for visitor-to-creator messages. The visitor encrypts to the creator's published X25519 public key without revealing or generating a persistent sender identity.
Digital signatures. Used for service-to-service trust within the platform and for signed audit-log entries.
A 24-word phrase generated at signup, displayed once to the user, and used as the sole recovery mechanism if the password is lost. The recovery flow does not bypass encryption; the phrase derives a key that decrypts the wrapped master key.
The pure-Rust cryptographic crate family underlying all of the above (chacha20poly1305, crypto_box, ed25519-dalek, argon2, hmac, hkdf). LinkSilo pins audited versions and does not implement primitives internally.
User-generated content is stored as ciphertext blobs that LinkSilo cannot decrypt. Database access is partitioned across PostgreSQL roles, each granted the minimum privileges required for its service.
All transport encryption uses rustls; no OpenSSL sits in any TLS path. OpenSSL is present only as a transitive dependency of the WebAuthn/passkey library, where it parses attestation certificates -- never for transport security or the browser-side cryptography above. The single-implementation TLS posture reduces the attack surface introduced by parallel TLS stacks with different defaults, vulnerability histories, and configuration shapes.
TLS 1.3 with hybrid post-quantum key exchange (X25519MLKEM768) is enabled by default on the production edge once the deployment's certificate-authority pipeline supports it. Certificate transparency monitoring is enabled for all LinkSilo hostnames.
The analytics ingress receives certain inputs out of necessity (an HTTP request carries the visitor's IP and User-Agent), then coarsens and discards them at the process boundary. The list below describes data that is never written to a LinkSilo database under any tier or configuration.
Analytics data is aggregated rather than per-event. Visitor-derived dimensions are subject to k≥5 suppression at the API layer: dimensions whose population falls below the threshold within the query window are collapsed into an "other" bucket with the sum preserved.
LinkSilo treats internal claims about cryptography and privacy as provisional until verified by independent parties. The following independent reviews are planned.
Security researchers are invited to report vulnerabilities under a coordinated disclosure process. The intake address and the bounty schedule are listed below; both are also mirrored in the repository's SECURITY.md.
| Severity | Bounty range | Examples |
|---|---|---|
| Critical | €1,000 – €2,000 | RCE, master-key extraction, account-takeover via authentication bypass |
| High | €500 – €1,000 | Server-side decryption oracle, persistent privilege escalation, sensitive-data leak via direct DB access path |
| Medium | €100 – €500 | CSRF on state-changing endpoints, persistent XSS in creator-only views, broken access control on a limited resource |
| Low | €50 – €100 | Reflected XSS in a low-impact context, missing security header on a non-state-changing route, information disclosure of non-sensitive metadata |
Email security@linksilo.io with a description of the issue, reproduction steps, and your assessment of the impact. PGP encryption is strongly preferred; the public key will be published at https://linksilo.io/.well-known/pgp-key.asc (at launch; not yet available) and rotated every 24 months.
LinkSilo's client-side code is published under the GNU Affero General Public License v3.0-or-later (AGPL-3.0) from the public launch onward. Server-side code is published under the same license within 12 months of the public launch. The repository lives on Codeberg, mirrored to a Finnish-incorporated source forge to keep the canonical copy under EU jurisdiction.
Privacy-sensitive code paths are tagged with a PRIVACY: comment marker. Any merge request that touches a tagged path is flagged for security review at merge time.