Re: [tlug] Tuesday at THS: "Sync and share your data with Syncthing"?

[Curt Sampson <cjs@example.com>]

On 2018-03-07 08:59 +0100 (Wed), Kalin KOZHUHAROV wrote:

> On Wed, Mar 7, 2018 at 5:04 AM, Curt Sampson <cjs@example.com> wrote:
> > Possibly this could be mitigated significantly with the addition of
> > at-rest encryption by using the Syncthing volume as the underlying
> > storage layer for [eCryptfs] or something similar. (I'm fairly
> > confident in the security of eCryptfs when used properly because it's
> > what Google uses to encrypt the home dirs of users on Chromebooks.)
>
> Encryption at rest in a cloud does little sense. A root compromise of
> your VM gets access at the files.
> For 24/7 systems there is no "at rest", it is not a laptop.

I don't think you got what I was saying. No, there is no way to
compromise the data (other than actually guessing the key) on the
cloud servers because the keys are not accessible to the cloud
servers, or anywhere in the cloud. The files are encrypted on your
local system and only the encrypted backing store is sync'd to the
cloud servers.

Encryption at rest in this way in the cloud makes a _lot_ of sense.

> Now, eCryptfs is actual file-level encryption, so having file-level
> encryption in the hosts, we shouldn't worry since only encrypted data
> is being synced and the key stays at the host (so worry is pushed to
> the endpoint, a scary thought).

Precisely.

> well, I also am thinking to run my "forensic storage" (hundreds of
> drive images, 1GB-3TB each) eventually on syncthing :-D
> Also, since most of those images are sparse, using eCryptfs is out of
> the question there (it has no support, os it will blow up the stored
> size) :-|

Just compress the files before putting them on the eCryptfs
filesystem. For large drive images you'd want to be doing that anyway
regardless of how sparse they are.

cjs
-- 
Curt J. Sampson      <cjs@example.com>      +81 90 7737 2974

To iterate is human, to recurse divine.
    - L Peter Deutsch