Better integration for encryption


Despite the fact it’s possible to encrypt Linux, there’s no pleasant way, when it comes to enter the passphrase.
When the whole system is encrypted, there’s just an ugly prompt of grub, with an ID of your hard drive (I guess) and the question to enter your passphrase.
When just the /home directory is encrypted such a text appears right after grub.

At least when entering the passphrase for the /home directory, there should be a more “pleasant” way to ask for the password.
I use the boot splash invented by the manjaro team a few weeks ago, and there’s not even a prompt anymore, so that was kind of confusing. :smiley:

Probably you’re working on it, but it would be nice, if the “enter-passphrase-process” was less cryptic and confusing.

And security is important! :smiley:


So, specifically, what is the feature you want to be implemented?

“Make it less confusing” isn’t a feature that can be implemented.


I agree, it needs a pretty face on it like lightdm/gdm, etc.

My issue with it is that if you mistype your password, it doesn’t let you “try again.” I have to physically reboot the computer and wait for bios and passphrase prompt again.


Is there a Linux example of this anywhere, or is this a purely theoretical thing?


It is a wish-list thing.


Those things are pretty much impossible to implement. :wink:


I am still putting it on my holiday wish-list. :stuck_out_tongue_winking_eye:


There is a solution but it’s not for everyone:

PC should be equipped with TPM2. /boot should reside on a separate un-encrypted partition. I managed to make it work with direct kernel booting (no GRUB), my luks partition gets decrypted with a TPM-sealed key which is being added to luks keyslot during the setup process. This makes system boot without any prompt for password, making the whole process look like Windows 10 boots up with BitLocker enabled (seamless, in one word). Also, it uses pcr values when decrypting a key, so if some malicious rootkit alters boot sequence or bootloader, the decryption will immediately fail and ask for a decryption phrase (which usually resides on keyslot 0 of luks volume).

In brief the installation process has to be done this way:
trizen -S tpm2-tools tpm2-tss luks-tpm mkinitcpio-tpm2-encrypt
After installation, there are several steps to make it work:

  1. Creating of a pacman hook to set a temporary passphrase when kernel, rEFInd binary, etc gets updated (not necessary now as the tool got updated and Manjaro compatible pacman hook is now included):
    echo -e '[Trigger]\nOperation = Install\nOperation = Upgrade\nOperation = Remove\nType = File\nTarget = boot/vmlinuz-*\nTarget = boot/intel-ucode.img\nTarget = usr/lib/initcpio/*\nTarget = usr/lib/systemd/boot/efi/linux*.efi.stub\nTarget = usr/share/refind/refind_x64.efi\n\n[Action]\nDescription = Adding temporary LUKS TPM key...\nWhen = PostTransaction\nExec = /usr/bin/luks-tpm2 temp' | sudo tee -a /etc/pacman.d/hooks/luks-tpm2.hook
    As I use rEFInd and Secure Boot, I have some more hooks for auto-updating and auto-signing rEFInd binary and its ext4 driver (and kernel too). Let me know if you need to see this too.

  2. Listing persistent handlers of your TPM2-device:
    sudo tpm2_listpersistent -T device:/dev/tpmrm0

persistent-handle[0]:0x81000001 key-alg:rsa hash-alg:sha256 object-attr:fixedtpm|fixedparent|sensitivedataorigin|userwithauth|noda|restricted|decrypt
persistent-handle[1]:0x81000002 key-alg:rsa hash-alg:sha256 object-attr:fixedtpm|fixedparent|sensitivedataorigin|userwithauth|noda|restricted|sign
persistent-handle[2]:0x81010001 key-alg:rsa hash-alg:sha256 object-attr:fixedtpm|fixedparent|sensitivedataorigin|adminwithpolicy|restricted|decrypt

  1. Creating parent encryption key in your TPM2:
    sudo tpm2_createprimary -H o -g sha1 -G rsa -T device:/dev/tpmrm0

ObjectAttribute: 0x00030072

