This blog post is a part of a series about our research toward the next generation of the SecureDrop whistleblowing system. If you haven’t been following along, check out our previous post for some recommended context.

Here, we present a proposed end-to-end encryption protocol for a future version of SecureDrop server, accompanied by a brief discussion of various aspects of the protocol and our next steps.

Protocol overview

We present a proof-of-concept protocol with the following core properties, which are derived from the research and threat modeling concerns previously discussed:

1. No accounts, and therefore no user authentication;
2. No message flow metadata, meaning messages can’t be linked together, and different types of messages are indistinguishable from one another;
3. No changes in server state are observable externally;
4. No ciphertext collection or information leaks via trial decryption – a given recipient receives pertinent ciphertext only.

The protocol has a simple API with only three endpoints: send, fetch, and download. Sources’ and journalists’ requests to these endpoints are structured identically, to make them harder for a compromised server or network adversary to distinguish. The server’s response is unique for each request, to avoid leaking information about server state.

It uses well-established cryptographic primitives (currently libsodium for proof-of-concept purposes), achieving end-to-end encryption and one-way forward secrecy for messages flowing from source to journalist. The server has access to minimal metadata, theoretically opening the door to deployment in adversarial environments.

Along with this blog post, we’re also publishing:

• A proof-of-concept GitHub repository that demonstrates the end-to-end protocol and documents how it works;
• And a preliminary audit, which also contains a concise summary of the protocol.

This is proof-of-concept code and is not intended for production use. The protocol details are not yet finalized.

Discussion

Let’s contextualize the four notable properties of the SecureDrop Protocol as enumerated above.

The first property arises from the desire to maximize plausible deniability for the source in a variety of situations, including repeated snapshotting of the server. The motivation for the second property is evident, but the implementation is less trivial: it’s one thing to conceal a sender, but how does a server deliver a message to an unknown recipient? One approach is trial decryption — deliver all ciphertext to everyone, and valid recipients will determine locally which messages belong to them based on what their own secret keys can decrypt. But besides being inefficient, this would also introduce an information leak: it would allow anyone to constantly monitor the server state and know when messages are added and deleted, observe message upload patterns, and so on. In the context of a relatively low-traffic self-hosted system, this would represent a significant metadata leak, thus the need for our third property.

Finally, one of our additional goals is a graceful degradation of security properties, in case of different degrees of user or server compromise. Allowing anyone on the internet to observe ciphertext would allow for “harvest now, decrypt later” attacks, so the fourth property reflects the need to guard against such possibilities.

Comparison of messaging protocols

The following is a highly simplified comparison of real-world message delivery approaches.

Trial decryption

Trial decryption is a simple way to conceal recipient information. Payloads are encrypted for a given recipient, which in turn has full visibility of all the payloads in the system. As the name suggests, a recipient will discover which messages belong to them by trying to decrypt all the messages they receive.

Benefits to this approach include symmetry among user traffic (all users download all payloads) and lack of account creation requirement. Limitations include the lack of scalability, the information leak mentioned above, and the ability for an arbitrary attacker to collect payloads/ciphertext. This approach would satisfy requirements 1 and 2 (lack of accounts, lack of message flow metadata), but not 3 and 4 (externally-observable server state, bulk ciphertext collection).

Signal Protocol

Signal relies on accounts for both message submission and delivery. Only authenticated users can submit messages, and recipients must be specified outside the encrypted payload in order for the server to deliver the pertinent payloads at the next recipient login and fetch.

This message delivery approach has high delivery reliability, and is resource-efficient for the recipient, since only pertinent payloads are being downloaded and decrypted, but it would not support our transition towards a less trusted server. It satisfies properties 3 and 4 (no externally-observable server state changes, no bulk ciphertext collection), but not 1 and 2 (accounts, message flow metadata).

Oblivious Message Detection/Retrieval (OMD/OMR)

