Anonymity "Attacks" by Malicious Server

[felixlinker]

Hi everyone,

During discussions with @lumaier today, I thought of a new "attack" against anonymity by a malicious server. I deliberately put "attack" in quotes because I think that you did not plan to provide security guarntees in the scenario that I am about to describe. The "attack" rather puts concrete limits to SecureDrop's security guarantees.

Scenario is the following. A source submits a ciphertext to server. This will include the ciphertext $c$, the encryption public-key $g^r$, and the fetching shared-secret $g^{fr}$. The server wants to learn who this ciphertext is intended for. What the server can now do is the following.

The server wants to test whether ciphertext $c$ was intended for the journalist with fetching key $g^{f'}$. Someone starts the message fetching protocol. The server samples two IDs $id_1$ and $id_2$. Then the server encrypts...

• ... $id_1$ under $g^{fr}$ and sends the requesting party the corresponding ciphertext and $g^r$.
• ... $id_2$ under $g^{xf'}$ for a fresh key $x$ and sends the requesting party the corresponding ciphertext and $g^x$.

If the server receives a request for both $id_1$ and $id_2$ it learns that $c$ was intended for the journalist identified by fetching key $g^{f'}$ (i.e., $f' = f$). I believe that this "attack" should scale very easily by submitting multiple IDs in style of $id_1$ and not just one.

As I said, I expect that you did not expect anonymity guarantees to hold when the server does not follow the message fetching protocol. Feel free to close this issue immediately! I just wanted to share our findings with you. Luca will certainly include this "attack" in his thesis, so you will find it documented elsewhere!

[lumaier]

Maybe adding to it, that when linked to issue #56 (i.e., all parties should send the same number of messages), SecureDrop should enforce that all parties send $k+1$ messages (i.e., to all $k$ journalist and itself). This way, there is always a ciphertext intended for one of the journalists and one ciphertext for a source (for which the server doesn't know the fetching key).

With that, this attack is no issue. The server learns that a ciphertext is intended for a certain journalist. But its a priori knowledge was "one of the ciphertexts is intended for this journalist". Knowing which ciphertext should not be a problem...