I received my Librem5 this week. Disk encryption was enabled by default.
Yes, after entering the decryption passphrase correctly, it says for a short moment
cryptsetup: crypt_root: set up successfully
Sometimes it gives an error message, even when the passphrase was correct. It seems this happens, when the shutdown was not executed correctly. Will try to find the pattern and grab a video of the message.
1 Like
That’s most likely fsck.
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 
Anyway thank you for this info!
Now I’ve to flash again my L5 
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!!
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 ?
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
Now I’m using only numbers password and it’s working 
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