Verify files to detect (malicious) data changes

[petoem]

At point 3.1 Send Request (Metadata only) a checksum for each file could be send along, to enable the recipient to verify the file. Depending on the algorithm used and file size this could take a while to compute both before send and after receiving. I think this should be an optional preference (globally or before each send) and cancelable (on the receiving side), so it doesn't impact users with for example big files or slow phones.

[notjedi]

doesn't TCP already support CRC checksums? should we really need to verify it ourselves?

[petoem]

You are right.

I was initially thinking about cryptographic hash functions like sha256, to guard against malicious changes to files.
But because only self signed certificates are used here for HTTPS, it's unknown who we are sending the metadata to (including the proposed hash/checksum). So I settled on at least catching some errors that may happen at the receiving side.

Actually, the current random fingerprint in the announcement, could be the self signed certificate fingerprint. This way it's possible to verify who the file is send to and guard against MITM attacks. And if the certificate is persistent, it's possible to remember known devices.

[petoem]

Looks like v2 (PR #5) will set fingerprint to the certificate hash, which will make it harder to impersonate and maliciously change files at transmission once this is implemented.

[petoem]

I'll close this for now. Feel free to reopen.