if the second one is deniable, it is all different story.
Why can the primary LUKS encryption be non-deniable, but the secondary is deniable?
The car is mine, I drive it every day, I give the keys to the police but I won’t tell them the password to start the engine, because it is deniable.
What police would buy that story?
and forced disclosure is not the only scenario.
I never asked whether it was. I am trying to understand the logic of all this.
Because if we design it properly, there could not be any proof that extra qubes even exist.
To confirm the default LUKS settings in Qubes OS, you can run this command in the dom0 terminal:
sudo cryptsetup luksDump /dev/<device>
This outputs the LUKS header, which will show something like:
LUKS header information
Version: 2
Epoch: 5
...
Data segments:
0: crypt
offset: 16777216 [bytes]
length: (whole device)
cipher: aes-xts-plain64
sector: 512 [bytes]
Keyslots:
0: luks2
Key: 512 bits
Priority: normal
Cipher: aes-xts-plain64
Cipher key: 512 bits
PBKDF: argon2id
...
This confirms that Qubes OS uses LUKS2 with the aes-xts-plain64 cipher and a 512-bit key by default. Here’s why this is equal to AES-256:
XTS Mode uses two AES keys: one for data encryption and one for tweaking (XORing) to ensure unique ciphertext across sectors, and the 512-bit key here is split evenly:
The actual encryption strength is AES-256 because the data is encrypted with a 256-bit key. The tweak key enhances sector-level security but doesn’t increase the brute-force difficulty beyond 256 bits.
So, yes, Qubes OS defaults to AES-256 for data encryption in its LUKS setup, as the 512-bit key in aes-xts-plain64 reflects this 256+256 split. This also aligns with NIST recommendations for resistance against future threats like quantum computing.
Sorry I didn’t check that the question was already answered properly. Mine was somewhat a repetition of the original answer.
Because if we design it properly, there could not be any proof that extra qubes even exist.
What is the proper design?
We can design the same for Qubes, as for qube, and it was written a lot about that here. But, when tortured, not many will persist denying.
The OP essentially asks to look the room, when someone broke his home. Or even more analog: to lock the box, when someone broke the vault.
This would be a dream. Have been using veracrypt with hidden volumes since truecrypt 7.1a and before… And I remember encrypting my whole windows with the hidden OS partition back in the day. That was a dream IMO. If something similar would be included with Qubes, I would be very happy.
I don’t see how this will work.
Dom0 access = access to everything that dom0 “is aware” of.
If dom0 (or a domU) is aware of existing hidden volumes/partitions, there is no possibility of denying. Otherwise those hidden things may get overwritten, assuming that is free space.
If the VM is entirely on a separate physical storage (not confiscated), then the whole exercise looses its meaning - that VM is already safe and one LUKS is enough. One can still be pressed to confess where the storage is though. So, I still think the main question is what does this actually protect from.
Additionally, all this functionality is discussed publicly and will be open source. What is there to deny? In fact, it may create additional problems, as every Qubes user becomes a suspect.
It makes much more sense to invest effort in per-qube memory encryption to make Qubes more resistant to side-channel exploits. (I don’t know if there any threads about it)
Just the same way truecrypt / veracrypt hidden volumes work. Come on, read the original thread! It is not rocket science or it is something new. Those things are basics known for decades.