[Now Implemented!] Support For Untrusted Encrypted Node.

[laurens]

It is possible and it will be released. Don't have exact schedule for this though.

Great! This is the single feature I was missing! Can't wait to have this! Amazing, thank you!

[sabotrax]

Very nice kos13!

[pascal257]

Awesome, this would make btsync perfect!

[Haravikk]

This is something I posted on the wishlist and would very much like as well.

While I understand that there are various ways to setup sender-side encryption, this is one of those of things that is just more elegant if it can integrated into the app itself. I like having my synced folders be just normal folders with files that I can just manipulate normally, the best solution I've found for encrypting data in unsecured sync services is to use a banded (backed by multiple smaller files) disk image as this hides any information about its contents and can provide encryption. The only problem is you need scripts or other tools to properly handle mounting of the image and ensuring that only one peer has read/write access while others use a read-only copy, for example, to prevent conflicts that destroy the disk image.

I think the idea of store-only key would be ideal. Preferably this would function like a public key, while a read-only or full permissions key will function like the private key. So by giving a peer a store-only key they will receive encrypted chunks with no knowledge of the files they belong to, and simply store these in any reasonably efficient format for quick retrieval. Any peer with a read or read/write key can then request chunks from the store-only peer, and decrypt them before writing to the correct file.

One thing I like about the idea is it opens up the possibility of services that, when given a store-only key, will function as peers in your network, without any knowledge of what you're sharing, while only those with read or read/write keys can see anything of the original contents.

[raveur]

+1 Would love to give backup space to my friends and family.

I just wanted to add that there is precedent for this in existing backup solutions:

• Time Machine lets you encrypt to Time Capsule (or other server)
  
• CrashPlan lets you add a password as well when backing up to friends. (By the way, CrashPlan has a nice restore feature called Guest Restore where you can enter a password to decrypt and access specific files from the target computer)
  

[Quinist]

This is going to be a killer feature. An additional "encrypted read-only" secret would be so much cleaner of a solution than the various Truecrypt/EncFS workarounds. Thank you in advance!

[aguearde]

I would like this feature as well. I think it would actually be more disruptive than BtSync itself.

[bradbamford]

It is possible and it will be released. Don't have exact schedule for this though.

 

Is there any update on this, or a public roadmap ?

[nils]

Is there any update on this, or a public roadmap ?

It exists already, the encrypted secrets can be created through the API. The only feature missing is the decryption of the encrypted node's data in case of an emergency recovery.

[bradbamford]

It exists already, the encrypted secrets can be created through the API. The only feature missing is the decryption of the encrypted node's data in case of an emergency recovery.

 

So, Please forgive my ignorance, let me see if I understand this.

Using the API I can create an encrypted secret that I can share with someone else.

They enter it into their BTSync Client and my data will be stored there encrypted, but without any way to decrypt it ???

btw, where can I find more information about this outside of this thread? Thanks 

[nils]

Using the API I can create an encrypted secret that I can share with someone else.

Yes.

They enter it into their BTSync Client and my data will be stored there encrypted

Yes.

 but without any way to decrypt it

yes/no. Your friend won't be able to decrypt your data, unless you give him the RW or RO secrets of the share. What I meant was: in case of a disaster i.e. your laptop caught fire and the server you have running gave up its ghost at the same time, you would NEED to have at least an RO secret at a third location, with which you then can set up a new client and your data would be synced back.

 

btw, where can I find more information about this outside of this thread?

http://www.bittorrent.com/sync/developers/api

 

HTH

[lolcat]

I would really like to start using this feature, unfortunatly the only way I have found to obtain the "encryption secret" is from some blog post (seems rather unsafe, as he could be storing it all himself). Each user getting their own API-key seems extremly tedious, then you have the option of making a closed soruce program to do it, but then you would still have the problem with trust.

I have applied for the API key, hoping I can make a usable GUI that works on Linux/FreeBSD, and preferably can be used to manage more than one node (it seems rather tedious to add the keys to several nodes that I myself control).

[tlr]

+1 I would love this feature.

 

