[GAVE UP]Encrypted boot with GRUB, it sucks. Is there anything better?

lfitzgerald · 2023-02-05 03:36:24

I have /boot on its own 1 GB partition, encrypted with LUKS1. I use GRUB with `GRUB_ENABLE_CRYPTODISK=y`. When I boot, I get the prompt from GRUB to type in the LUKS password. After I enter, I see the GRUB menu to boot my system (also encrypted, but with LUKS2).

I like that this allows me to have a separate encrypted boot. But otherwise it's very annoying. It takes 5-10 seconds to unlock, which is too long. The iterations on the key are already pretty low, if I decrease it more I feel like it's going to compromise security. There's also no asterisk echo and if I make a typo I get a very user-unfriendly recovery prompt.

Is there a better option for encrypting boot?

Last edited by lfitzgerald (2023-03-04 01:08:15)

frostschutz · 2023-02-05 12:54:13

The only thing the iteration count can do is prevent brute forcing. Given enough entropy, brute force is not an issue. If the passphrase itself somehow leaks (someone puts a keylogger to your keyboard) then the iterations won't really help you either.

So it's fine to not have a large iteration count (or any at all), as long as the passphrase itself has plenty of entropy. 12 random words for XKCD style passwords would result in >128bit of entropy. No one will be able to bruteforce it, even if you disable iterations altogether. But of course, instead of waiting 10 seconds to unlock, you'll spend 10 seconds to type it out... :-)

Grub's cryptomount also supports --key-file (-offset/-size) options, which is another way to use very high entropy keys. The problem then is how to provide such keyfiles to Grub, without allowing anyone else access...

If you are using multiple keyslots, make sure the one you're trying to use is the first one. Otherwise you waste time trying to open the wrong keyslot. With LUKS2, it's possible to set a priority flag for a given keyslot so it is tried first. Not sure if Grub would respect it though. (Grub has some support for LUKS2, only the key itself has to be LUKS1 style pbkdf2 since argon2i is not yet supported).

Personally I don't encrypt /boot at all, it's too much hassle and simply not worth it.

Gregosky · 2023-02-05 16:50:35

I bought myself something like this and moved /boot partition into usb. I also store decryption key on that usb. When I want to boot my laptop I unlock the usb and plug it to my usb port first and let laptop to boot from it.

lfitzgerald · 2023-02-07 23:39:11

Guys, I'm not asking for ways to introduce fatal flaws into my disk encryption

I'm just asking if there's any way to make GRUB faster, or if there's a better bootloader that isn't so slow.

Gregosky · 2023-02-08 07:34:12

I can't remember exact details but cryptsetup binary used this early in the boot process is much slower than the one used later in the boot process, I can't remember why (maybe it was the key derivation as described in this reddit thread), but I do remember making observation that it's slower when unlocking /boot itself.

I wonder why do you think moving grub to encrypted storage introduces fatal flaw into it? As far as I'm aware storing grub on external encrypted usb is more secure than GRUB_ENABLE_CRYPTODISK=y. Both will fail anyways if you meet man with the wrench..

Last edited by Gregosky (2023-02-08 07:48:33)

frostschutz · 2023-02-08 10:05:03

lfitzgerald wrote:

Guys, I'm not asking for ways to introduce fatal flaws into my disk encryption

You already introduced them by encrypting /boot … :-)

It's not like relying on Grub is secure in any way. Grub doesn't do anything special, it puts its pants on one leg at a time, there is no secret ingredient, etc…

lfitzgerald wrote:

I'm just asking if there's any way to make GRUB faster

You'd have to optimize or rewrite Grub source code…

lfitzgerald wrote:

or if there's a better bootloader that isn't so slow.

Not aware of any bootloaders that do the shenanigans that Grub does.

But you could make your own.

Instead of reyling on Grub, you would boot a minimal kernel + initrd, this can be baked into one image, signed by secureboot or whatever.

