How secure is Qubes dom0 backup tool encryption?

102 views
Skip to first unread message

Patrick Schleizer

unread,
May 7, 2017, 1:37:29 PM5/7/17
to qubes...@googlegroups.com, Whonix-devel
How are chances that the encryption could be broken? How likely are
there issues with the implementation?

Should Qubes dom0 backup tool encryption be relied upon or would it be
more advisable to put backups on luks / dm-crypt encrypted disks?

Andrew David Wong

unread,
May 7, 2017, 1:49:19 PM5/7/17
to Patrick Schleizer, qubes...@googlegroups.com, Whonix-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2017-05-07 12:37, Patrick Schleizer wrote:
> How are chances that the encryption could be broken? How likely
> are there issues with the implementation?
>

I'm not aware of any reasonable methodology for providing answers in
the form of probabilities, so instead I'll provide a more subjective
answer: very low.

> Should Qubes dom0 backup tool encryption be relied upon or would it
> be more advisable to put backups on luks / dm-crypt encrypted
> disks?
>

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.

[1] https://github.com/QubesOS/qubes-issues/issues/971

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJZD14PAAoJENtN07w5UDAw53YP/jPuxBHObBT0d3Qk5KL8n9eY
4FM3dnF8HUi0PL4akN8HKb+QnAXq1HtPqLOzz0rJVjF0BbZDE6Dfcvvkmp6rr5zd
NbFgLRfPdPTQ7jrPnkilb90SqTeoJhihtKsroK0JM4ETicy55yyLITNYZU0nNViR
FlN3odTNesjWA3HT8Ig9HR7RfIupB6+VhC4MOarQHe2hoyaMUxwgNH0UBnCm6tAK
mSTbqGyBk0Pla45AC0246veoNlReUGDB56JOaHAisvJGShhlqzb0CC+57UEvPBwh
4eVkzcbZTQGe7txyfkYGiZ/DnJ/s6QOGeahclqnnSRgUKn6ZuuvmFSdthKbFCWpe
kboqWoatKjJXr2byUigaHaFEqQylHdX3eOokLL9VrCJRNqZtxoUYxNSyDJL/3fp3
8zuB6uKRxSEb29qJZRuBoMTzdH88XotdG3rxUvBWpkiGw92G2y7WFjH2HPfexfKi
0dTJ9sof/9V5Kyg1N2N2/B0p8Cd5lEuEay2UcbKL7RVeMAGzB2U7R/p9kUUcv5Cw
OY0rS/bSP9n3USPXZWvASkPM263Ue8RmUdyCdk35XAtlEURUCrfGMTZ0HkfKDoUH
W5h6XLG8tM8bIAkt1X8hbtom5G5w+hEFpmsobgYcpdBPIgqqui6F3iVmFoAblaTw
7/YB8/FSOQOd95lVIiEY
=OXtE
-----END PGP SIGNATURE-----

Peter Todd

unread,
May 7, 2017, 6:43:59 PM5/7/17
to Andrew David Wong, Patrick Schleizer, qubes...@googlegroups.com, Whonix-devel
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).

--
https://petertodd.org 'peter'[:-1]@petertodd.org
signature.asc

Chris Laprise

unread,
May 7, 2017, 6:52:54 PM5/7/17
to Peter Todd, Andrew David Wong, Patrick Schleizer, qubes...@googlegroups.com, Whonix-devel
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, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Andrew David Wong

unread,
May 7, 2017, 7:08:11 PM5/7/17
to Peter Todd, Patrick Schleizer, qubes...@googlegroups.com, Whonix-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2017-05-07 17:43, 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.

The main reason would be for offsite non-drive backups (e.g.,
file-based upload).

> 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).
>

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJZD6jPAAoJENtN07w5UDAw1hwP/2QLqHjdskGO+Gu9ZAwE6c8z
9iJle20bZ3tLVNc2lxSwmrm1xT3YxSpzpWEm6yvB5wTtYk6JEWN9F/Wx9PYiw+sz
uZBqsN/XWy1QtFWPa3+1hLg1jTBBObFGpdU6YGtEunI/hh3q8dHir9Cyii5DxwfA
gaomHyyu8EeMsPlBRex5NPdozWjd5dlugA+Eg9jUKcDZAiTYhTW6tG5KIKUn1RLF
oSv9VUa4fUl9nTWlI4SUcHDhmUBKSrFpG3jh8u26xQ9TDqZEIXSGXhQwm+zychFx
XeO0ucOKsAg4SXqcRHusj8fRj0564wPLYrWJYdZDsKpdFCe5aAHW3HHUF4+lVw+C
u4LDyJMh6iqGuyAidDZQUH5LOrApJryez/BS5DxcvKV7S5tKqu9RqbwDekgrhZhZ
83O/pEjZR0GeDAICuRIfGQTxRBjM3Awx684A2gdKnzDa+OIneoQ9OL0r62SmZ7Tt
ww0ySMtHmnPUbckh51qelLHvb+hJyjSqwFrq4ak/bEXHEyMLH23U2f1owgP2RUIl
l7aEiFUGxxYxWi0wGE1RSBJgXTe9hRzP8+nxD83oFqsmnjvxkvGp9E5KtaGEFNRa
H5aF7gmLcelHJHXRYNkvkhxPA7azGotCxOuJCNEtAixTcDI3CY/ID9fK9cxDvlaE
SVqRN62iZ34x7iDw3cFY
=ETLi
-----END PGP SIGNATURE-----

Manuel Amador (Rudd-O)

unread,
May 7, 2017, 7:22:05 PM5/7/17
to qubes...@googlegroups.com
On 05/07/2017 10:52 PM, Chris Laprise wrote:
>
> 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.
>
Agreed. That said, borgbackup onto a VM an then through SSH is about
four hours for an incremental backup, qvm-backup to a local disk (which
in principle should be much faster) is about eight hours. While I make
no guarantees about the integrity of a tampered borgbackup, the
performance math is clear.

I will publish the automation to do borgbackup on Qubes OS soon.

--
Rudd-O
http://rudd-o.com/

Reply all
Reply to author
Forward
0 new messages