dfens

Thanks, that pretty much sums it up. So basically it is working, but not readily documented at this point and not pushed by the developer (since it doesn't seem to be implemented properly in the main client). I get how "to get it working", but is there any information on how the file encryption actually works? As i understand it, the normal modus operandi is to use a cryptographic one way hash of the secret for adressing and use several keys for authentication and access control. Transport encryption - is it based on session keys or based on the actual secrets? I didn't find any documentation on how the actual files on the "encrypted secret" node are encrypted, stored and exchanged. Now the obvious question to me is: with what keys are the files encrypted that are stored on the encrypted node? They can't be encrypted based on the master secret i assume, especially in light of: "If you are concerned about security, BitTorrent Sync provides opportunity to regularly generate new Secrets for a folder, or replace an existing secret with your own Base64 string more than 40 characters long. The new folder secret should be re-entered on all the devices in sync." If the files in transit are encrypted using the 20 byte master secret the encrypted node could just store the encrypted file, though that would open another can of issues. If it uses a key that is derived, the question would be - how? Reading through thee forums i get the impression: Master key -> 20 bytes randomly generated -> beencoded -> Master Secret - used for addressing AND encryption/decryption edit: apparently this is wrong, the read only key is always generated and the hash of a part of the read only key is used for addressing Read only secret -> derived from Master key (edit: apprently a sha256 hash of the masterkey), split addressing and encryption/decryption key Encrypted secret -> part of the read only key, probably the part that gets hashed for addressing, but lacking the decryption/encryption key edit2: apparently the announce hash is a sh256hash of the readonlykey so basically sha256(addressing part of sha256(masterkey)) So it seems that for the read only key addressing and decryption was decoupled and only the former is used for the encrypted secret. One argument that was made by the BT folks was that the encrypted secret is not in the client because it would add additional load on embedded systems. However as far as i understand it, the systems that store encrypted files don't do any cryptographic operations and the systems that transmit files have to do transport encryption anyways. Added workload would only happen, if there was an extra layer of encryption, that doesn't use the transport encryption but works with derived keys that would have to be persistent on the encrypted node ala MEGA. Is there any documentation or observations concerning this? @CrisH: those DMA based forensic tools are not really sophisticated nowadays, they are turnkey "plug and play" solutions that work for several DMA capable hardware interfaces, exspecially if you run a standard Windows or Linux Distribution.

is there any documentation on how encrypted secrets work?

I read about the btsync protocoll stack and it seems to me it has a significant design flaw that comes crashing down if you realize certain use cases. The btsync protocoll is designed to be secure in the scenario "trusted devices vs. everyone else". Realistically to have reasonable reliability you have to have either a.) have one private "always on" device with btsync that you control alone b.) have a server somewhere with btsync as "always on" device Option a.) is perfectly fine, option b.) with the current design isn't. Realistically a server in some hosting environment is no "trusted device" in that the server (which you don't own and don't ultimately control) has the same pitfalls as a regular cloud storage service: The provider can and may look into your files or may even be obliged to do so by law in certain cases. Technically this is very easy, since most offers today are based on virtualization technology. So the claim that btsync offers security advantages compared to "cloud providers" may be true in practical ways but not in a strict technical way. You can mitigate some risk scenarios by setting the device as "read only", but that doesn't help the issue that the provider may look into your files (since btsync needs "a" secret to operate). I therefore propose a protocoll change: decouple addressing and encryption key. That would allow the b.) scenario to work with just the addressing key in a "zero knowledge" operation mode. It would allow the operation of an "always on" reliability node/device in some cheap hosting environments without the security pitfalls currently associated with it. Regards, dfens Nevermind, i just realized (from the meagre documentation) that btsync apparenly doesn't encrypt the files at all but just the transport of the files between devices. Still the protocoll should implement a modus that allows a non-trusted device to participate in a secure manner.