In the initrd you can then handle the encryption shenanigans, grab the real encrypted kernel and initramfs, and finally boot it using kexec.

Security then would depend on your own implementation.

Speed would be the same as real cryptsetup as that's what you would be using.

Last edited by frostschutz (2023-02-08 10:05:53)

lfitzgerald · 2023-02-12 05:29:19

Gregosky wrote:

As far as I'm aware storing grub on external encrypted usb is more secure than GRUB_ENABLE_CRYPTODISK=y

How so?

Gregosky · 2023-02-13 07:51:40

lfitzgerald wrote:

Gregosky wrote:
As far as I'm aware storing grub on external encrypted usb is more secure than GRUB_ENABLE_CRYPTODISK=y
How so?

Look at this piece of hardware. Encrypted grub still requires decryption component to be unencrypted. By storing your /boot on encrypted device you have everything encrypted.

I was using encrypted grub in the past, I was also using TPM for storing decryption key, and I switched to hardware-encrypted USB key, I'd say it's more convenient too.

Last edited by Gregosky (2023-02-13 08:07:23)

lfitzgerald · 2023-02-15 00:15:44

Gregosky wrote:

Encrypted grub still requires decryption component to be unencrypted.

That's a fair point. I see why you say it's more secure. In my case, it is acceptable for the pre-boot decryption code to be unsecured. My concern is the performance of exactly this part.

Gregosky wrote:

Look at this piece of hardware.

In this case, Kingston is responsible for correct and secure implementation of the encryption, is that not the case?

Gregosky · 2023-02-15 08:20:55

lfitzgerald wrote:

In this case, Kingston is responsible for correct and secure implementation of the encryption, is that not the case?

It becomes single point of failure if there was something wrong with it (including whole security concept defeated if there was exploit allowing adversary to access the storage without knowing the pin). In my case I made security assessment and came to conclusion that potential adversaries I want to dodge will most likely not be on that level to be able to exploit such vulnerability (people like burglars are more interested in hardware than data, and more serious people have more serious methods so would get my data anyways).

Anyways, have you looked at reddit thread I linked? You can simply try to create and test another key like this:

cryptsetup luksAddKey --iter-time 1 /dev/sdXY

This key should result in much faster boot experience for you, and can be harmlessly deleted after you are done with testing.

Last edited by Gregosky (2023-02-15 09:14:05)

lfitzgerald · 2023-02-23 00:26:13

Gregosky wrote:

It becomes single point of failure if there was something wrong with it (including whole security concept defeated if there was exploit allowing adversary to access the storage without knowing the pin). In my case I made security assessment and came to conclusion that potential adversaries I want to dodge will most likely not be on that level to be able to exploit such vulnerability (people like burglars are more interested in hardware than data, and more serious people have more serious methods so would get my data anyways).

I don't really want to trust a faceless multinational company with encryption.

Gregosky wrote:

cryptsetup luksAddKey --iter-time 1 /dev/sdXY

Setting iter time to 1 ms seems like it would weaken the encryption.

Gregosky · 2023-02-23 09:14:04

You already trust faceless multinational company who manufactured your computer/laptop..? Unless.... you manufacture your own electronic in your home factory

I already trust Kingston with my RAM, it would be some sort of split-mind situation to suddenly not to trust them with some other piece of hardware. Actually, I would trust Kingston more than some nameless company who could sell forged hardware that pretend to be hardware encrypted.

I'm of opinion that when it comes to perceived security - no matter how secure the system is, man with wrench will probably defeat it in no time...
Whatever you have is already good enough to keep your secrets safe if your laptop gets stolen or lost. Even with iter time 1.

Adversaries who would try to brute force your password will count on this password to be weak, so use long complex password which you don't use anywhere else and you will be fine. Adversaries with budget (like state actors or organized crime) will probably ask you nicely (because you are probably obliged by law to give password if there is investigation going or in similar case) or use wrench since it's cheaper. Again - my opinion.

