Treat messages and metadata as attachments

[lsd-cat]

Following @eaon suggestion, this PR treats messages and metadata as attachments in the following way:

From the source side:

• A random key is generated
• Message m is encrypted using nacl.SecretBox
• Encrypted message m is uploaded through the /file endpoint
• Source sends the file_id and the encryption key to every journalist

Basically instead of sending the message and the metadata duplicated, padded and encrypted for every journalist we just send the retrieval information in an encrypted form. The same happens when communicating in the opposite direction.

Open questions:

• Does this worsen pattern behavior and helps linking fetching? Ie every journalist reading the same message will fetch the same attachment. However this was the case even before with attachments so I do not see this worsening it; we have to add decoys/countermeasures anyway.

TODO:
Readme changes will come in the next commits.

[eaon]

As I've continued working on variations of the protocol, I stumbled on the following:

Depending on the order-of-operations by different actors, sources may end up denying a subset of journalists access to message contents:

1. ✅ Journalist 1 sends a message to Source A
2. ✅ Journalist 2 checks messages, learns file_id, downloads message contents attachment
3. ✅ Source A checks messages, learns file_id, downloads message contents attachment
4. ⚠️ Source A uses their knowledge of file_id to delete message contents attachment
5. ❌ Journalist 3 checks messages, learns file_id, but is now unable to download message contents attachment

This applies to this PR as well as to #13.

The only countermeasure I've found so far that keeps journalist and source interactions indistinguishable from the server's perspective is uploading at least two message content attachments per message. In that case…

• Sources upload one decoy payload made up of random noise and another payload with the encrypted message contents
• Journalists upload two "real" attachments but distinguish between recipients:
  • → Journalists: enc(msg(file_id of message-contents-1))
  • → Sources: enc(msg(file_id of message-contents-2))

Edit: This is somewhat similar to #3

This could be sidestepped if deletion is an exclusively automatic process rather than an operation triggered by a user, however that would also hurt the deniability properties of the system.

Another aspect that should be considered here is that random noise uploads ought to be cleaned up in some way, requiring that journalists either have some way to learn about their file_ids through an authenticated request, to use that knowledge to implement automatic deletion on the client side, or the server would need to keep some metadata to be able to do that (again, hurting the deniability properties).