Power users could spin up a VPS without worrying too much about securing it, average users could sign up for 3rd party services to do it for them without worrying about the provider stealing their data, etc.

[dekaluti]

Hi, im trying to use encryption for a client with the API. My process ist to use get_secrets with the type encryption to get all three keys. and then to add folder with add_folder and a read_write secret. So far it works, but there is a problem if i decide to create keys with a custom read-write secret bigger than standard. get_secret returns then only the same read_write and read_only secret, but not the encryption secret. Why is this so ? I would like to have larger keys and be able to encrypt it on remote server. Am i doing something wrong?

Best Regards, Deka

[RomanZ]

Hi Deka,

 

Please don't use custom long secrets with API. It is intended to work with standard 20-byte secrets.

[haberjr]

For encrypted backup to other computers that you don't want others to read, I highly recommend Crashplan. The free version allows you to use computers and disks from friends and family ad colleagues all over the world. Encryption takes place before sending and during transmission and at the endpoint it is encrypted. The recipient cannot read it unless he has both your account and your password.

 

Syncing is something else than backing up.

[PeterVerhees]

Hi Deka,

 

Please don't use custom long secrets with API. It is intended to work with standard 20-byte secrets.

 

Hello RomanZ,

 

Are custom secrets ever going to be supported by Bittorrent sync?

I'd like to double the length of the key and use a custom entropy pool.

[RomanZ]

Hi PeterVerhees,

 

Custom secrets are supported in BTSync, but not in API. In BTSync you can put custom secret encoded in base64 with length of 40 symbols or more.

 

For API you can use custom entropy pool to generate 20 byte binary, encode it to Base32 and add a prefix symbol "A" for RW secret, "D" for RW secret with encryption.

[wimbit]

> I would like this feature as well. I think it would actually be more disruptive than BtSync itself.

 

For sure a winner!

 

1) Solves the unencrypted NAS problem.

2) Solves the untrusted node problem.

 

Then, our family and friends all over the globe can act as nodes for each other.

 

Please please please do this soon!

[wimbit]

I tried longer than 40 secrets on my windows 7 btsync and it crashed without an error message.

[GreatMarko]

I tried longer than 40 secrets on my windows 7 btsync and it crashed without an error message.

 

What version of Sync are you using? If it was 1.2.82 there was a known - and rather strange - issue whereby the presence of the number "9" in a secret would could Sync to crash!

 

This was fixed for 1.2.87/89, so either update to one of those builds, or remove any "9" digits from your custom secret - that will hopefully resolve your issue!

[wimbit]

I am on 1.2.82. When I  "check now" it says I am on most recent version??

[GreatMarko]

I am on 1.2.82. When I  "check now" it says I am on most recent version??

 

"Check For Updates" hasn't yet been "turned on" for every beta build. You can manually obtain 1.2.87/89 via the main download page.

[wimbit]

Thanks for the help GreatMarko. FYI - The page delived 1.2.87 but it says 1.2.82 on the page.

Bzzzt. Same error. It works to add folder with long password. Then, when open sync preferences for folder, it crashes.

[RomanZ]

Hi wimbit,

 

BTSync crashes due to weak secret validation mechanism. This issue is solved in upcoming release.

 

I suspect that you put some illegitimate symbols in your secret or just did not base-64 encode it.  Let me show you an example.

 

Here is the secret (without quotes):

"1234567890!@#$%^&*(),./\';][=-qwertyuiop"

If you put it into BTSync, it will either crash due to bug in validator or refuse to get such secret. However, if you encode it to base64 it is going to look like (again, no quotes):

"MTIzNDU2Nzg5MCFAIyQlXiYqKCksLi9cJztdWz0tcXdlcnR5dWlvcA=="

And is going to work. Base64 format is 30% longer than binary, but it contains only printable characters (letters, digits, and + and = signs).

 

Please make sure that the custom secret you add is base64 encoded. You won't be able to adjust it in UI due to crash which will occur when you open a folder properties, so simply remove folder from BTSync UI and add a new one.