What is the best way to password protect individual qubes as an additional safety measure on top of LUKS?
Is there a post quantum version of LUKS that is being thought of or implemented?
Thank you
1 Like
There is nothing “on top” or better to say 'after" the LUKS. After the LUKS nothing matters anymore.
This is an answer that reflects the fact you didn’t say what do you want to achieve, but how to achieve some step.
Adding a password to the users of the qube won’t make any difference as you can just mount them under Domain-0 and change the passwords easily if that is what you desire.
If you have the /var/lib/qubes partition set up as LUKS encrypted, then you have LUKS inside each guest as well, then you have 2 layers of security there.
If you are running the LVM version, then you would have to have LUKS on each guest, but this means that if you were to have different passwords per guest, you wouldn’t be able to use the template system.
LUKS can be broken easily enough if you use simple or short passcodes.
My encrypted partitions use a 2048 bit key to maintain security. But this isn’t for the average partition that has high usage. It’s only for those things that I need protected.
Using a 128 bit key would suffice for general usage. That’s a 32 character password that you would enter.
So that should be plenty.
If you are talking Quantum Computing (QC), then since it’s inception in 2007 you would then find that your passcode would be broken instantly and it wouldn’t matter what you set the passwords to. Since QC isn’t widely available at that level (yet) your codes and all should be relatively safe and secure for the time being.
If you have data you need to keep super secure, then you should think about storing it on a USB drive. And have another USB drive that has the key and have it as a 1 GB or more key.
Even just make it from a 16 or 128 GB drive.
So it’s just something to think about security wise. Add on physical security and separation on top of the software limitations using LUKS.
This is probably the best option if you are worried about data in your Qubes machine.
Quantum computers primarily threaten asymmetric encryption algorithms like RSA, DSA, and ECC. Experts predict that within the next decade or so, sufficiently powerful quantum computers could leverage Shor’s algorithm to break these widely used asymmetric schemes by efficiently factoring large numbers or solving discrete logarithm problems.
Symmetric encryption, such as AES (used by LUKS and VeraCrypt), is far less vulnerable. Quantum computers would apply Grover’s algorithm here, which reduces the effective security of symmetric keys by half, for example, reducing a 128-bit key’s strength to roughly 64 bits. However, this is not a complete break, and AES-256, commonly used by LUKS for full-disk encryption (FDE) in Qubes OS, retains 128 bits of effective security post-quantum. This level of security remains robust against both classical and quantum attacks for the foreseeable future.
That’s not entirely true. In the context of symmetric encryption like AES in LUKS, the strength does rely on the passphrase used to derive the encryption key, but the idea that quantum computing would “instantly break” any password is inaccurate.
Grover’s algorithm only halves the effective security of the keyspace, meaning brute-forcing remains computationally expensive, not instantaneous. To ensure post-quantum security with AES-256 (which offers 128 bits of effective security after Grover’s), passwords for symmetric encryption should have a minimum entropy of 256 bits to resist quantum brute-force attacks. It means that minimum password length should be:
- 39 characters if including lowercase, uppercase, digits and ASCII symbols.
- 43 characters if lowercase and uppercase letters and digits are used.
- 53 characters if only lowercase letters are used.
3 Likes
Thank you for the replies. My main concern is if my laptop is open, to have some extra data/apps on a qube that can not simply be started and everything is there. Have an extra security step. I know I could back it up with a password and then restore it every time but it would get annoying with updates and the whole backup/restore process doing that often would be unpleasant.
Very useful information regarding password lengths.
If your computer is open (after you enter your first passphrase, your LUKS passphrase), then everything is decrypted until you shut down your computer. Locking your screen will not encrypt it (technically speaking, the key is in the kernel, so it automatically decrypts data).
This is how full disk encryption works on all modern devices, and there is no simple way to improve it. However, you can use fscrypt, gocryptfs, and other file encryption mechanisms to encrypt your files in a qube.
You didn’t, and you won’t.
LUKS supports a maximum key length of 512 bits (technically not entirely true, but it is true for most cases). Your password is not the key. The password and keyfile go through a key derivation function to become the actual key, so any password that contains entropy greater than the key bit length is meaningless.
Um… That doesn’t make sense either. As I said above.
No, please. LUKS disables discard by default, which is necessary for the virtual hard disk driver to work efficiently. If you do not know how encryption works, please do not tweak it. Security is not something that can be easily achieved by simply adding layers of protection. You may harm your system.
Actually, if it is a true Quantum Computer then it would only take a second to brute force the passphrase.
If you are using 53 characters, that’s not many.
LUKS handles up to 512 characters to generate up to an 8 MB key. (Depending on your settings)
We will have to wait for them to test this on the Quantum Processor some day.
But since one processor takes up an entire warehouse, it will be a while before this becomes a viable option.
If people can’t log in to your laptop, then don’t worry so much.
If anyone knows how to get around things, then they will.
Even if someone gives me their oencrypted Qubes Drives, yes I could get around things and gain access. Would take a while, but I could. I have had to do it to my drive in the past, which is why I store the passcode on one USB and the key on another, but securely.
If you hit the maximum length of passcode of 512 chars then that is the best you can do for LUKS, but that is 8MB encryption key, best to keep it backed up somewhere as well.
When you leave your PC, you can set it so that when the system locks, it puts all the guests to sleep and then unmounts the /var/lib/qubes storage device, and that will then require the LUKS passphrase again, but that can be done when you re-mount the partition.
This will allow one bit of protection. Then once mounted, you just un-pause the guests and allow them to keep doing their thing and writing to the drives.
If they are unpaused without mounting, then they would crash.
So as you see, CHARACTERS for the PASSPHRASE is 512 chars.
Key can be up to 8192 kb, and I’m only talkign a 2 kb key.
Why doesn’t it make sense?
I see, sorry for my mistype. My bad for not explaining. Was thinking things as well as typing…
The drive has the key, and the drive would be 1GB or more with the key.
In other words just key storage, but not nessecarily in the 1 GB area as one string, but shifted amongst garballed data. But if you read from the correct sector then the sectors that they point to align to give the key.
I know how encryption works, I’ve been dealing with it for a very very long time.
I was around when LUKS was invented. So I have been using it for most of my life.
I’ve had encrypted volumes with encrypted images in it since I first started using virtualisation in Unix.
And yes it would be 2 layers of security, ebcause you have to remember tht the images are different “drives”.
Perhaps you need to do your research before you say anything further?
Security can be added by encrypting inside a guest as well as inside Domain-0 on the primary storage area.
Not saying it’s great security, but it’s better than plain text open drive.
1 Like
Yes, but I think what we are discussing here is “bits of the key”. Characters in the passphrase are not bits. The point is that any passphrase and keyfile will go through a key derivation function (regardless of their length) before they are used in symmetric-key algorithms as keys.
Passphrase --[KDF]--> Key --[Encrypt Algorithm+Plain Data]--> Encrypted Data
Most commonly used symmetric-key algorithms in disk encryption support a maximum key length of 512 bits.
The AES standard supports 256 bits, but due to the XTS operation mode, AES-XTS-512b is actually using AES-256 internally. I believe this is also true for Serpent-XTS and Twofish-XTS, which are available in LUKS as well. You can verify this by looking into /proc/crypto.
So you will never use a 2048 bit key for symmetric-key data encryption. Because there is no such algorithms accept it.
Let’s go deeper: Why does a too long passphrase or too large keyfile make no sense?
The length of the key directly affects the size of the key space.
Suppose a cryptographic algorithm has a key length of 256 bits; then the number of possible key combinations is 2^256. This means that, in the worst-case scenario, an attacker would need to try 2^256 possible keys to crack the encryption without any additional information.
As I mentioned, a passphrase is not the same as the key. If a passphrase contains more combinations than 2^256, the key derivation function will reduce it to 2^256 to match the algorithm. Therefore, if you use a 2048-bit long keyfile or passphrase, you still have 256 bits of security, not 2048 bits.
This is a valid point. However, an 8192 kB keyfile still provides 256-bit security, just like a 512-character passphrase or a well-chosen (randomly generated) 40-character passphrase.
Another thing: LUKS actually stores the real master key (the key used to encrypt data) in its header for each slot, encrypted by your passphrase. In LUKS 1, a slot is only 48 bytes in length by design, which is shorter than your 2048-bit (512 byte) passphrase.
What is the best way to password protect individual qubes as an additional safety measure on top of LUKS?
What does that protect from?
Are you sure Qubes use 256 bit by default?
The situation when an adversary got lucky to get access to your decrypted disk contents, but that would not be enough to go further and decrypt images that have secondary encryption. And there is multitude of scenarios when primary luks encryption may fail you. Maybe you main passphrase gets compromised, or else. Or would it be cold memory attack. Whatever.
The situation when an adversary got lucky to get access to your decrypted disk contents, but that would not be enough to go further and decrypt images that have secondary encryption.
IIUC, that situation would mean dom0 access, AKA on this forum as “game over”. If one can plant malware in dom0, that could sniff anything.
And there is multitude of scenarios when primary luks encryption may fail you. Maybe you main passphrase gets compromised, or else. Or would it be cold memory attack. Whatever.
Why isn’t the secondary encryption prone to the same?
Not implemented yet, but the comments might hint at some workarounds in the meantime:
Not necessary. Symmetric ciphers with sufficient key size are already quantum-resistant.
Yes, of course it does. You can check for yourself in dom0. First, find your LUKS device:
$ lsblk | grep crypt
Look for the device with crypt in the last column. It’ll probably look something like luks-<YOUR_UUID>. Then, view the encryption details:
$ sudo cryptsetup status luks-<YOUR_UUID>
type: LUKS2
cipher: aes-xts-plain64
keysize: 512 bits
[...]
aes-xts-plain64 with a 512-bit key = AES-256.
From https://en.wikipedia.org/wiki/Disk_encryption_theory#XTS:
[…] XTS-AES was standardized on December 19, 2007 as IEEE P1619. The XTS standard requires using a different key for the IV encryption than for the block encryption; this differs from XEX which uses only a single key. As a result, users wanting AES-256 and AES-128 encryption must supply 512 bits and 256 bits of key respectively. […]
2 Likes
As information security practitioner, I am strongly against black and white vision that cannot be proved by exhaustive enumeration of threat scenarios. “dom0 access” is game over only if you plan to continue to use this machine. Confidentiality and integrity requirements are not the same. Etc etc. I also would like to have several “deniable” VMs protected by extra password (I think it was discussed before). Your luks password or key may be compromised by multitude of reasons, and your secondary password could be not because it was not used at the moment of the attack.
I think all this was already discussed years ago.
2 Likes
@qubist is right. If anything/anyone gets into dom0, you’re done.
But @arkenoi also makes a valid point. Maybe it was pure coincidence that someone happen to come across your unlocked machine, and they weren’t prepared for the opportunity. If they’re really out to get you in a premeditated manner, and they had more time to prepare, of course they would have studied you, and crafted a “special payload” just for you. But maybe your unlocked machine caught them by surprise, and they just decided to jump in and nose around your machine.
Or maybe it’s someone who was just in the right place at the right time, and got curious, even for trolling (friends, family members, work colleagues, etc.)…
These are scenarios where this could prove reasonably effective, albeit relying heavily on pure luck…
But if you think about it, i’s not really the OS inside the qubes you’re worried about. It’s the files.
Things like GPG, CryFS, cryptomator, or would be well-suited to this use case, as long as the key is kept out of reach of dom0. And that’s a difficult thing to do…
Yes, files matter. But Qubes is about contexts. Say, I have a sensitive project I would not like to expose. It is not just a bunch of files. I want the whole Qube to be both hidden and encrypted.
“Keep out of reach of dom0” is not that relevant. What is relevant is possible attack sequence. What they would be able to do first and then.
Yes, if INTEGRITY of dom0 is compromised, you just stop using this machine immediately. I am thinking about attack scenarios where confidentiality is compromised, but the rest depends on if you have left some clues lying around dom0 or not. Stop thinking about mossad level “evil hacker compromised my dom0”. Think about someone who will able to confiscate your computer at customs point, or even break into your house. Or you even may be force to reveal your luks password (mandatory xkcd wrench reference here) This is more relevant threat model than hypothetical hypervisor escape attack chain crafted by NSA specifically for you.
And this scenario may imply that your luks password is not going to be safe and sufficient either.
The man asked about qube(s) and not about files. And then a lot of "IF"s took place, instead "WHEN"s. The latter would shorten this topic to a 3 posts.
Think about someone who will able to confiscate your computer at customs point, or even break into your house. Or you even may be force to reveal your luks password (mandatory xkcd wrench reference here) This is more relevant threat model than hypothetical hypervisor escape attack chain crafted by NSA specifically for you.
And this scenario may imply that your luks password is not going to be safe and sufficient either.
If someone can force you to reveal your LUKS password, why should he not be able to force you to reveal the rest?
What makes the second LUKS password more secure?
if the second one is deniable, it is all different story. and forced disclosure is not the only scenario.