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.