Full disk encryption (including /boot) Luks2+argon2id

8 replies [Last post]
Joined: 09/28/2023

Hi all . I wanted to ask the community if it is possible to install Trisquel with full disk encryption (including /boot) Luks2+argon2id.

Has anyone had a positive experience? If yes, please let me know how you did it.

As far as I know, Gnuboot does not currently have such an option. Project response: So, the answer is no, we do not support Argon2. This is what the coordinator of the Neox project told me https://wiki.xmpp.org/web/Adrien_Bourmault_Application_2023 This means that it is impossible to encrypt a disk including the /bo partition

I looked in the Trisquel repository https://packages.trisquel.org/ there is version 2.06, as far as I know this version also does not support argon2id.

Why Luks2+argon2id including the boot partition? According to professionals in this field, today this is the best option possible.





Joined: 09/28/2023

Hello Ignacio Agulló. Why did you duplicate my post?))

As for full encryption including the /boot partition, you did not read my post carefully.

I wrote about Luks2+argon2id. This is possible if Grub Trisquel or Grub Gnuboot (for example) supports Luks2 and argon2id.

Thanks for the link https://trisquel.info/en/wiki/full-disk-encryption-install but it doesn’t work!


I am a translator!

Joined: 08/18/2020

Thanks for the references.

On my laptop running Trisquel 11, /boot is not encrypted but cryptsetup luksDump on the encrypted volume that contains /, /home and swap says that argon2id was used for key derivation. This is the recommended key derivation function in your links.

Does /boot contain any confidential information?

Joined: 09/28/2023

Hello Avron.
Thank you for your answer. I also checked my root partition and you are right it is argon2id.

So the reasons:

1. This is the fact that most users do not correctly use the concept of Full Disk Encryption, which is confirmed by Debian developers.
Correct understanding means encrypting the disk including the /boot partition where the kernel & initramfs are located.


2. Another reason is to protect /boot from interference by anyone with physical access to the system.

Even with less secure encryption, an attacker would need time to brute force the boot partition. This means that you can feel safe leaving your machine for several hours, knowing that an attacker isn’t installing malicious code into your machine.
Data theft:
This could be especially useful for attorneys facing unscrupulous airport security. If forced to hand over a machine with privileged information, an attorney could simply refuse to give his/her passphrase.


My opinion is that if a developer thinks that his kernel or program will not be tampered with or hacked, he is already in danger, at the moment no one needs him. Encryption is the only protection after free software. As the practice of recent years has shown, even large corporations with huge budgets of millions of dollars cannot cope with this and pay attackers.

It would be great if Gnuboot used almost everything and the new release had support for Luks2+argon2id.


I am a translator!

Joined: 08/18/2020

If someone can write something to your disk, couldn't that person write an unencrypted boot with something that starts and looks like your normal software but catches your passphrase when you type it?

Perhaps if you boot on a CD, you could check that your disk was not modified, but I am not sure how to do exactly. Maybe that is possible even with unencrypted /boot.

Joined: 09/28/2023

Now I don’t exactly remember the name of the resource, but I read how they did it, so you need to encrypt the boot partition and set a password for grub

Perhaps this looks paranoid)) but when you have important data on your PC, this is important.

Evil Maid attack

Many full disk encryption systems, such as TrueCrypt and PGP Whole Disk Encryption, are susceptible to evil maid attacks due to their inability to authenticate themselves to the user.[9] An attacker can still modify disk contents despite the device being powered off and encrypted.[9] The attacker can modify the encryption system's loader codes to steal passwords from the victim.[9]




What is the GRUB2 BootHole Vulnerability (CVE-2020-10713)?

BootHole (CVE-2020-10713) is a new high-risk vulnerability that can potentially effect billions of devices worldwide, from servers and workstations to laptops, desktops and IoT systems running nearly any Linux distribution or Windows system.

BootHole resides in the GRUB2 bootloader. If exploited, it could potentially allow hackers bypass the Secure Boot feature, designed explicitly to prevent unauthorized code from gaining additional privileges and pre-OS persistence. Thus, the attacker would gain high-privileged persistent and stealthy access to those targeted systems.


There is an interesting project where there are no hard drives in the PC , for example, an attacker ripped out the PC and all the data is in the cloud, since the computer does not have a physical disk, .all the data is in the crypto-cloud

Joined: 12/20/2023

I think I remember something at




that shows there is no "cloud", only other peoples computers.

Also parts of


show how anyone may always be able to bypass anything on earth.

Though you could than also "bypass" your computer back.



also has a user called throgh show in part

The problem is: Not every professional is thinking same. I could name several strange and weird information contradicting from experts we two would acknowledge being in general individuals we at minimum read through. So I'm cautious with information given as the point of encryption is something always in development. If I would need to use some metaphor for this:

A house in endless building with never finishing possible. An eternal construction site!

You have one encryption-method you recognize that current time "safe". Tomorrow it is no longer "safe" as something is discovered. And that essential point is something in need under perspective. If you want to wait? Okay. But I cannot give any kind of timeline here, or if others have that amount of interest. I can only say what I have done for supporting: Giving information I have and also forwarding to people possible to support wide better. When nobody is supporting in the end or cannot offer the time: This ends exactly at the point I have already scribbled with "do it yourself". And a system as Hyperbola is stable and secure as possible, but foremost long-term and stable. That's the point!

And we cannot include any update just "like that". First it has to tested local and long-time, at best not encrypted and encrypted. Demanding this from one single person is not possible. So if you have interest in this, jim: You should be clear to engage within that instead of waiting.

That was on a forum post about

Question about Grub2 and Luks2

So, I think, many users using many types of encryption may also make the cracker not know what type you are using.

Joined: 09/28/2023

Hello . Thanks for your answer and your opinion.
There is one detail: Throgh is not involved in cryptography at a professional level, but I gave links to developers who do this professionally and expressed my opinion on this matter.

Today, according to a post by Luks2+argon2id, the best option is .



Motivation of Full Disk Encryption

Full disk encryption goes beyond the ordinary disk encryption by protecting the operating system’s files as well as user data. Certain types of OS files are common attack surfaces, like SSH host keys under /etc/ssh, Sudo’s configuration file under /etc/sudoers.d, Linux kernel’s files at /boot and /lib/modules, etc. If they are encrypted too, adversaries cannot tamper with them to inject malicious configuration or executable code, and the system integrity is thus better protected. For example, they cannot replace the kernel image or user-space executable programs with a modified copy containing dangerous code because those system files are encrypted too under full disk encryption.


Of course, everything is temporary, but this is the information for today, tomorrow everything can change...

Joined: 12/20/2023


has information about

Install Full disk encryption (including /boot ) Luks2+argon2id T440P

so maybe if it can be done with Hyperbola it also can be done with Trisquel.

I did not test it yet though.

I do not know if Gnu boot works with

Full disk encryption (including /boot ) and Luks2+argon2id

yet, though maybe it can be patched or put in somehow, if it does not yet work.

Though Coreboot and Libreboot have "blobs" that may not be under a free as in freedom license now, so patching freedom supporting code into Gnu boot may help, if that is something that can be done.

Or those blobs may be a technological or "legal" backdoor into your computer, bypassing the encryption.