Is It Possible To Have "dumb Nodes" That Just Serve Non-Decrypted Copies Of The Files.


benguild
 Share

Recommended Posts

Question for you all:

Love the product, but what I'm wondering is if it's possible to configure the software to only *serve* the content from a destination (ie. a colocated server) but not actually decrypt it?

 

For example, if hardware is stolen, compromised, or recycled... it'd be nice to serve it only from a destination that will never need to access the actual data. It would also reduce distribution of private keys.

Please let me know, thanks!

 

_____________________________________________

 

edit: I was poking through the documentation and I saw this:

 

 

API users have an additional option to generate folder secrets with encrypted peer support.  Encryption secrets are read-only and make sync data encrypted on the receiver’s side (peers can sync files, but can not see their content or modify them). Such secrets are useful when syncing to an untrusted location.
 
... This sounds like exactly what I'm wondering about. Is this pretty foolproof, or is it possible to run into issues where these peers might become unsynced with a future release if just left there indefinitely? Or would they offer an indefinite backup?
Edited by benguild
Link to comment
Share on other sites

Remember, most non intel or amd cpus doesn't support hardware encryption and will be under heavy load if they're on a RO or RW where there's a ENC key involved.

 

Got it, so basically if there's an encrypted "peer only" client then the BitTorrent Sync iPhone/Android Apps will have to decrypt it on its own when receiving content from it and it'll eat battery?

 

But an Intel desktop/laptop machine will be fine with it since they support hardware encryption?

 

OR, do you mean that the encrypted "peer only" client will be under heavy CPU load because it's receiving/serving encrypted data?

Edited by benguild
Link to comment
Share on other sites

It will drain battery yes. But even if the android is RO and there is another client that is ENC, the android will encrypt the file before sending it. So it is not a good idea. But to have android as ENC wouldn't slow down. But that wouldn't be very useful...

 

Got it... so don't open any large files on a handheld?

The ENC peers shouldn't be doing any encryption/decryption, no? (since they shouldn't have the actual keys)

Link to comment
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.

 Share