Feat(fs): remote level encryption

[fbeauchamp]

do not merge befofre the july release

Check list

Check if done, if not relevant leave unchecked.

• [ ] PR reference the relevant issue (e.g. Fixes #007 or See xoa-support#42)
• [ ] if UI changes, a screenshot has been added to the PR
• [ ] documentation updated
• CHANGELOG.unreleased.md:
  • [x] enhancement/bug fix entry added
  • [x] list of packages to release updated (${name} v${new version})
• I have tested added/updated features (and impacted code)
  • [x] unit tests (e.g. cron/parse.spec.js)
  • [ ] if xo-server API changes, the corresponding test has been added to/updated on xo-server-test
  • [x] at least manual testing

Process

1. create a PR as soon as possible
2. mark it as WiP: (Work in Progress) if not ready to be merged
3. when you want a review, add a reviewer (and only one)
4. if necessary, update your PR, and re- add a reviewer

From the Four Agreements:

1. Be impeccable with your word.
2. Don't take anything personally.
3. Don't make assumptions.
4. Always do your best.

[fbeauchamp]

Forum post draft :

Hello everybody

Following our blog post, here is the preview of remote level encryption. For now, the algorithm can't be changed and it's AES 256 CBC, we use an initialization vector per file.

To activate it, create a new Remote, add an encryption key ( hexadecimal, 32 char) , and you're good to go. For reference , here is an encrypted remote : please don't use the same key

Please note that using remote level encryption mandate the use of vhd directory. It means that your remote will have a lot of ( can be millions ) small files and up to 16 concurrent writes per running backup.

On the plus side ALL the data ever written by XO will be encrypted before being sent, you can use an insecure network or remote confidently from delta to full backup , even all the metadata and temporary files.

This should work with any remote type

The current implementation compress and then encrypt the delta backup files. It gives use quite a nice efficiency boost (around 20-30% smaller files) but it can lead to easier key finding by a determined attacker. If you have rivals powerful enough to break AES 256 and willing to do it, you should disable compression in your config.toml by setting vhdDirectoryCompression to false . And also probably build a lair under a volcano.

Please tell us if everything is ok and what can kind of performance cost penalty you see , if any.

regards