Due to an unexpected shutdown - my qubes operating system stopped starting with an error ! [1c4c8eb2745dea23342d4031e5581330ace0f153_2_666x500|666x500] (upload://gzEf87pC2u9TYlwWbTl0mHOTRPh.jpeg) I took a second laptop and installed cubes on it. I created the same disk encryption password I used on my old laptop, which stopped starting after an unexpected shutdown. And then I was very surprised. The new laptop did not start loading the operating system with the same error as the old laptop. After that, I reinstalled qubes on the new laptop and set a different disk encryption password - after which qubes started to start normally. How can two different devices produce the same startup error simply because of the same disk encryption password? Isn’t the encryption password stored locally?
Did you attempt to upload a picture? If so, try again. You can drag and drop the pic into the message window.
I can’t help you with your system error but I don’t think it’s caused by your disk password. LUKS passwords are not sent to remote servers (at least they aren’t supposed to be!)
I didn’t save data from the previous forum account, so I had to create a new one.
in the first post the screenshot did not load, so I duplicate it below
First, the question in the title:
Are qubes OS disk encryption passwords sent to a remote server?
Of course not.
(This is like asking whether the government is directly reading our thoughts.)
-
You’re assuming that “using the same disk encryption password” is the cause of your problem simply due to observing a couple of correlations. Maybe it is, but maybe it isn’t. Correlation does not entail causation. Was the passphrase particularly long? I recall seeing someone report a problem with a 100+ character passphrase.
-
Did you control for all other variables? In other words, what else was different among the different installation attempts?
-
Your last question assumes that, even if the passphrase is somehow the cause of the problem, the explanation must be that it isn’t stored locally and instead gets sent to a remote server? This is an unfathomable leap of logic. Think about it: Even if some shadowy cabal were plotting against you and your passphrase were being sent to a remote server, why would they then use this nefarious mechanism in order to cause only one of your passphrases not to work? Either they’ve gone to all this trouble with the endgame of causing you a mild, temporary inconvenience, or they’re so incompetent that they could only stop you until you decided to simply try a different combination of characters when creating a passphrase, at which point their master plan was utterly thwarted. It’s far more likely that you had a configuration problem, that some of the hardware isn’t supported, or that there’s a bug.
I used a password of about 20 characters
I will describe the situation again. I have 2 very different laptops. On laptop A I used qubes os, and on laptop B - qubes was not installed once. A few days ago, Laptop A unexpectedly lost power and prematurely shut down, after which qubes os stopped starting with the error I showed in the screenshot in the previous post. Now I decided to install qubes os on laptop B. On laptop B, I specified the same disk encryption password that I used on laptop A. Nothing else connects these notebooks. Even the installation flash drives were different. After entering the disk encryption password on laptop B - I see the same error, one in one as on laptop A. Moreover, laptop A initially worked fine with this password encrypting the disk, and stopped working only after a sudden shutdown. Laptop B - immediately refuses to work. I reinstalled qubes os on laptop B again and now specified a different disk encryption password (no special characters). Now laptop B began to start normally.
That is, indeed, a strange situation. I have no idea what the explanation might be, but here are some thoughts:
-
I still think “passphrase sent to a remote server” wouldn’t explain this. After all, the second passphrase you attempted on laptop B worked fine. Why would “passphrase sent to a remote server” cause a problem with the first passphrase but not the second one when they were both tried on the same laptop (laptop B)? Besides, what would be the point of this? Who could have benefited from this situation?
-
It seems exceedingly unlikely that any 20-character passphrase would trigger a bug in LUKS, so that’s probably not it.
-
I don’t really know what the error depicted in your screenshot is, but it looks like cryptsetup somehow failed to load or something. I’m not sure what causes this, but it’s indeed weird that it happened on two completely different laptops (of different models and manufacturers?). It’s also weird that it happened the first time you tried to install on laptop B but not the second time. Possibly some kind of hardware-dependent installer bug?
That’s all I can think of in terms of commentary. Perhaps folks who are more knowledgeable than I am can shed further light on the situation.
Looks like your attacker used the same buggy software. I would definetly recommend to wipe CMOS and SSD and try a new install. Have the net VM Qubes functions disabled (at least remove the file manager and browsers)
There’s little reason to suppose this is the case.
A simpler, and more likely explanation is that OP simply makes
mistakes when trying to input the long password.
Bologni! The dude uses the same password because of muscle memory. He can type it correctly even heavily intoxicated when not being able to remember his name. I do the same…
I wonder what would have happen when trying to install Qubes on a laptop B from newly bought usb stick, newly downloaded and verified iso from the third laptop, and using the same password as in laptop A.
But, probably it’s too late, since laptop B could’ve been already compromised by old installer usb medium…
even if person use windows bitlocking in the qube connected to sys-net and bitlocking password is same as qubes password for disc?
Did you check iso hash?
wrong hash = wrong qube
Consider the form of the question: “Are Qubes OS disk encryption passwords sent to a remote server?” The question is whether Qubes OS is the thing doing the sending (if such sending is occurring at all). This is a matter of conversational implicature. Even if Qubes OS does no such sending, of course it’s always possible for you to send your password to a remote server yourself separately (or let other software do it for you), but this is obviously not what the OP was asking.
I’ve always found that informed theories are better than wild
speculation.
You obviously disagree.
if stupiduser makes bitlocking and disc passwork same and then password gets sent to underwater windows facility, qubes is still doing sending
stupiduser may not know qubes is doing sending. stupid user does not say to qubes “sudo send password-from-windows-AppVM underwater-place-for-Windows-that-has-much-access-from-others --fix-missing”.
the OP might not know about windows underwater passwords since this since OP knows very little of the qube
maybe OP has used top secrt disc password of “iloveyou” for qube and then also used top scret password “iloveyou” for windows thinking highly secure password protects all qubes.
i am not clicking on conversational implicature link. the last time clicked on strange link, downloaded wannacry and had to delete qube and then clone cloned qube, wasting valuable minutes of time.
In your scenario, I thought that Windows BitLocker (or whichever third-party non-Qubes software) was uploading its own password, which happens to be the same as the Qubes LUKS password (only because the user decided to reuse the same password for both). In that case, Qubes OS isn’t doing the sending in any meaningful sense. Rather, some third-party non-Qubes software running inside of a Qubes VM is sending out a piece of a data that the user voluntarily gave to it. I think most people recognize that Qubes OS itself isn’t responsible for the infinite possible things you can do inside of a Qubes VM. That would be like saying the Statue of Liberty is responsible for punching me in the face because I first went inside the Statue of Liberty before proceeding to punch myself in the face.
This meme (template) also comes to mind:
It is all qube fault that my “iloveyou” password is stored underwater and no longer secure.
I’m now going to sue my credit card company because I used the same credit card numbers on both legitimate and suspicious websites to purchase things. It’s obviously their fault and not mine….
I’m also going to sue the bakery I bought bread from because I made a sandwich with their bread, and I, out of my own free will, added ingredients that I’m allergic to, and I got sick. Again, it’s obviously their fault and not mine….
Finally, I was trying to rob someone’s house, and I fell through the skylight onto a knife and cut my leg; so I’m going to sue the owner of the house I was trying to rob. Obviously it’s their fault and not mine….
One of these is not like the others - check out Bodine v Enterprise High School.
Yeah. The lawmakers were quick to counter that with legislation….