4 ms·
That's also a peeve of mine. Is there a way at all for grub to use hardware acceleration there? Or maybe the bootloader isn't allowed to do such things
by nextaccountic 1y ago
That's also a peeve of mine. Is there a way at all for grub to use hardware acceleration there? Or maybe the bootloader isn't allowed to do such things
- shmerl 1y agoYes - use newer libcrypto. They are in the process of switching, but it just takes very long. I don't see why bootloader won't be allowed to use the CPU features that accelerate decryption.
- nextaccountic 1y ago> They are in the process of switching, Nice! Do you have a link with the progress of this? Maybe in a mailing list or something. I can't manage to find it Also, do you know whether grub plans to support luks2? And maybe even veracrypt - ok this one is unlikely. (cryptsetup can read veracrypt just fine and the Linux kernel copes with it, maybe it's a matter of porting this code to grub? One issue is that grub would need to embed the number of iterations of the key derivation function somehow - the thing veracrypt calls PIM - because unlike luks, veracrypt doesn't store it in a header that can be read before unencrypting)
- shmerl 1y agoThe main bug is here: https://savannah.gnu.org/bugs/?55093 https://savannah.gnu.org/bugs/?55093 But I do recall some other post which went into more details and was saying that switching was taking time due to lack of stable API and other issues. Try searching for grub 2 + libgcrypt. Some links are also in that bug.