As far as I understand setting iter time to 1 does not weaken encryption, it makes the algorithm to derive your password less times through some complex algorithm - so basically using your pass phrase as input and producing another pass phrase after N derivations. Encryption algorithms are not affected by this mechanism.

Last edited by Gregosky (2023-02-23 09:28:43)

ewaller · 2023-02-23 15:25:17

Remember one of the basic truths of encryption. Your data are safe as long as the cost of breaking the encryption exceeds the value of the encrypted data. Is your data such that someone is going to spend significant effort attempting to recover it?

lfitzgerald · 2023-02-26 19:18:43

Gregosky wrote:

You already trust faceless multinational company who manufactured your computer/laptop..?

Not with encryption.

Gregosky wrote:

I already trust Kingston with my RAM, it would be some sort of split-mind situation to suddenly not to trust them with some other piece of hardware.

No it wouldn't be, RAM doesn't implement hardware encryption.

Gregosky wrote:

man with wrench

I'm not worried about this.

Gregosky wrote:

you are probably obliged by law to give password

I'm not.

Gregosky wrote:

As far as I understand setting iter time to 1 does not weaken encryption

Then why does it default to much higher iteration counts? That's right, because it makes it much easier to brute force.

I appreciate that you're trying to help, but your advice just makes no sense, sorry. Setting the iteration count really low is not a solution. I even said it in the OP.

ewaller wrote:

Remember one of the basic truths of encryption. Your data are safe as long as the cost of breaking the encryption exceeds the value of the encrypted data. Is your data such that someone is going to spend significant effort attempting to recover it?

What does this have to do with Grub being bad at decrypting Luks?

ewaller · 2023-02-26 19:58:02

It has to do with determining a reasonable level of effort ensure things are secure.
It sounds like you place high value on the security of your data and is steering you away from solutions that you perceive as less secure.

lfitzgerald · 2023-02-26 20:07:45

ewaller wrote:

It has to do with determining a reasonable level of effort ensure things are secure.
It sounds like you place high value on the security of your data and is steering you away from solutions that you perceive as less secure.

It's really quite simple, I want to encrypt /boot with LUKS, and I don't want a pitifully low iteration count. Grub only supports Luks1 for this and is very slow. So the question is, is there any way to make Grub faster, or is there another bootloader that is better?

I'm confused that a bunch of people who seemingly don't know how to accomplish what I'm trying to do, are now trying to convince me that instead I want to do something else, just so their solution can work. But no, I am in fact pretty sure that I want to encrypt my /boot with LUKS and a reasonably high iteration count, and I want it to decrypt reasonably fast. This is a very common use case, I feel like it's silly to try and derail this thread into a debate about justifying it. For people who want to debate theory, there are lots of places to do that. This thread, I think, is not one of them.

Imagine you make a thread on a baking forum, saying you baked some bread using a common recipe from the baking wiki and it came out soggy, so is there a way to make it less soggy. Suddenly some people show up saying "why do you want to bake your own bread anyway? you think you'll do better than the bread company? they've been baking bread for years and they get regularly inspected by the fda it's perfectly good bread. just go to the store and buy some bread! there, problem solved". Okay, but not the point lol

Last edited by lfitzgerald (2023-02-26 20:19:25)

Strike0 · 2023-02-26 21:05:21

First, if you added multiple keys for your encrypted /boot, grub decryption will try them one after the other. If your passphrase is for the second slot, it will take time failing the first. So, if you have multiple keys or try to tune your existing grub decrypt with another key for a lower --iter-time, make sure it is in the first LUKS slot.

Your post does not state what system (specs, bios) you use and what iteration count it achieves in grub (and what "pitifully low" implies for you). It reads like you use the defaults, do research your desired iteration level first.

As another option, there is also a grub patched for argon2 in the aur. If you're happy with the patches it makes, perhaps give that a try.
As a final option, you can also wait until argon2 lands in grub-git and be happy you have resisted the 5-10 second wait. I, for one, manage to get a glass of water while grub iterates forward

