Closed eaon closed 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.
Basic testing done, working as expected. Fixes #10.
It turns out the codebase already distinguished between
file_id
andfile_name
, both of which are randomly generatedsecrets.token_hex(32)
values. This adapts the use of these variables, makingfile_id
knowable by the source, and changesfile_name
to be used to access/delete a particular file.Journalists create a signed map of
file_id
andfile_name
key/values, which they share. Any long-term journalist signature is verified by the server, adding the respective mappings as members to thefile_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/privatefile_id
/file_name
map.Notes
file_name
for file-system names andfile_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.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 learnfile_name
)