grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: State of Argon2 support


From: Nikolaos Chatzikonstantinou
Subject: Re: State of Argon2 support
Date: Tue, 30 Jan 2024 10:18:20 -0500

I want to share a small update:

I'm reading the GRUB source code for the memory manager to get a bit
acclimated.  I was surprised to see libgcrypt depend on <stdio.h>.
Asking around, the monocypher library was brought to my attention,
<https://monocypher.org/>. No external dependencies, the license is
compatible, just two files monocypher.c and .h that can be bundled,
supports argon2, and it's already used by some bootloaders/firmware
(ArduPilot Project, Joulescope). It is however written in pure C99; it
seems to me that it supports architectures that a C99 compiler can
target.

While the goal of upgrading libgcrypt is noble, it is a bit scary as
libgcrypt seems difficult to navigate for me, the import_gcry.py
script also being hard to read. So I have the following questions:

1) What are the cryptographic requirements of GRUB? I.e. which
features and algorithms does GRUB require right now?
2) Can we include monocypher just for the purpose of unlocking
argon2-configured luks2 partitions?
3) Is it of interest to replace libgcrypt entirely (if possible, with
monocypher e.g.?)

If the best plan to go ahead with is to upgrade libgcrypt, as I've
said before, it would be good to know the version currently bundled
with GRUB  (I'm just reiterating this point.) But from my viewpoint,
libgcrypt is a userland library with a wide range of features; perhaps
not the most appropriate for a bootloader. I'm wondering if the
reasons that led to choosing libgcrypt in the past for GRUB can be
reevaluated now that there are more options for cryptographic
libraries.

Regards,
Nikolaos Chatzikonstantinou

On Fri, Jan 26, 2024 at 3:31 PM Vladimir 'phcoder' Serbinenko
<phcoder@gmail.com> wrote:
>
>
>
> Le ven. 26 janv. 2024, 20:50, Daniel Kiper <dkiper@net-space.pl> a écrit :
>>
>> On Fri, Jan 26, 2024 at 03:18:57AM -0500, Nikolaos Chatzikonstantinou wrote:
>> > On Thu, Jan 25, 2024 at 1:15 PM Daniel Kiper <dkiper@net-space.pl> wrote:
>> > >
>> > > Adding Vladimir who knows GRUB history better than I...
>> > >
>> > > On Wed, Jan 24, 2024 at 01:23:55AM -0500, Nikolaos Chatzikonstantinou 
>> > > wrote:
>> > >
>> > > [...]
>> > >
>> > > > My apologies for the repeated messages, but I came up with just one
>> > > > more question that I'm curious about. To summarize my questions:
>> > > >
>> > > > 1. Where is the libgcrypt bundle from grub from? I think my
>> > > > investigation has led me around version 1.7.0 of libgcrypt, but if I
>> > > > can get a precise commit or version, that would be useful.
>> > > >
>> > > > ... and now to my new question:
>> > >
>> > > Vladimir, could you help with that?
>> > >
>> > > > 2. What is the reason libgcrypt is bundled as opposed to a regular 
>> > > > dependency?
>> > >
>> > > I am not entirely sure I understand the question. Could you elaborate?
>> >
>> > By bundling, I mean that someone copied libgcrypt files into the GRUB 
>> > project.
>> >
>> > To elaborate further, regular programs (not like GRUB which is a
>> > bootloader) can link statically or dynamically to libraries; but also,
>> > there's a third option, to dump the source code of a library directly
>> > into the source tree of the project. To my understanding this third
>> > option (which is not really a third linker option as it is not related
>> > to the linker) is chosen when the project needs to include its own
>> > patch set to the library. I am curious if GRUB has patched libgcrypt
>> > for some reason, and is that why libgcrypt is bundled with GRUB?
>>
>> I think Vladimir could tell us more here...
>>
>> Anyway, I think we should avoid patching libgcrypt, or any given library
>> merged with GRUB source, as much as possible.
>
> This was my goal as well. Almost all the changes are difficult to avoid. But 
> at least they are automated in most cases. See import_gcry script. I'm not on 
> my computer now. I hope to find a time to have a look until the end of next 
> week.
>>
>>
>> Daniel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]