CreatePrimary Succeed ! Handle: 0x80000000

  1. Making your own persistent handler for it:
    sudo tpm2_evictcontrol -A o -H 0x80000000 -S 0x81000003 -T device:/dev/tpmrm0

persistentHandle: 0x81000003

I used 0x81000003 (which was just created with the above command) because 0x81000001 and 2 others were already occupied by default (I suspect it was Windows who owned other handlers listed as per tpm2_lispersistent).

  1. Before proceeding you need to check your luks partition’s slots and adjust them as needed (sudo cryptsetup luksKillSlot <device> 1, sudo cryptsetup luksAddKey <device> -S 3 /crypto_keyfile.bin, etc):
    sudo cryptsetup luksDump /dev/nvme0n1p5
    AFAIR by default, Manjaro is being installed with 2 keyslots active, first (its number is 0) is for your phrase, second one (number 1) is /crypto_keyfile.bin. luks-tpm2 uses slots 1 and 2, so you should either add your /crypto_keyfile.bin to another slot (i.g. 3 as shown above) or simply kill this slot 'cause there will be no need in it from now on. Or – it’s also an option – make adjustments in /etc/default/luks-tpm2, corresponding variables are TPM_KEY_SLOT=1 and RESET_KEY_SLOT=2. But pls don’t kill your slot 0 with your passphrase – it’s your fallback option if you do smth wrong.

  2. This is an actual command for creating of TPM-sealed keyfile:
    sudo luks-tpm2 -p /boot/keyfile -H 0x81000003 /dev/nvme0n1p5 init

Initializing LUKS TPM key for /dev/nvme0n1p5
WARNING: This will permanently delete the key in slot 1!
Do you wish to proceed? [Y/n]y
Enter any existing LUKS passphrase:
Generating new LUKS key…
Removing existing key from slot 1…
La ranura de claves 1 no está activa.
Adding new key to slot 1…
Sealing keyfile with the TPM…

  1. Add tpm2 hook right before encrypt one in /etc/mkinitcpio.conf and regenerate initramfs with sudo mkinitcpio -P.

  2. Finally, bootloader’s parametres:
    tpmkey=/dev/nvme0n1p2:/keyfile:0x81000003 tpmpcr=sha1:0,2,4,7 cryptdevice=PARTUUID=a8c19e8e-blah-blah-blah-your-usual-parametres, where nvme0n1p2 is a /boot partition where keyfiles were created, /keyfile – a relative path to both keyfiles, 0x81000003 – above mentioned TPM handler, sha1:0,2,4,7 - PCR values as per /etc/default/luks_tpm2

What a wall of text, right? So many things must be configured. Of course all commands are not meant to be copied and pasted without proper adjustment for every single use case.
Maybe I will make it more readable or maybe not – I got tired while describing this :dizzy_face:


PS: ATM it has some limitations like auto-assigning temporary passphrase works only with updating via pacman, while pamac (cli and gui) does not provide a request for user input.
PPS: Also this thing relies on tech that is under active development so sometimes there are some failures to compile and install tpm2-tss and so on, git versions may change in a way that breaks compatibility with luks-tpm2, etc.
I checked btw, this script works with LUKS v2 as well.

Full disk encryption like Bitlocker using TPM
[Testing Update] 2018-11-25 - The "I shoot you outta Orbit" Update
Decrypting manjaro to get to installed grub bootloader takes 20+ secs?

Then what’s the point of encrypting?
If your laptop gets stolen and the thief boots your laptop, they have access to all the data on it, if there is no need for a password/user input.


First they should guess my login password :wink:


So let me get this straight.

The encryption is active. So if a thief steals the laptop and uses a Linux live session, he can’t see the files from the live session?
So it only gets decrypted with the user login password?


Hm, no, it gets decrypted during the boot process, but in order to see my files they will need to login first. Maybe I’m too dumb but I don’t know any way to get access to files until I log in. You tell me. I’m not claiming I know everything. As for live session - you mean some Linux usb stick, right? Well, booting from such stick does not automatically grants any access to encrypted partition. To decrypt, one would still need a passphrase. And there is a general way to prevent booting from usb devices at all with the use of BIOS setting and BIOS password. Secure Boot also kicks in when one wants to set up things right.

