3 ms·

> In addition the untrusted device must not be able to modify, remove or introduce data by itself without detection. It sounds like that property is satisfied

by comex 3y ago

> In addition the untrusted device must not be able to modify, remove or introduce data by itself without detection. It sounds like that property is satisfied on a file-by-file level. But what about between files? Can the untrusted device delete some files without it being detected? Or un-delete deleted files? Or selectively revert files to older versions? The documentation describes how each file gets a signed blob containing the file’s metadata and hashes of its contents, but there’s no mention of any signed structure containing the state of the directory tree as a whole. So judging (only) by the documentation, it sounds like the answer to all of those questions is yes. YMMV on how big of an issue that is. It helps that the attacker theoretically shouldn’t know which file is which. But imagine, say, a Git checkout of an open-source codebase being stored in a Syncthing folder. The attacker can guess which file is which based on file sizes and modification patterns. At that point, selectively reverting files might be able to mess up the code being stored, or associated configuration, in a way that creates some sort of vulnerability. Apologies if I’m misunderstanding the security guarantees; again, I’m only going off of what the linked page says.

whatevaa 3y ago
You are expecting too much. You want something like noise protocol (like Signal does for messages) but for files, plus guarantees of a blockchain. Ensuring deleted files are not kept is impossible. Use encryption containers such as Veracrypt, where all files is just a big binary blob, if you want that. Defining covered threat models would be useful, though.
ianopolous 3y ago
You might be interested in Peergos[0], where the server is treated as an adversary, and can't see file sizes, number of files etc. Everything is in merkle trees whose roots are signed. So not possible for a mirror to selectively remove a file, or add an old version of a file. They don't even know what constitutes a file. [0] https://github.com/peergos/peergos https://github.com/peergos/peergos

by comex 3y ago

whatevaa 3y ago

You are expecting too much. You want something like noise protocol (like Signal does for messages) but for files, plus guarantees of a blockchain. Ensuring deleted files are not kept is impossible. Use encryption containers such as Veracrypt, where all files is just a big binary blob, if you want that. Defining covered threat models would be useful, though.

ianopolous 3y ago

You might be interested in Peergos[0], where the server is treated as an adversary, and can't see file sizes, number of files etc. Everything is in merkle trees whose roots are signed. So not possible for a mirror to selectively remove a file, or add an old version of a file. They don't even know what constitutes a file. [0] https://github.com/peergos/peergos https://github.com/peergos/peergos