Re: State of Argon2 support

[Patrick Steinhardt]

On Fri, Dec 22, 2023 at 09:43:35PM -0600, Oskari Pirhonen wrote:
> On Fri, Dec 22, 2023 at 12:29:22 -0500, Nikolaos Chatzikonstantinou wrote:
> > 2. libgcrypt does not have support for Argon2. Possible solution is to
> > use the reference implementation, licensed under CC0. This is bringing
> > up issues (that I don't fully understand), would be preferable if the
> > authors released under GPLv3. Has there been a follow-up on this?
> > <https://lists.gnu.org/archive/html/grub-devel/2020-03/msg00170.html>
> > 
> 
> Libgcrypt supports Argon2 as of 1.10 (March 2022). The version of
> libgcrypt that is bundled with GRUB is older than that.
> 
> - Oskari

Indeed. There are two different ways to implement Argon2 support in
GRUB:

  - Use the reference implementation of Argon2.

  - Update libgcrypt to a newer version.

I have sent patches that bundles the reference implementation in [1]
quite a while ago. Back then there was the problem that we couldn't
allocate required memory on UEFI-based systems, but we improved the
memory allocator with GRUB 2.12 to support this usecase now.

Still, I consider it to be the inferior option. Back when I posted the
patches (February 2020 originally) there was no Argon2 support in
libgcrypt yet, so it was the obvious choice. But now that libgcrypt does
have support it's a no-brainer to use its version of libgcrypt instead.

Problem is that upgrading the bundled libgcrypt library is not trivial
at all. I've tried multiple times, and every single time I quickly gave
up. There's simply too many things that have changed, and GRUB does have
quite a lot of patches on top of the current bundled version of the
library. Regardless of that it would be the right thing to do, because
in the long run we do want an up-to-date version of libgrcypt regardless
of Argon2 support anyway.

That being said, I do not see myself updating it given that it's such a
huge and frustrating endeavour to update it. If anybody else wants to
take up this task I'd be more than happy and would definitely want to
rebase my own patches on top of this work. But until somebody steps up
to handle this task it's not going to happen.

The alternative would be to just live with the current state of my patch
series, where we use the reference implementation until libgcrypt gets
updated. But I'm not sure whether Daniel would consider pulling this
version (Cc'd him so that he can post his opinion). If he would then I'd
be happy to re-send a rebased version of my patch series.

Patrick

[1]: <cover.1628430731.git.ps@pks.im>

signature.asc
Description: PGP signature