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 d
-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-back
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
passp
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 i
-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 probabili
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?
--
You received this message because you are subscrib