lfitzgerald · 2023-02-27 01:11:34

Thanks for the response.

Strike0 wrote:

First, if you added multiple keys for your encrypted /boot, grub decryption will try them one after the other. If your passphrase is for the second slot, it will take time failing the first. So, if you have multiple keys or try to tune your existing grub decrypt with another key for a lower --iter-time, make sure it is in the first LUKS slot.

I know that in my case Grub uses the intended key slot. I tried the other slots, they take several minutes.

Strike0 wrote:

Your post does not state what system (specs, bios) you use

If I provided specs, would it help resolve the issue? Which ones are relevant?

Strike0 wrote:

It reads like you use the defaults

Of course not. The "default" is that cryptsetup runs a benchmark to figure out how many iterations your computer can do in 1 second on whatever system you use to set up the drive. This is usually the Arch live ISO, in which the number comes out to several million. If you try to make Grub use that it will be painfully slow, multiple minutes.

I'm asking more out of curiosity, so that I can improve my writing: In what way does it "read like I use the defaults"? Where do you get that? I say in the OP that it takes 5-10 secs (defaults take much longer), I say that iteration count is *already* too low and I don't want to *decrease it more*. This implies that I have already decreased it, because I say "decrease it *more*". From this, I thought it would be clear that I know what --iter-time is and have tried to use it.

Strike0 wrote:

what iteration count it achieves in grub

This is explained in https://gitlab.com/cryptsetup/cryptsetu … dQuestions under "5.10 What is "iteration count" and why is decreasing it a bad idea?". The default iteration count is considered safe and the FAQ advises against reducing it. In my case, I have already reduced it to 1/20th of the default, because that default is way too slow with Grub. So I've already made my encryption 20x less secure than what is recommended, and yet people in this thread for some reason are telling to reduce it even further.

Strike0 wrote:

what "pitifully low" implies for you

It implies that it is possible to try >1k passphrases per second on a consumer PC with average specs. Coincidentally, that other person's "advice" of using --iter-time 1 would produce exactly such a pitifully low iteration count.

Strike0 wrote:

As another option, there is also a grub patched for argon2 in the aur. If you're happy with the patches it makes, perhaps give that a try.

First relevant suggestion in the whole thread. Thank you! I wasn't aware of this patch. How does it work, does it allow Grub to use Luks2? Can you link to the AUR package?

Strike0 wrote:

As a final option, you can also wait until argon2 lands in grub-git and be happy you have resisted the 5-10 second wait. I, for one, manage to get a glass of water while grub iterates forward

Like the Arch project, I pride myself on practicality, so I keep a pitcher with water on my desk instead of getting up every time. So I'm afraid this doesn't work for me

On a more serious note, is there actually a plan to support argon2 in grub?

frostschutz · 2023-02-27 10:04:24

lfitzgerald wrote:

So I've already made my encryption 20x less secure than what is recommended, and yet people in this thread for some reason are telling to reduce it even further.

People are trying to offer practical solutions which can be used now, today. Grub is still being very actively developed, so Grub itself getting faster might happen one day. But talking about it won't change anything until then.

The cryptsetup FAQ you linked states the same things already stated here... the iter count is """protection against use of low-entropy passphrases""" and """Of course the best thing is to have a high-entropy passphrase.""" furthermore """Now, what about decreasing the iteration time? This is generally a very bad idea, unless you know and can enforce that the users only use high-entropy passphrases."""

You can not realistically change Grub's slow hash rate for now (unless you are a developer or a patch is available already). But you can directly choose your own passphrase and make sure it has high entropy. Doing so would not make your encryption less secure at all.

https://xkcd.com/936/ explains password entropy. For encryption, go for way more than 44 bits… you can stop at 128 bits

Last edited by frostschutz (2023-02-27 10:07:46)

