I have some memory of something that I thought was the LUKS password for an old drive with PureOS installed, but I’m not getting in with that password. Obviously I forgot a few characters or something. Is there any way to utilize the knowledge of the “almost” password to do some automated guessing or something to discern the actual password without giving up on the drive?
1 Like
Dictionary attacks or brute-force:
Roast Modular Mothball Estranged Wispy Imagines Kinship Prodigy_U]Py>".yf#(3*E.
If the password is formatted like the latter, computation of the remaining characters will take varying amounts of time depending on the character space(s) used. The former is based off the EFF long wordlist:
I am not aware of a (white hat / black hat) hacker tool that would automate that for you - but I’m willing to bet that such a tool exists. 
Unless such a tool comes from a trusted or verifiable source then you have to weigh up the risk of using the tool against the risk of not using the tool.
In theory, yes, this is doable. If you think that you have some idea then this could greatly reduce the effort in bruteforcing. However, in my experience, memory can be flaky so that, while you have some idea, you don’t really know whether you are adding or varying characters at the beginning, position X in the middle, or the end … to the point that you might give up. To do this, you would need to know the slot encryption parameters (e.g. which algorithm, number of iterations / other performance options).
To be clear though, because of the way the slot encryption key is derived from the slot encryption passphrase, there is no “almost” about it. Even a one character change to the passphrase will introduce a great many bit changes to the slot encryption key. So you just have to iterate through all possible passphrases (within the limits of the remembered information), grind the algorithm to convert that into a slot encryption key and then try that key.
Before starting this exercise, assuming that you do go ahead, I think most people would recommend making a dd image of the drive as it is now i.e. before you start messing around with it.
I guess there might be two possible shortcuts:
- Have you tried the default passphrase? That is, are you certain that you actually set a passphrase?
- Did you regenerate the actual disk encryption master key? I am not sure but I think this question would only apply to the Librem 5.
Other possible ways in:
- You can access a LUKS-encrypted disk by supplying the correct passphrase for any one slot. Are you in the habit of populating more than one unlock slot?
- Did you make a backup of the disk encryption master key?
- Do you have an unencrypted backup of the content of the drive? Or a backup of the decrypted content of the drive but with the backup encrypted with a different passphrase?
- Did you “write down” the LUKS passphrase somewhere?
1 Like
Thanks. Your advice is very good and aligned with my previous understanding.
1.) I tried the Librem 5 default but I think it would’ve never worked. The drive in question was used to boot up PureOS on x86_64 hardware prior to my purchase of a Librem 14… I think.
2.) So I think the possibility of having never changed password is perchance not applicable
–
3.) I’m not in the habit of thinking about the slots. Generally I set up the passphrase in the GUI installer of PureOS and then use the same one forever.
5.) I did not make any key backups for the drive
6.) I believe it is highly likely the drive contains no useful files or information that I didn’t already have access to. I wanted to remember the password to relieve myself of the ailment of stubbornly not wanting to believe I forgot the code and lost access. If I ever actually get back in, I’ll probably pretty quickly remember that my effort to get in was pointless.
7.) I’m quite sad to think I probably never wrote down this LUKS phrase anywhere. I have some notes that tell me loosely what it should be, but they don’t contain the full text.
I was able to sudo apt install hashcat and use some program from pureos to try to guess huge numbers of passwords at high speeds. I loaded this onto a large nvidia card I had around with a bunch of cuda cores that works on a computer running ImpureOS (debian nvidia drivers + pureos) and I got to where I could crunch through about 40000 passwords in a minute. Then using my own code I made a list of everything I could possibly conceive off that might have been the one for this case, but hashcat told me it existed all attempts without success.
Similarly, asking it to guess over a wider range of passwords without special knowledge that I thought I had seems to take decades of estimated time instead of seconds, so I think this means that in my case the recovery is infeasible.
But I appreciate the help, and it was at least a little fun to prove to myself how I was wrong about my first 70000 guesses and accordingly that I am wrong to think I remembered the code.
1 Like
Actually, you misunderstand. Each slot holds the same disk encryption master key. Each slot is encrypted using a different slot encryption passphrase and therefrom a different slot encryption key.
If you change the slot encryption passphrase, you aren’t changing the disk encryption master key. So if someone knows your disk encryption master key, they can forever decrypt the disk contents, regardless of how many times you change the slot encryption passphrase. Have you tried asking the NSA? 
2 Likes
Is it better to memorize a series of randomly generated passwords or make your own do you think?
1 Like
I don’t suppose you’ve taken a disc image as back up recently? You could return to that previous state with all of your (older) files intact, if you remember your old LUKS pw. That way you wouldn’t lose the whole system.
1 Like
Humans have flaws in their thinking which decreases randomness and make passwords more quessable, so purely on that I’d say generated are better. But, in both instances, length matters - is it within cracking range or in the range of not-likely-in-any-reasonable-timeframe. But there is also the problem of human limits of how long pws we are able to remember, and how many (it’s a human flaw and using same in many systems is bad practice). Luckily we have some tools, like password managers that both generate and remember for us, which help but in turn also create a bit of work and (if done badly) transfer risk (having all the keys to all your valuables in one place). The question, I think, is a bit theoretical as there are all this kind of other things to consider. In addition to: “maybe using just passwords isn’t the best method - at least in all cases”.
2 Likes