Why does Kicksecure installation built-in FDE option utilize LUKS1 format instead of newer safer LUKS2? How can it be fixed? Sorry for such stupid questions, i’m new to this, thanks
Users cannot fix this.
(Except with a workaround: manual installation, Distribution Morphing - Transforming of a Linux Distribution into Another Linux Distribution → Install Kicksecure inside Debian because then other installation methods can be used such as manual setup of encryption which is however needs to be figured out as per https://www.kicksecure.com/wiki/Self_Support_First_Policy.)
Kicksecure 17.2.3.7 and above will come with luks2 by default. Unreleased at time of writing. Will probably be released soon (October 2024). Stay tuned. → Follow Kicksecure Developments
I see, thank you
Its already supported , i have tested kicksecure iso on vbox .
calamares installer created luks2 except /boot partition witch remains unencrypted.
I know due to grub not supports argonid2, i have seen 2 workarounds to bypass this :
1- encrypt boot using luks2 with the pbkdf2 algorithm -password must be entered twice .
Adding root kefile to initramfs image is not safe , in case of attack on encrypted boot partition.
2 -another option is to use patched grub to support argon2id
-Patrick Steinhardt patch
-Arch AUR improved grub luks2 git
Witch way would you recommend here to encrypt boot partition .
The current solution Kicksecure is using is to leave /boot unencrypted. This allows passphrases written in non-US keyboard layouts to work, and it seems to unlock the disk faster than when GRUB has to do it.
What unlocks the disk faster than GRUB ?
Did you mean when boot is not encrypted, Grub are not involved or needed?
For me when used calamares with luks1 and encrypted boot i didn’t face any problem .
Grubs default us English layout was not a big issue for me .
Well, that too. But also GRUB seems to literally be slower than Linux itself at running the code needed to unlock a LUKS volume.
For some, it has been a big deal, and doing things this way avoids the need for Kicksecure to distribute a custom-built bootloader (which would add maintenance burden) while still getting the security advantages of LUKS2. It does mean that files under /boot could potentially be modified by an attacker to do bad things on next boot, but even if you have /boot encrypted an attacker could still modify the unencrypted bit of GRUB to do bad things on next boot.
Alright .
As far as i see kicksecure uses calamares installer with luks2 without encrypted boot
It still uses Grub to boot Kicksecure witch will not ask for password unlike when boot was encrypted.
1-could you explain what decrypts luks2 partition instead of grub?
The initial ramdisk (initrd) (created by default by initrd creator
“dracut” in Kicksecure at time of writing).