PeterVerhees

[Now Implemented!] Support For Untrusted Encrypted Node.

Recommended Posts

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!

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

+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)

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

+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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.