Again, I don’t claim I know how to penetrate the OS and get an access to users’ files, so… Maybe this thing’s application could be just for a seamless system boot, but /home should better reside on a separate partition encrypted with another key, accessible only with a user input.


So you’ve created 5 threads, previous 4 have been mod closed … wonder how long this one will last … :face_with_raised_eyebrow:

What the hey, I’ll bite … even if I am feeding a potential troll.

Probably not actually.

How about learning a little about disk encryption first (ie LUKS, dm_crypt, grub encryption support, etc) … and make an educated implementation suggestion based in reality.

This type of “golden goose” wishlist thread really serves little purpose without an idea of how to configure it manually (ie the Arch Way).


For newbies and/or for those who don’t require a full disk encryption setup, you can use ecryptfs as an alternative to LUKS, and use it to encrypt your /home only.

It can be configured to unlock /home right on login with the user’s login password using PAM.

It’s quite easy to setup as long as you follow the instructions carefully:


Manjaro/Arch newbie, longtime Debian user here. This is the method I used previously, but I read it is not as secure as LUKs. What say ye?

Edit question to say, “…not as secure as a whole disk encryption with LUKs.”


Of course a FDE is more secure, and LUKS also uses a stronger cipher than ecryptfs by default.
It’s still largely good enough for the majority of people, as most sensitive data of casual users tend to be on the /home partition.
EDIT: it was also planned to integrate ecryptfs into the Architect installer, but it was more difficult than we initially thought, and that plan has since been shelved.




Well, I have to apologise, I understood this forum topic wrong.

As it seems, “realistic” feature requests are just features that already exist in the linux world and “just” have to be implemented, I’m sorry for that, it won’t happen again.
I just remebered that I encrypted Suse Linuix once and they had a proper interface for decryption, but maybe my memory fools me, I don’t know, but that’s the reason why I thopught it would be possible.

Maybe the forum should be renamed to something more concrete, since I thought, “realistic” is something that’s actually possible. This is my interpretation of this word, but it doesn’t seem to fit properly here.

I can just say that I’m sorry and won’t spam this forum with useless wishes again.

I can just say that I wanted to make Manjaro better and not drive Manjaro devs and admins crazy for nothing.

I’m sorry.


Yes you are right, 3 threads were closed because it was
1.) solved
2.) a stupid question caused by a mistake of mine (I’m sorry for that)

I understood the sense of this forum topic wrong, so thread number 4 & 5 are the perfect candidates to be closed too.
I’m sorry.

And yeah.
AS a troll I can say that it’s really cool to write a textof 460 words just to troll the admin team of the distribution I use & donate to.

Yeah, that seems reasonable. :joy:

But maybe that’s the definition of a troll, I don’t know.
As it seems I have no clue about how Linux works and that I have to be a Linux pro to be able to write acceptable comments in Linux forum, since suggestions of “Newbies” seem to be too nooby to actually work on them.

But wait… If a newbie is says “Hey there’s something that could be better!” shouldn’t someone listen to them? :thinking:


I read your final two posts in this thread as being fairly well-balanced. This last section just comes across as whiny.

Any “idea” is pretty worthless without any indication of how it would be possible.

“I have an idea! You should build a space station in orbit around Mars!”

Yeah, it’s a great idea. But how would it happen?

“You should make this car have four-wheel drive!”

It could make it better, but how on Earth would you technically make it happen?

“You should make encryption better!”

OK, again, nice idea. But how?

“I think this thing in Manjaro could be better. I’m new to Linux so you should listen to me!”

That’s not realistic:

“I’m new to cars but I think cars would work better if they were harder to crash! I would do it myself but I don’t know how and I don’t get paid to do it. It’s a good idea, though, so why won’t you just make it happen?”