[clug] Cloud + rsync + backup

[Paul Harvey]

On 3 August 2015 at 12:51, Eyal Lebedinsky <eyal at eyal.emu.id.au> wrote:
> On 08/03/15 12:07, Paul Harvey wrote:
>>
>> I'm a huge fan of bup [1], but haven't played with any of the hacks
>> which add encryption (Eg. [2]).
>>
>> I've been meaning to look into ZBackup [3].
>>
>> Crypto is easy to get wrong, I tend to avoid file-level encryption.
>
>
> What do you mean by this? What level do you prefer? The smaller the

I should have clarified: crypto is easy to get wrong, choose your
tools wisely (if it matters). Perhaps for personal usage where our
threat model is simply "mitigate the case where I lose control of my
Dropbox account with all the family photos", any old solution will do.
But we've seen a fairly continuous parade of flawed crypto over the
years in otherwise well-meaning projects.

As for the "level" I prefer: Well, don't get me wrong - no single
choice is the best. Full Disk Encryption does its job with far less
fuss and configuration thought, thus has fewer failure modes, and is
easier to get right. But then again, FDE can only protect you when the
filesystem is not in use, ie. if you've booted up and mounted,
LUKS/TrueCrypt/etc. are essentially worthless.

On the other hand, file-level encryption offers some great benefits,
namely much better granularity than "all-or-nothing" of FDE: you can
choose different keys for different categories of sensitive stuff,
which reduces your exposure if you're only "unlocking" certain files a
few times per month, rather than close to 24hrs per day as with FDE.

But file-level encryption has traditionally not fared well when held
up to scrutiny - thinking mostly of EncFS here. EncFS has some
fundamentally irredeemable flaws (metadata, eg. datetimes, sizes,
path/filenames aren't protected) which may be addressed in
alternatives, but then I'd have to study them to find out (apologies
if I'm wrong here and using an invalid generalization).

But EncFS is one of the very few open source projects apart from
TrueCrypt that's actually had a professional, paid audit [1]. So I
assume it has a much greater maturity than alternatives. Yet it didn't
fare so well:

- It used unorthodox techniques (we shouldn't needlessly "swim outside
the flags"; stick to well-analyzed and published techniques)
- Block IVs were too small and and use easily predicted block IDs as input
- It used too-small MACs that are easily forged and also subject to
timing attacks
- It may be subject to chosen-plaintext attacks, Eg. by comparing
before/after dropbox sync
- MAC is trivially disabled by an attacker

Now, I don't pretend to even half understand much of cryptograpy at
the best of times. But there is a lot to get right. Can you be sure of
the tools you're using? That's all I'm asking.

> encryption
> unit the better the recovery from damaged files, and the less volume is
> changed
> with any cleartext change. So I assume you prefer block level encryption?
>
> An aside: How safe is encryption when you have many files in both cleartext
> and
> cypher. This is the case when system files are included in a backup.

I try to keep things simple. I don't really consider file-level
encryption to be "simple" - there's a lot to go wrong, from
integration mess to key management to worrying about whether my
super-secret-documents are being edited by clumsy software which
leaves plaintext temp/swapfiles lying around, rendering my encrypted
versions a waste of time.

But file-level encryption is unavoidable, simply for the granularity issue.

So my thoughts are really: if your data is only as important as "some
encryption is better than no encryption", then perhaps there's nothing
worth worrying about.

If you want to make a serious investment in your data security, it's
prudent to try your best to educate yourself on how your tools might
let you down, which might simply mean not relying on any one
technology.

[1] https://defuse.ca/audits/encfs.htm