Disk decryption passphrase

I received my Librem 5 Evergreen today, after four years since my order. I put it in charge, without turning it on, the message “Enter disk decryption passphrase” appeared. Question, what is the passphrase of my device? and why is it required in the charging phase?

This is what you’re looking for – it’s the same for all phones that ship (until you change it). How to change each of them is in various responses to the post.

1 Like

Thanks, but i think it should be indicated on the “quick start guide”.

1 Like

We think so too:

I dont think so. I know fsck output for 30++ years. This message on the L5 in a one liner and says something about decrypt canceled....

Aaahhhhhhh that’s why it doesn’t work!! I changed the standard one (123456) for mine including numbers, letters and special characters!!!
And yes, it’s possible to change it by terminal commands line or setting in disk app! But it’d be a warning about this limitation! I did both ways without receive warning message :man_facepalming:
Anyway thank you for this info!
Now I’ve to flash again my L5 :sweat_smile:

PS: I found right now that also it’s suggested don’t use gnome disks to change password because it destroys encryption! So I’ve to change it just manually from terminal by commands line, correct?

1 Like

I modified my disk encryption password (only numbers!!!) throw gnome disks and it’s working!!!
Just to let you know!!
:blush::wave:

1 Like

I think in “the user passphrase can be changed in settings (but yes, for now it’s numbers only)” Dorota is talking about the login password that is associated with the purism user i.e. the password used to unlock the phone after initial boot and thereafter any time the lock screen activates.

That is quite separate from the disk encryption passphrase (the LUKS passphrase) that is used during the boot to access the content of an encrypted disk.

The only restriction on the disk encryption passphrase is that it should be printable ASCII characters only. It is not restricted to digits only.

However I admit that for changing both of these (disk encryption passphrase, purism password) for initial install, I used the command line. So I am not really across what restrictions or problems the corresponding GUIs might have.

To be honest, a digits-only disk encryption passphrase is probably not strong enough but a) as always, that depends on your threat model and b) even a shortish digits-only disk encryption passphrase is some kind of protection for the information on your phone in the event that your phone is subject to casual (untargeted) theft or loss.

2 Likes

It’s no restriction. It’s “no support for non ASCII characters” - but they do work. So “should be” is exactly what it stays for: a recommendation. And I strongly recommend to make backups on another disk before trying out such things. I would recommend it anyway before changing LUKS pw. A little failure and you have to reflash your device, because you cannot decrypt on next startup.

2 Likes

Yes, that’s the reason that I wrote “should be”, not “must be”.

Be very careful … when you are fully and normally booted, you may have access to a keyboard, used by the application that you use to change the LUKS encryption passphrase, that can generate far more characters than can be generated by the keyboard that you use to enter the passphrase during boot.

And in either entry scenario it may not be entirely predictable how a sequence of characters is converted into a sequence of bytes (which is ultimately what will be input to the key stretching process). Sure, if for example both use UTF-8 now and forever, that is fine. (In some situations even the underlying character set could be an issue. Again if for example both use Unicode now and forever, that is fine.)

It is conceivable that if you want to use non-ASCII characters in the LUKS encryption passphrase then you should either make a second key slot, with a longer, safer passphrase or make a backup of the LUKS encryption master key (but if doing the latter, you need to think about how that backup is itself protected.)

3 Likes

I’m curious to know why, LUKS, is limited to only numbers?
Someone could explain me it, please, in a layman terms :sweat_smile:?
I looked for it on internet but I didn’t find it!
Thank you

1 Like

The LUKS encryption passphrase is not limited to only numbers:

2 Likes

So why I had to reflash my L5 after I set my new LUKS password including numbers and characters and it didn’t work?
It’s also said by to use only numbers :sweat_smile:
Now I’m using only numbers password and it’s working :woozy_face:

1 Like

Keyword is “special” characters.

1 Like

Please, so why I should have two different keyboards in L5?

1 Like

The keyboard provided during LUKS decryption is minimal, whereas the keyboard accessed after LUKS decryption is capable of a rich character set. They are separate due to their different use cases (security vs general).

3 Likes

To add to that … in a traditional Linux multi-user environment, after you log in, you will get the keyboard for the locale that the logged in user has selected (or indeed the keyboard that the logged in user has selected when it is possible to customise that choice). Clearly, that is not possible during disk decryption - since you can’t possibly yet be logged in.

There has to be a keyboard built-in to the boot environment that is used to handle disk decryption - and by definition that keyboard is being used before the root file system is even mounted.

I dare say that it would be possible to customise the keyboard used during boot. However if you get that wrong then you will likely completely lock yourself out of your phone and you would need to use Jumpdrive to reverse that customisation. You may also find that a system upgrade overwrites your customisation unless the boot environment caters for that customisation (I haven’t checked) and that again could result in losing access to your phone.

At the end of the day, you have to weigh up the benefits of using unusual characters in a LUKS password (stronger password for a given length) against the risks that have been outlined in this topic. It is your phone.

However, if it were me and I had made the decision to use an unusual LUKS password then the bare minimum is to know how to recover access to your phone if things go pear-shaped.

(In an ideal world?, the Disks mechanism that allows you to change the LUKS password would use a non-standard keyboard i.e. use the built-in boot keyboard rather than the user-selected keyboard - so as to make it harder to enter a LUKS password that will then lock you out. However I don’t know how easy that would be to implement.)

2 Likes

Thank you so much for your detailed and interesting answer, Irvinewade! After I read it I decided that, the best compromise for me (not expert), is to choose and use just a numbers password! Maybe it’d be a wise suggestion for every user at same tech level :sweat_smile:
I hope, in the future, Purism will implement an ASCII full compatibility boot keyboard with logged in keyboards although, in my opinion, picture password remain the best option to unlock L5 (because digiting on the keyboard could be spied in crowded places (eg: trains, buses,…)! Hope Purism will implement it one day, at least as security option for us as choice!
Have a nice day :slight_smile:

1 Like

So, just curious to know, boot keyboard when L5 is switched on is created/set by Purism, not by LUKS?

1 Like

I’m not sure where this is coming from??

LUKS on the Librem 5 is perfectly happy with a LUKS password that contains ASCII letters (uppercase and lowercase) and ASCII digits and ASCII punctuation characters.

I know this for a fact because I have intentionally used a LUKS password that contains at least one ASCII character from each of those 4 subsets. I have zero problems to enter the LUKS password during boot.

I guess the safe approach is to

  1. Start out with an all digits LUKS password (preferably keeping your phone off the internet, just in case).
  2. Finish setting up your phone.
  3. Use Jumpdrive to make an image of the phone’s disk. (All users should know how to do this and all users should do this, regardless of LUKS password issues.)
  4. Change the LUKS password to use any characters from the set of printable ASCII characters (longer and stronger).
  5. Reboot the phone to confirm that you can successfully get past the LUKS password entry.

That may not be possible because you can customise the keyboard that you use once you have logged in to the phone. I mean I guess with enough work this could be done - but if you just tell people to use printable ASCII only and you give people exactly one LUKS keyboard that can generate any printable ASCII character then that is good enough.

I believe that the keyboard is from package osk-sdl and that it is therefore not created by Purism and is more or less part of LUKS (i.e. in any case a standard Debian package).

2 Likes