Oblivious Message Detection and Retrieval is a newer message delivery mechanism aimed at concealing the recipient and addressing the scalability issues of trial decryption by, in very broad terms, mixing pertinent and non-pertinent payloads, and using one or more “detector” servers to heuristically group, as well as distinguish, pertinent and non-pertinent content for a given user based on the “clues” assigned to each payload. (The idea of detecting/delivering messages in a way that makes them differentiable only by the receiver is an active research area; see also Fuzzy Message Detection.)

Fuzzy message delivery is less feasible for small-scale systems like SecureDrop, where a burdensome level of decoy traffic would be required. In addition, OMR uses homomorphic encryption and other constructs that, at the time of writing, are relatively new, and pose some design challenges. The combination of the protocol's complexity and the bleeding-edge nature of some of the protocol's components gave us pause, although research in this area, particularly that focused on group messaging, is promising.

SecureDrop Protocol

As with OMR, in the SecureDrop Protocol a sender sends the payload and a “clue” without any authentication. The recipient anonymously asks the server for clues, and the server serves both clues and decoys on every request. Every time a message-fetching request is made to the server, the response contains a new combination of clue and decoy ciphertext. Since every request returns a different response, and since the ciphertext is indistinguishable without being able to decrypt one or more of the clues, individual requests do not leak information about server state changes.

Message-fetching is a two-step operation. The recipient requests clues, and attempts trial decryption on them. For each successfully-decrypted clue, the recipient discovers a message_id. The message_id is a cryptographically unguessable value generated by the server upon message submission and kept private from all other parties. When an anonymous user discovers a message_id, they are able to fetch the corresponding message payload from the server. This two-step process is an optimization-related implementation detail, not a security measure.

SecureDrop Protocol in detail

Understanding SecureDrop Protocol’s message retrieval mechanism requires a basic understanding of classical Diffie-Hellman key agreement. In particular, we take advantage of the notable properties that key agreement is commutative and can be extended to any number of parties.

This diagram shows how the recipient of a message can agree with the server on a shared key K without learning anything about the state of the server – while preventing the server from knowing whether the recipient is indeed the intended one. Every K is obtained using: long-term key material, which later allows the correct recipient to detect their pertinent messages; per-message ephemeral key material, which introduces unlinkability between messages addressed to the same recipient; and per-request ephemeral key material via “remixed” clues, which provides unlinkability between message-fetching requests, since the clues are transformed before every request.

As shown in the next diagram, this scheme allows the server to obliviously encrypt and transfer some information using symmetric key K, without knowing if the requesting recipient will be able to decrypt it.

The material that is obliviously-transferred is the message_id, a securely random, unguessable value that the server generates upon message submission. Conceptually, it can be thought of as a server-side message uuid. Its main purpose is to keep clue sizes small, rather than encrypting and remixing full message payloads.

Leveraging the commutativity of multi-party Diffie-Hellman to achieve unlinkability between requests is an uncommon application. We credit this contribution to former SecureDrop team member Michael Z, who resolved what was a multi-month sticking point in our research.

Why is the server “untrusted” if it generates secret key material? The server is “untrusted” in the sense that it should learn nothing about users and messages besides what is inherently observable from its pattern of requests, and it should not have access to sensitive metadata, or sender or receiver information. What the server must know are ciphertext payloads and associated clues that need to be stored. In this regard, the server is still a “privileged” asset that should not be queryable by anyone on the internet. That is why the server contributes with an ephemeral key: to hide its state and thus render all requests unlinkable to any change of such state.

SecureDrop Protocol: encryption properties

Message retrieval symmetry despite source-journalist asymmetry

Until now, we have commonly used the terms sender and recipient to indicate a role that a user can have. In classical messaging applications, all users can both receive messages and initiate conversations. In whistleblowing applications, the anonymized party (source) initiates communication with the trusted party (journalist). Our previous blog post outlines the difference in their endpoint requirements in detail, and describes the limitations on the type of key material that a source can have.

