> Will Qubes Manager work fine if VMs will not be available at the boot time 
> or some time after that, before user will not mount container? 
Yes. I have R3.0, and some vm's are on secondaty, encrypted drive. I mount 
it using crontab like
@reboot /my/script/to/mount/encrypted/secondary/drive
I used this instruction <https://www.qubes-os.org/doc/secondary-storage/> 
to move appvms there. But I did it not in purpose of security, but just to 
have more disk space. I store the key to that drive in dom0.

How "quick" any of available super PCs (10,649,60 cores, 125,435. TFLOP/S 
> )  can find the password (e.g 8-16 chars) encrypted with Qubes default 
> settings cryptsetup? 

Encryption is the hardest part of chain. If the passphrase is long 
enough.If password is 16 random lowercase and uppercasr letters, then it 
is  52^16 combinations, it is about 10^27. If you can crack 100 Peta 
passwords/S, then it will take 10^(27-17) = 10^(10) seconds to brute the 
password, which is 316 years. (Really expectation is half of it, so 158 
years on average). Of course, if those letters are not "Password12345678". 

How can we improve security to prevent this? 

If 316 years is not enough, than you can add one more character, to make 
it  16 thousands of years!

Is it a good idea to install some 3th party software tat dom0 to make 
> crypto container to store some VMs and mount it before VM start? 

I don't think so. The more different tools you use, the more there are 
chances to use something wrong.

After all, there are much easier ways to get your data.  For example 
hardware backdoor called Intel ME.

You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to