On 05/07/2017 06:43 PM, Peter Todd wrote:
On Sun, May 07, 2017 at 12:49:06PM -0500, Andrew David Wong wrote:
They're not mutually exclusive. You can do both.
I'm the one who reported the key derivation issue [1], but even I
think qvm-backup is plenty safe as long as you use a high-entropy
passphrase. (This will no longer be an issue when we switch to scrypt
in 4.0. [1]) I personally rely on it for my most confidential data,
and I'm confident that it's not the weakest link in my setup.
FWIW, personally while I frequently use qvm-backup, I always use the password
"a", and instead backup to LUKS-encrypted partitions formatted with BTRFS (for
crappy authentication via BTRFS's checksums).
I already rely on LUKS, so I don't see any reason to add another potential
vulnerability to my setup. For my usage pattern, I'd actually prefer an option
to completely remove both encryption and authentication to reduce CPU usage
during backups. Based on CPU load, this appears to be the bottleneck on many of
my machines (though this could be parallelized).
I believe the largest qvm-backup bottlenecks to be related to disk I/O.
For one, qb writes all data to a temporary file before sending it to the
destination. Second, it seems to inefficiently read all parts of a
sparse image file (although it does pack the file efficiently on the
destination) so a 40GB image with only 8GB used will take a long time to
process in relation to the space used -- these are the parts where the
CPU is busy.
Encryption should add very little to the backup overhead.
--
Chris Laprise, [email protected]
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/c49199ed-3136-1b23-d2db-8d0766089119%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.
