Address and analyze the preliminary audit

[lsd-cat]

FPF has contracted @mmaker for a preliminary audit of a frozen version of the protocol (November 2023) at commit 2f32d0b

The report has been delivered at the beginning of January 2024.

The resulting report is attached to this issue.
securedrop report.pdf

We should keep track of the findings and address them and the improvement recommendations.

[lsd-cat]

From the report, we have 2 issues and 1 suggestion.

Issues

1 - Message Forgery

See #30: we would prefer not to sign messages (at least source to journalist) to preserve some form of deniability. It is relevant to note that message forging would need to know the identity of the recipient, in order to forge a ciphertext decryptable by them, information that by design should be hidden. We cannot have participation repudiation anyway due to the lack of key advertisement on the source side. Final choice yet to be made.

2 - Message replay

See #31: we already add timing information inside the encrypted envelope in the PoC, but that was not explicitly part of the specification. On the source side we cannot keep track of the messages already delivered due to the well known lack of state. Journalist side it should be trivial to detect replay attacks.

3 - Denial of service

Denial of service is a significant threat we have no way to mitigate right now (but it is also a very serious problem with current SecureDrop). We have no way to limit spam and users as Signal does by relying on phone numbers. We could think of captchas or proofs of work, but they would not deter a determined attacker but impaiur the user experience for everybody else.

Suggestions

1 - Server-side state storage using asymmetric PAKE

After serious consideration, implementing this feature would undermine our fundamental requirements of non-user enumeration and no concept of accounts. Furthermore, it would still not provide two way forward-secrecy against an attacker that has historical server snapshots.