So, while both journalists and sources will use the same message retrieval mechanism and the same submission mechanism (and in practice, the same API endpoints), and are treated indistinguishably from the server’s perspective, their key setup is inherently different. This difference of roles and setup has a significant impact on the encryption properties we can achieve, especially in three areas: forward secrecy, participant authentication, and deniability.

Forward secrecy: It’s imperfect

Forward secrecy requires ephemeral keys, implying an evolving state with some non-predictable, non-deterministic source of entropy. Forward secrecy requires that both parties use per-message ephemeral keys, and is commonly achieved by periodically re-generating secret-key material and then discarding it, like an automatic key-rotation procedure. Our design constraints allow for source-to-journalist forward secrecy, by rotating some journalist encryption key, but not vice versa: for usability reasons, we do not want to rotate a source passphrase, and we cannot add non-deterministic key material on the source side, since we cannot store it anywhere. We consider the anonymity of the source a higher priority than the confidentiality of the material, so under these circumstances we accept this “one-way” form of forward secrecy.

Participant authentication

Consider a simple Diffie-Hellman key-agreement used with per-message ephemeral keys used for symmetric message encryption. A Diffie-Hellman key agreement is performed between the secret part of the per-message key and the public component of the recipient.

This kind of key agreement is unauthenticated: the recipient has no implicit or explicit proof that a particular sender sent that public key and ciphertext. This does not matter for a “first contact” message, which by definition comes from an anonymous/unknown party, but for ongoing conversations, some measure of participant authentication is required – essentially, to ensure that the source who began the conversation is indeed the one who is continuing it.

The question of participant authentication is an open problem that is interlinked with deniability. We see several fairly straightforward ways of addressing it; more discussion can be found here.

Deniability for sources

There are multiple layers at which SecureDrop seeks to create deniability: forensic deniability on a source’s own machine; forensic deniability on the server of the existence of a given source; and message-level cryptographic deniability.

The first forensic deniability property is discussed at length in our previous posts and is orthogonal to the protocol; broadly, we satisfy it by avoiding writing to disk on the source’s machine. The second type of forensic deniability is served by the lack of server-side accounts; the only way to prove that a given party exists is to gain ciphertext addressed to them (a pending message) along with their key material.

Conversation-level and message-level deniability require a more detailed discussion.

In cryptographic terms, deniability is often called repudiation, of which participation repudiation and message repudiation are two forms. Repudiation and authentication are both important security principles, and yet, in some ways they appear at odds with one another: how can a protocol offer both authentication and the ability to deny sending a message or being part of a conversation?

The Signal Protocol does offer both repudiation attributes and implicit participant authentication under certain conditions, via a clever use of multiple Diffie-Hellman key exchanges. Broadly, the implicit authentication comes from the use of long-term identity keys, while the deniability comes from the combination of approximately-discoverable public keys (via phone number/username, on Signal’s servers) and the idea that, while both parties must agree on a shared key to facilitate their conversation, neither party must sign their individual messages. Hypothetically, a conversation between two parties could be forged by one of the parties, providing the other with a measure of deniability.

By contrast, the SecureDrop Protocol cannot provide conversation-level repudiation in cases where an ongoing source-journalist conversation is desired. This is because, while journalist public key material can and must be publicly discoverable so that anonymous sources can contact them, sources do not publish their public key material, and must attach it in their first-contact message so that journalists can reply, proving their participation in at least this initial message.

SecureDrop Protocol could theoretically support two modes: a true “dead drop” mode from a source that never intends to return or receive replies, and a conversational mode, in which the source expects to return and continue correspondence. In the former, the source achieves full deniability. In the latter, which is the more typical use-case, individual message repudiation can be achieved (as can participant authentication, mentioned above), but participation repudiation cannot. This issue is an area of ongoing research.

Putting it all together: message-fetching and encryption

