Add clear statement of the desired security properties

[lsd-cat]

We started tracking that outside, as an effort for the ongoing audit. However, that should be a clearly explained and defined part of the documentation. I am informally reporting that content in this issues, with the idea to import and formalize that better as an iteration to this issues.

Summary
The server should act just as an anonymous message queue and should be completely untrusted, without requiring additional hardware features or components.
We expect the server to be able to drop messages; we thus assume this specific denial of service attack out of scope.
The server shall have no knowledge of the number of parties involved, message threads, recipients or sender information and any other non technically necessary metadata. The server is a holistic component and we can consider some mitigations architectural, and some implementation specific.

Key requirements
All messages are equal: all messages are indistinguishable between each other and do not have any unencrypted metadata. Messages are not correlable even if sent or delivered to the same user. Thus we must have indistinguishability between message ciphertexts, message public keys, and the partial message group diffie hellman which are the 3 fields stored in the server database for each message.
There are no user accounts, login protocol or information: anyone can submit messages.
Users must be able to fetch only their own messages and know the existence of messages only if they are the intended recipient.
Users on the internet must learn nothing about the state of the server, not the amount of messages, or if there is any message at all. Subsequent fetching requests should not be correlatable and should give out no information about state changes on the server.
Asymmetric parties: sources cannot have a client-saved state besides a mnemonic. Journalists can have plenty of storage.
The server must not be able to tell if it is interacting with a source or a journalist for messaging purposes. Requests to the server are self-contained and there is no need of a state: every API request, such as submission or fetching can happen independently from any other action.

Implementation specific mitigations
Decoy and mixing: the protocol architecture should easily allow the addition of mixing traffic, such as fake messages to and from fake parties. If we can get an equal access pattern for source and journalists better, otherwise we can attempt to fix that later with decoy, mixing, and client specific mitigations.
Browser based code integrity verification: the server will be serving a Javascript/WebAsm based client to sources. The sources’ browser will verify the integrity of such a client properly. This is out of scope for this research.
Server in memory metadata: we can add implementation specific mitigations to avoid timestamps and similar metadata persistence, such as a timestamp-free fuse filesystem. However, we cannot prevent similar information from existing in memory at a certain point in time.

Attackers
Anonymous user on the internet
An anonymous user on the internet should learn nothing about the state of the server, including whether there are new messages, if there are messages at all, if there are users, etc.
An anonymous user on the internet should learn nothing about state changes on the server. If there are no intended messages for the user who is attempting to fetch messages, every server query for fetching should be indistinguishable and the same whether there are 0, 30, 100 messages.

Server at rest
The messages (and eventually attachments) are stored persistently on the server disk. Obtaining images of such a disk must not disclose more than: the existence of messages, the encrypted envelopes or non decrypting keys of the messages (so the public key of the message and the group DH), the number of messages. Multiple images over time can disclose the change of state of information, so what messages have been added or deleted, the change in the number of messages over time.
The server must not be able to correlate messages, even with active attacks. It must not be able to link messages to source or journalist keys. It must not be able to correlate messages with each other (such as, a reply to a specific submission).

Server in memory
An attacker who has access to the server memory, or even a history of it over time, must not learn anything about the messages, besides the existence of the messages and eventually their (individual) download, or submission or any direct action that the server must perform to complete its duties.
The protocol implemented now allows for message discovery on the client side and messages are intended to be downloaded using the message id individually. Thus all fetching requests should look the same and all download requests should look the same.

Source
A source must not learn anything about the state of the server. They must be able to fetch only their own messages.
They cannot know if they have sent messages, even if their key material is compromised. (deniability)

Journalist
A journalist, when fetching messages, is in the same position as a source. From there, they must not learn anything about the state of the server, the number of sources and so on.
After fetching and decrypting messages, a journalist might keep locally the message information and track threads, conversation and sources. They must never learn anything about the origin, location, real identity, or any linkable metadata of the source.

Deniability
NOTE: when working on this, we did not know about non committing encryption (NCE).

“Accountless” properties, what we think we have now
From an attacker who compromise a source passphrase
Given the passphrase, if there are no pending delivery messages to fetch for the compromised source, then it should be impossible to know whether the source ever existed or not

From an attacker who has the latest server snapshot and a source passphrase
As before, if there are no messages pending delivery for the source, it should be impossible to prove whether the source exists or not

From an attacker who as multiple server disk snapshots, multiple server memory snapshots and a source passphrase
If the source never received a reply, it should be impossible to tell whether the source existed or not.

Forward Secrecy
In the source to journalist direction, given the use of ephemeral key agreement keys we expect to be forward secrecy is the journalist client properly discards used keys.

Limitations (known problems not to spend time on investigating)
As mentioned in the limitations in the README of the repository, we consider out of-scope or know to need mitigation in the implementation:
Journalist ephemeral keys exhaustion due to an anonymous attacker on the internet
Journalist ephemeral keys reuse due to a malicious server
Traffic analysis and request correlation linking together access patterns of multiple API requests
Source web-based client integrity verification
Message dropping/denial of service from a malicious server
Denial of service from an anonymous user on the internet who floods the server with messages
Denial of service from an anonymous user on the internet who floods the server with fetching requests