Secure Document Submission Platform on Tor Hidden Service

A secure whistleblowing system separates submission, storage, and review into distinct systems. The submission server is a Tor hidden service that accepts documents and messages from sources. It runs a minimal web application (Python/Flask or equivalent) with no outbound network connectivity. Documents are encrypted upon receipt with the journalist's public GPG key before storage - the submission server never stores plaintext documents. The journalist review workstation is an air-gapped system (no network, removable media only) running Tails OS. Documents are transferred via encrypted USB drive. The admin workstation manages the SecureDrop system via .onion SSH access. Physical security for all components is essential - the servers and workstations should be in secure locations with controlled access. This architecture follows the SecureDrop threat model: even if the submission server is compromised, only encrypted documents are present (the journalist's private key is on the air-gapped workstation, never on the server). Source anonymity is protected by Tor (sources connect via Tor Browser to the .onion submission address).

The submission web application handles document uploads and sends encrypted messages to journalists. Build with a minimal stack: Python 3 with Flask (or Go for better memory efficiency), SQLite for metadata storage (not document content - documents are encrypted files), and server-side GPG encryption. The submission flow: source visits .onion URL via Tor Browser, generates a random codename (used for follow-up communication), uploads documents (encrypted with journalist's public key on upload), and optionally submits a text message (also encrypted). The submission codename allows the journalist to send a reply (encrypted with the source's session key) and the source to check for replies in a later session. Document encryption: use GPG with the journalist's public key. The python-gnupg library provides Python bindings. Never decrypt documents on the server - always serve encrypted blobs for download to the air-gapped review workstation. Metadata minimization: do not log file names, file sizes in a recoverable way, or timestamps that could correlate with source activity.

The journalist's GPG key pair is the critical cryptographic element. The public key is installed on the submission server (for encrypting incoming documents). The private key is stored only on the air-gapped review workstation. Key generation: create a 4096-bit RSA key pair (or Ed25519 for modern systems) on the air-gapped workstation. Export the public key (ASCII-armored) and transfer to the submission server via a freshly formatted USB drive. Install on the server: gpg --import journalist-public-key.asc. Document retrieval workflow: journalist downloads encrypted documents from submission server via a journalist .onion address (different from the source submission address), transfers to the air-gapped workstation via encrypted USB, and decrypts using the private key stored on the workstation. The private key never leaves the air-gapped workstation. Key rotation: rotate journalist GPG keys periodically (annually or after suspected compromise). Destroying old encrypted submissions after review reduces the value of historical server compromise.

Operational security guidance must be provided to sources using the platform. Sources should be instructed to: (1) Use Tor Browser (not just any Tor-capable browser) to access the .onion submission address. (2) Use a computer that is not personally owned or associated with their real identity if possible. (3) Not access the submission platform from a workplace network where traffic is logged. (4) Not discuss the submission with colleagues or family members who could be compelled to testify. (5) Not use personal accounts (email, social media) to research the submission address before using Tor. (6) Note the codename they generate - it is the only way to check for journalist replies. From the server side: implement a canary statement (a regularly published statement asserting the server has not been compromised or served with a secret legal order) in a verifiable format. Respond to sources via encrypted replies within the platform, not via email. Establish a physical address for legal correspondence that does not reveal the server location.

The submission server requires maximal hardening. Operating system: use Debian stable with only the minimum required packages installed (no graphical interface, no unnecessary services). Disable SSH password authentication (key-only via .onion address for admin access). Enable automatic security updates only (no feature updates that could break configurations). Application security: run the submission application as a dedicated non-root user. Use systemd sandboxing (ProtectSystem=strict, PrivateTmp=true, NoNewPrivileges=true) to restrict the application's filesystem access. Network isolation: use iptables or nftables to block all outbound clearnet traffic from the server. The only permitted outbound connections should be via Tor (for the submission server's Tor daemon). Application firewall: if using fail2ban, configure it for patterns in the submission application logs rather than SSH (SSH is already key-only). Disk encryption: encrypt the server disk at rest. Many VPS providers offer disk encryption options - enable it. If disk encryption is not available from the provider, use LUKS at the application level for the document storage directory. Regularly audit the submission server by reviewing logs, checking running processes, and verifying file integrity with a tool like AIDE.