frostschutz · 2023-02-27 10:29:19

lfitzgerald wrote:

On a more serious note, is there actually a plan to support argon2 in grub?

You can read on the grub devel mailing list when the argon2 patch was submitted. There were issues with the license of the argon2 code, and also issues with the memory requirements of argon2.

There is work on a memory allocator https://git.savannah.gnu.org/cgit/grub. … e1185700bc where the commit message explicitely mentions "upcoming support for the Argon2 key derival function in LUKS2"

So there are plans and it will happen one day. Whether it will be fast is another matter... Grub is complicated, there is no OS, no memory, CPU instructions like SSE are not available... Grub's crypto is slow for reasons.

The other alternative I mentioned (boot a minimal unencrypted kernel, use it to do your crypto and to boot your real kernel) was also ignored by yous :-) well, it's a bit much.

Personally I'm happy without /boot encryption. It only complicates things unnecessarily. Everything else is encrypted, that's good enough for me.

Last edited by frostschutz (2023-02-27 10:29:29)

Strike0 · 2023-02-27 10:34:44

Yes, I perfectly agree to frostschutz, i.e. balance the complexity of your passphrase when you deviate from iteration defaults. It makes no difference to unlocking the device at all, whether your passphrase is complex or how long it is, but helps you balance an acceptable decryption time.

lfitzgerald wrote:

Like the Arch project, I pride myself on practicality, so I keep a pitcher with water on my desk instead of getting up every time. So I'm afraid this doesn't work for me

That's great. I do similar occasionally, do like standing up for a short stroll too though. Also I do like to sprinkle some fresh lemon into the water at times, but not that often that I keep the lemon on the desk and rather get fresh slices. Anyway ..

You did not mention in your OP that you already lowered defaults, just state "5-10 seconds are too long" and don't provide further information (like 1/20th, etc). That's why I made those remarks. I did indeed overlook that frostschutz already advised on the key-slot relevance in the first reply, but you never replied to their advice re-confirming you are aware.