The following is a simplified illustration of the message-fetching and encryption in the SecureDrop Protocol. (Ephemeral keys have been omitted for illustrative purposes). The full protocol diagram can be found on GitHub.

Cryptographic primitives

The proof-of-concept implementation uses libsodium for both key-agreement and symmetric encryption. That means, as of now, that our DH exchanges are powered by X25519 and our authenticated symmetric encryption is powered by XSalsa20 and Poly1305 MAC.

Post-quantum security?

Elliptic-curve Diffie-Hellman is not considered quantum-safe. There are various key encapsulation mechanisms we could make use of that are appropriate for encryption, however, we have not yet found a post-quantum-secure solution for the message-fetching mechanism in the protocol, which requires the commutative properties of multi-party ECDH discussed above.

The multi-party mechanism we describe is used to protect anonymized metadata from leaking information about the state of the server over time, similar to a network-level correlation attack. One possibility is a hybrid model where messages themselves (including their sender information and other metadata) are encrypted in a quantum-safe manner, while the message-retrieval mechanism remains usable with less future-proofing.

That said, this protocol will not transition to production-readiness until a thorough post-quantum security assessment has taken place.

Post-quantum readiness is an open research topic that we do not have the resources to address alone; we are grateful for the offers of assistance with post-quantum readiness that we have received, and we welcome additional collaboration in this area!

Preliminary audit

In November 2023, we engaged cryptographic researcher Michele Orrù for a preliminary audit of the protocol and some of our claimed security properties, with a focus on the server state hiding and message unlinkability. The full report is available here, and a preliminary discussion of the findings can be found on GitHub.

Next steps

Astute readers will have wondered where the client side of this protocol takes place. We previously discussed the problem of browser-side encryption in “Anatomy of a Whistleblowing System”, and we’ll have more to say on this topic soon.

Later this year, we also expect to have the results of ongoing work on formally modeling the SecureDrop protocol, proving its security properties, and finalizing the specification for audit and publication.

In the meantime, we want to invite feedback from the security and cryptography community on this research. You can join our discussion list, write to us privately at <securedrop@freedom.press>, or get involved on GitHub.

If you have expertise in post-quantum/quantum-resistant cryptography, we’d especially like to hear from you!

Acknowledgments

This research has been funded by Freedom of the Press Foundation (FPF) and is being led by SecureDrop team member Giulio B. Davide TheZero and smaury from security firm Shielder SpA have partnered in the research effort. The audit of our proposed framework was conducted by Michele Orrù.

We’d like to acknowledge Michael Z for their core contributions to this work, both as a SecureDrop team member and as an independent contributor.

FPF's work on SecureDrop Protocol has been made possible by funding from the Filecoin Foundation for the Decentralized Web (FFDW). We are deeply grateful to FFDW for their support.

We would also like to thank the following people:

Stuart Haber
Jennifer Helsby
David Liu
Olivia Murat
Guillermo Pascual Pérez
Paul Rösler
Eleanor Saitta
Jacob Young

Appendix

Additional resources and links

• Lua server demonstrating another example SecureDrop Protocol implementation
• Slide deck from SecureDrop presentation on deniability
• Audit report
• Original proof-of-concept repository based on the Signal Protocol

Timeline

• October 2020: First commit in https://github.com/freedomofpress/signal-protocol
• November 2021: Working demo of https://github.com/freedomofpress/securedrop-signal-poc
• January 2022: Internal open discussion on the code integrity problem; JavaScript discussion and necessary steps for any end to end encryption
• July - October 2022: Various team meetings, discussion advances
• January - February 2023: Initial proof-of-concept development with Shielder, first external feedback requests
• October 2023: Final version of the message delivery protocol
• November 2023: Team members participate in IETF; initial outreach to cryptographers
• November 2023: Engaged Michele Orrù for the audit
• January 2024: Audit report, ongoing outreach to and collaboration with cryptographers