Research

The SecureDrop whistleblower platform has resulted in security research on the project itself, academic research analyzing threats of relevance to SecureDrop, and research inspired by SecureDrop that advances the state of the art of whistleblowing platforms. This page contains links to research papers and reports we're aware of on SecureDrop or research that mentions the project. Please send us a message if you are aware of research that is not mentioned here. Interested in working on research on SecureDrop? Reach out!

Our research

SecureDrop Protocol

Resources: eprint, repository, specification, implementation.

SecureDrop Protocol is an ongoing research project to develop an end-to-end encrypted (E2EE) protocol for whistleblowing applications, which allows for deployments in untrusted server enviroments while requiring no source-side state beyond a single passphrase.

For more information on SecureDrop Protocol, see our eprint or our series of blog posts:

Or our talks:

We have a few open research tasks that we are actively working on, or are scheduled down our roadmap:

  • PKI & Key Transparency: The SecureDrop Protocol establishes a key hierarchy in which FPF signs newsroom identities (leveraging the direct contact we often have through support), newsrooms authenticate and sign their journalists' keys, and journalists sign their single-use key bundles. While we represent all of this as key signing in the Protocol, we have yet to decide which standards to adopt for transparency and revocation, both necessary for offboarding journalists or decommissioning instances. At the same time, we want to minimize UX friction, avoiding expirations or forced renewals unless strictly necessary.
  • Attachments: The Protocol provides secure and anonymous communication between a source and a journalist, but it is designed as a messaging protocol rather than a file transfer one, with messages limited to a few hundred KB. Since whistleblowing often requires sending larger data, we need to extend the Protocol with an attachment scheme. The Protocol itself can carry the metadata for larger files (encryption keys, IDs, pointers), but the attachment scheme must satisfy additional constraints: it should keep the system single-server, and it must not downgrade the Protocol's other properties, such as unlinkability.
  • Traffic Analysis: The Protocol provides unlinkability at rest. However, a passive server adversary, whether through a compromised system or as the hypervisor, can observe request patterns and potentially correlate them to learn about users and their messages. We plan to mitigate some of this at the deployment level, but we'd like to better characterize the residual risks and explore mitigations such as cover traffic.

WEBCAT

Resources: documentation, extension repository, infrastructure repository, specification.

WEBCAT is an ongoing project to develop and deploy a system for in-browser code verification. This will support the deployment of future whistleblowing systems built on SecureDrop Protocol, but is also generally applicable to security-focused single-page web applications. The project is public and collaboration is welcomed - see the WEBCAT Github repository.

For more information, see our blog posts:

Or our talks:

We have a couple open research topics we are currently looking into:

  • Proof of Onion Enrollment: WEBCAT enrolls domains in a distributed consensus system. For classical domains, the properties are relatively easy: spam is mitigated by subdomain limitations, domains are public by default, and they are easy to fetch and verify. Onion domains present a different problem set: we want the enrollment list to remain confidential but still auditable, and anyone can generate an unlimited number of valid onion keys, which complicates spam resistance and automatic validation of claims.
  • Formal Modeling of WEBCAT Constraints: WEBCAT imposes a complex set of constraints on web applications to enforce auditability and integrity. These constraints induce a large state space whose interactions are difficult to evaluate exhaustively by hand. Building on prior work in constraint-based modeling of browser behavior, we want to explore whether similar formal-methods approaches can be applied to WEBCAT to systematically check the safety and reachability of its states.

Whitepapers

Academic Publications

Third-party audits

We get regular third-party audits of SecureDrop and its subcomponents. For transparency, we publish the reports, which can be seen below:

  • X41 D-Sec, 2026 SecureDrop Workstation & Inbox Audit (PDF). This report describes a March 2026 audit before the SecureDrop Inbox's initial release, as well as the broader SecureDrop Workstation.
  • 7ASecurity, 2024 SecureDrop Audit Report (PDF). This report describes the wide-ranging audit of SecureDrop performed in the summer of 2024. The audit covered application code, the supply chain, build/deployment infrastructure, and the SecureDrop threat model. Funded by OTF.
  • Trail of Bits, SecureDrop Workstation Audit (PDF). This report describes the December 2020 and January 2021 audit of the journalist Qubes workstation, now in pilot use in news organizations. Funded by the New York Times.
  • Include Security, SecureDrop Workstation Audit (PDF). This report describes the November 2018 audit of the alpha release of the journalist Qubes workstation. Funded by the OTF Red Team.
  • Leviathan Security, SecureDrop Audit (PDF). Performed in late 2018 on behalf of Softwerx.
  • iSEC Partners, SecureDrop Audit (PDF). Performed in Summer 2015.
  • iSEC Partners, SecureDrop Audit (PDF). Performed in Summer 2014.
  • Cure53, SecureDrop Audit (PDF). Performed in late 2013.
  • University of Washington, SecureDrop Audit (PDF). This was the first audit of SecureDrop, performed in Spring 2013.

Student Research