The relevant specs to me would be something like the cryptsetup benchmark for the hashrates on your system, followed by the actual settings you have chosen to encrypt the LUKS master and the relevant info from the header it has resulted in (Hash spec, MK bits, MK iterations from cryptsetup luksDump for the boot device). Since we all know the grub implementation is much slower, it would be useful to know if you have tried to test how much slower it is on your system (i.e. close/unmount /boot, unlock it from the booted system - how many seconds does it take compared to the five (or ten? It should be perfectly reproducible at boot). Plus, anything else you consider relevant specs and information that would be helpful for an informative OP asking for advice.

lfitzgerald · 2023-03-02 06:23:37

Strike0 wrote:

cryptsetup benchmark for the hashrates on your system

$ cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1      1952655 iterations per second for 256-bit key
PBKDF2-sha256    3628290 iterations per second for 256-bit key
PBKDF2-sha512    1474790 iterations per second for 256-bit key
PBKDF2-ripemd160  836185 iterations per second for 256-bit key
PBKDF2-whirlpool  648871 iterations per second for 256-bit key
argon2i       4 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id      6 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
#     Algorithm |       Key |      Encryption |      Decryption
        aes-cbc        128b      1206.6 MiB/s      3568.1 MiB/s
    serpent-cbc        128b       113.9 MiB/s       405.6 MiB/s
    twofish-cbc        128b       235.1 MiB/s       427.1 MiB/s
        aes-cbc        256b       936.2 MiB/s      3095.2 MiB/s
    serpent-cbc        256b       118.8 MiB/s       422.1 MiB/s
    twofish-cbc        256b       245.3 MiB/s       431.2 MiB/s
        aes-xts        256b      2894.2 MiB/s      2566.7 MiB/s
    serpent-xts        256b       379.0 MiB/s       385.1 MiB/s
    twofish-xts        256b       395.9 MiB/s       397.4 MiB/s
        aes-xts        512b      2516.8 MiB/s      2523.0 MiB/s
    serpent-xts        512b       382.8 MiB/s       376.4 MiB/s
    twofish-xts        512b       399.6 MiB/s       391.6 MiB/s

Strike0 wrote:

actual settings you have chosen to encrypt the LUKS master and the relevant info from the header it has resulted in (Hash spec, MK bits, MK iterations from cryptsetup luksDump for the boot device).

I assume by "LUKS master" you mean the encrypted /boot? It was made with cryptsetup --type luks1 --iter-time 100 luksFormat /dev/sda1.

Hash is sha256, MK bits 512, MK iters 283580. Iterations on the key are 224413.

Strike0 wrote:

it would be useful to know if you have tried to test how much slower it is on your system (i.e. close/unmount /boot, unlock it from the booted system - how many seconds does it take compared to the five (or ten? It should be perfectly reproducible at boot).

It takes about half a second.

I guess I'll ask this too: If I want to encrypt my boot partition with LUKS, is GRUB my only option?

3beb6e7c46a615a · 2023-03-02 11:47:02

lfitzgerald wrote:

I guess I'll ask this too: If I want to encrypt my boot partition with LUKS, is GRUB my only option?

I'm not aware of any other, and I doubt that other bootloaders would bother about encrypted /boot these days. In general, encrypting boot doesn't add trust, neither in BIOS nor in EFI systems. Under traditional BIOS boot encrypting /boot just makes things harder, but since you can't encrypt the boot sector itself, the boot chain is effectively untrusted. In EFI the firmware establishes trust through secure boot (especially with fresh keys); you don't need encrypted /boot for this.

Neither does encrypting boot provide confidentiality in general; most people use distribution kernels, so it's not hard to predict what's stored on a /boot partition. And in EFI setups it's not possible to encrypt the system partition anyway, so it's not possible to hide what's being booted.

I'm not saying this convince you to change your setup; I'm just trying to explain why I believe you'll have a hard time improving the situation. Your use case is rather niche, and I don't think many people are working to improve it.

The general community moves towards EFI, UKIs and secure boot, which (firmware issues aside) can establish a completely trusted boot chain rooted in the firmware, with much less complexity in the boot loader.

Last edited by 3beb6e7c46a615a (2023-03-02 11:47:25)

Strike0 · 2023-03-02 21:34:15

Coincidently, regarding secureboot, blacklotus was publicly released yesterday.

lfitzgerald wrote:

Hash is sha256, MK bits 512, MK iters 283580. Iterations on the key are 224413.
...
It takes about half a second.

Yes, for the encrypted /boot. It's indeed apparent how you shaved iterations to save hashing time and I'd personally would not do it that much, to rely on it. Sorry, I don't see room to improve times right away. If I have a suggestion, I'll return it. The limitation to a single-try to enter the passphrase with grub is another reason I'd rather stick to more iterations than an overly complex passphrase.

lfitzgerald wrote:

I guess I'll ask this too: If I want to encrypt my boot partition with LUKS, is GRUB my only option?

Yes, afaik. If you need a trusted boot chain, also consider the other options mentioned above, secureboot probably the most widely supported (and fastest to boot). I write from an old system which has no reliable UEFI support, that's why I have encrypted /boot on it.

lfitzgerald · 2023-03-04 01:07:56

Strike0 wrote:

Yes, afaik. If you need a trusted boot chain, also consider the other options mentioned above, secureboot probably the most widely supported (and fastest to boot).

NTA but I find it ironic that you mention a malware targeting secureboot and recommend me secureboot in the same post.

lunaryorn wrote:

The general community moves towards EFI, UKIs and secure boot, which (firmware issues aside) can establish a completely trusted boot chain rooted in the firmware, with much less complexity in the boot loader.

Thanks. This actually makes sense. I know there's a push towards UEFI and UEFI offers solutions that make encryption of boot irrelevant, like the secure boot you mention. I'm personally skeptical of those solutions, but that's a tired argument that's been rehashed a million times all over the internet, it would be boring to go into it here.

tl;dr for people who later find this thread on Google: I was hoping to do better than the "standard" setup of encrypting /boot with luks1 and using GRUB_ENABLE_CRYPTODISK=y. It turns out there's not a real way to do better, and much of the community has decided that secure boot etc. is good enough. There's an argon2 patch for grub that's floating around, but not part of the official grub yet. I guess I'll just accept the delay at boot.

If you do discover a solution, please update the arch wiki where people can find it.

Arch Linux

#1 2023-02-05 03:36:24

[GAVE UP]Encrypted boot with GRUB, it sucks. Is there anything better?

#2 2023-02-05 12:54:13

Re: [GAVE UP]Encrypted boot with GRUB, it sucks. Is there anything better?

#3 2023-02-05 16:50:35

Re: [GAVE UP]Encrypted boot with GRUB, it sucks. Is there anything better?

#4 2023-02-07 23:39:11

Re: [GAVE UP]Encrypted boot with GRUB, it sucks. Is there anything better?

#5 2023-02-08 07:34:12

Re: [GAVE UP]Encrypted boot with GRUB, it sucks. Is there anything better?

#6 2023-02-08 10:05:03

Re: [GAVE UP]Encrypted boot with GRUB, it sucks. Is there anything better?

#7 2023-02-12 05:29:19

Re: [GAVE UP]Encrypted boot with GRUB, it sucks. Is there anything better?

#8 2023-02-13 07:51:40

Re: [GAVE UP]Encrypted boot with GRUB, it sucks. Is there anything better?

#9 2023-02-15 00:15:44

Re: [GAVE UP]Encrypted boot with GRUB, it sucks. Is there anything better?

#10 2023-02-15 08:20:55

Re: [GAVE UP]Encrypted boot with GRUB, it sucks. Is there anything better?

#11 2023-02-23 00:26:13

Re: [GAVE UP]Encrypted boot with GRUB, it sucks. Is there anything better?

#12 2023-02-23 09:14:04

Re: [GAVE UP]Encrypted boot with GRUB, it sucks. Is there anything better?

#13 2023-02-23 15:25:17

Re: [GAVE UP]Encrypted boot with GRUB, it sucks. Is there anything better?

#14 2023-02-26 19:18:43

Re: [GAVE UP]Encrypted boot with GRUB, it sucks. Is there anything better?

#15 2023-02-26 19:58:02

Re: [GAVE UP]Encrypted boot with GRUB, it sucks. Is there anything better?

#16 2023-02-26 20:07:45

Re: [GAVE UP]Encrypted boot with GRUB, it sucks. Is there anything better?

#17 2023-02-26 21:05:21

Re: [GAVE UP]Encrypted boot with GRUB, it sucks. Is there anything better?

#18 2023-02-27 01:11:34

Re: [GAVE UP]Encrypted boot with GRUB, it sucks. Is there anything better?

#19 2023-02-27 10:04:24

Re: [GAVE UP]Encrypted boot with GRUB, it sucks. Is there anything better?

#20 2023-02-27 10:29:19

Re: [GAVE UP]Encrypted boot with GRUB, it sucks. Is there anything better?

#21 2023-02-27 10:34:44

Re: [GAVE UP]Encrypted boot with GRUB, it sucks. Is there anything better?

#22 2023-03-02 06:23:37

Re: [GAVE UP]Encrypted boot with GRUB, it sucks. Is there anything better?

#23 2023-03-02 11:47:02

Re: [GAVE UP]Encrypted boot with GRUB, it sucks. Is there anything better?

#24 2023-03-02 21:34:15

Re: [GAVE UP]Encrypted boot with GRUB, it sucks. Is there anything better?

#25 2023-03-04 01:07:56

Re: [GAVE UP]Encrypted boot with GRUB, it sucks. Is there anything better?

Board footer