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

Disallow sources to access or delete their own submissions #13

Closed eaon closed 8 months ago

eaon commented 1 year ago

Basic testing done, working as expected. Fixes #10.

It turns out the codebase already distinguished between file_id and file_name, both of which are randomly generated secrets.token_hex(32) values. This adapts the use of these variables, making file_id knowable by the source, and changes file_name to be used to access/delete a particular file.

Journalists create a signed map of file_id and file_name key/values, which they share. Any long-term journalist signature is verified by the server, adding the respective mappings as members to the file_token redis set. This then allows the server to tell sources what they're allowed to learn (file_id) when submitting anything, while journalists can infer what they need to learn (file_name) when they receive messages or want to reply to a source. In the case of the latter, sources have to be told what they needs to know (file_name) by journalists without supplying other details of the public/private file_id/file_name map.

Notes

  1. I don't know if there was a significant reason for distinguishing between file_name for file-system names and file_id for database/remote access names, but as far as I can tell there is no need to hide on-disk file names from recipients. Happy to adapt if this is still something we want to continue to do.
  2. The base branch for this PR is messages-as-attachments (i.e. #8), as protocol symmetry is a key point of this change (even though it could be adapted to just not send replies as file uploads, i.e. the source would not need to learn file_name)
eaon commented 8 months ago

Closing this as it's overall more impractical than a public-key cryptography based approach (touched on in https://github.com/freedomofpress/securedrop-poc/issues/10#issuecomment-1785747992 although that exact line of thinking is also outdated) to solve this issue.