freedomofpress / securedrop-protocol

Research and proof of concept to develop the next SecureDrop with end to end encryption.
GNU Affero General Public License v3.0
47 stars 1 forks source link

Attack on indistinguishability: server excludes some journalists when keys are fetched #56

Open lumaier opened 2 months ago

lumaier commented 2 months ago

When aiming for indistinguishability between messages sent by sources and journalists (from the server's point of view), one must also consider the information leaked by the number of messages sent by each participant. Specifically:

Sources receive keys from the server for $k$ journalists and send $k$ messages to the server (one for each journalist).

The behavior of journalists is underspecified. Assuming that journalists fetch keys as well (to mimic the sources' behavior), they send $k-1$ messages to all other journalists, excluding themselves, and 1 message to the source (using the keys received from the source's submission). Hence, if the server behaves honestly, the journalists also send $k$ messages.

Attack

The server can now exclude one journalist when returning the journalists' key material. If the fetcher is a source, the server will receive $k-1$ messages with probability 1. If the fetcher is a journalist, the server will receive $k$ messages with probability $\frac{1}{k}$ (when the fetcher is the excluded journalist) and $k-1$ messages with probability $\frac{k-1}{k}$.

(The winning probability can be increased to $\frac{1}{2}$ by excluding half of the journalists.)

Solution

Sources will always send $k$ messages. Journalists need to ensure that they also always send $k$ messages. I propose that, in cases where the journalist fetching the keys is excluded from the returned set of journalists, the journalist encrypts and sends a message to themselves. This way, journalists always send $k$ messages (which will eventually be fetched by someone — i.e., no dummy messages).

TheZ3ro commented 2 months ago

I like this attack subtle but still super interesting. The proposed solution seems pretty straightforward and easy to implement. keep up the good work @lumaier !

lsd-cat commented 1 month ago

Thanks this is very interesting, again!

Should we require newsrooms to sign a manifest with the current number of journalists every time the onboard or offboard someone? It does not seem like too much additional burden: we can force to ahppen when they have to use their signing material anyway to revoke (yeah this is not really in the protocol) or add journalists. This way client could check if the server is at least providing the correct amount of keys.

Indeed, when we consider journalist to journalist communication we should still send k messages and as such specify it.