Secret Sharing Concerns

[milesrotaru]

I have a few concerns about the way BitTorrent Sync handles secrets, and I'd like to know if the developers plan to address any of them in the future.

There's no built in way to share secrets securely. A non technical person would be tempted to just send out the secret to their peers via IM or email, which is horribly insecure. The only safe way I've thought of to handle this is some other encrypted channel or a scheme involving PGP. Some implementation of PGP encryption built into the program for the purpose of exchanging secrets would be great.

Secondly, secrets are poorly protected. I'm only using BT Sync with people I trust but what if one of my peers leaked the key? Everybody I'm syncing with can see the secret and share it however they wish, possibly with someone I don't want gaining access to the shared folder. I'd really like to see a concept of folder ownership, along with authentication. To go along with that, some security features like getting a notification whenever a new user joins using my secret, and the ability to deny access. How can I know that a person using the secret I gave out is actually the person I originally gave it to?

BT Sync would be awesome to use with other people over the Internet but I'm nervous about that for the above reasons. If any of this in the future development plans for BT Sync? And are there any workarounds I could try in the mean time? Thanks in advance.

[Zbig]

Are you aware of the one-time secret feature?

[milesrotaru]

Are you aware of the one-time secret feature?

Are you suggesting sending out new one-time secrets every 24 hours? (or some other interval) That would be pretty good if there was a way to automate it. The usage scenario I have in mind is long term folder sharing with a small number of peers. The only way I can think to handle that with one-time secrets is to manually generate and send one out via encrypted email every morning, which my peers would then manually copy and paste into the program. It would be a security improvement I guess but not an elegant solution.

Maybe with an API I could set up something cleverer.

[Camaban]

One time secrets aren't "You'll only be able to sync for 24 hours" but "You'll only be able to use this to join our mesh for 24 hours"

[milesrotaru]

One time secrets aren't "You'll only be able to sync for 24 hours" but "You'll only be able to use this to join our mesh for 24 hours"

Ooooooh. I misunderstood how those work. Thanks!

Could a person I shared a one-time secret with invite more people to the folder? I'd really like to maintain control of the folder without restricting people from adding files.

When connected, a folder added with a one-time secret will receive a permanent master or read-only secret from the device where the one-time secret was generated.

Even though sharing a one-time key seems a lot safer it looks like the recipient still gets the master secret and could then do something stupid like let it get stolen. If there was something like a personal master password for viewing for viewing or changing your secrets, which were encrypted, that would at least prevent accidental leaking.

[Camaban]

I'm actually not sure. I hadn't tried it. From the name, you'd assume so, but it's best to test first.

All I can really say for certain is that it won't work after 24 hours.

It's probably worth having a look at.

Edit:

"For security reasons, you may not want to share a master secret. In this case you can create a one-time key that can be used only once and expires after 24 hours. This can either be a full access or a read-only key that is created on the base of the master secret. After the one-time secret is entered, the device will receive a permanent full access or read-only secret for the sync network."

[Zbig]

I think if you'd been given a read-only secret, you cannot actually see it in plain text anywhere in the client. This, combined with a one-time, read-only secret, provides some reasonable level of security as this way you don't get to see the "master" key at any time.

Anyway, look at it from a different perspective:

Even if there was a very fine and granular access management system with personal, user-bound and tightly controlled keys, what stops the malicious user from spawning another "cloud" pointing at the very same folder and giving the key to it to whomever they fancy? ;-) Okay, maybe there are some minor technical difficulties like the .Sync metadata folders already there but the bottom line is if someone has write access to your stuff and is determined to do something nasty, there's little you can do about it.

BTW, you can actually change a secret, denying access to all the currently synced nodes until they update the secret in their clients.

[milesrotaru]

Good point, Zbig. I also suppose if someone had enough access to a machine to steal the secret for a shared folder, they could just as easily steal the folder itself. One could share a Truecrypt volume to get around that but I don't think BT Sync hashes files in small chunks and sends only the changed parts like Dropbox does.

[Camaban]

I believe that's on their to-do list. But yeah, given that this is an alpha, I'd imagine a lot is on their to do list.

[Zbig]

Good news, BTSync uses 4MB blocks and as kos13 from the BitTorrent team stated on this forum, it supports TrueCrypt containers well (due to the data patterns not changing their position within the file).

[Camaban]

Oh so it will only update what's been changed?

Sweet.

[milesrotaru]

Good news, BTSync uses 4MB blocks and as kos13 from the BitTorrent team stated on this forum, it supports TrueCrypt containers well (due to the data patterns not changing their position within the file).

Sweet! I couldn't find any confirmation of that earlier. Good to know.