ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] Can the legacy HAVE_LIBGCRYPT_AEAD check be removed?

From: John Thacker <johnthacker@xxxxxxxxx>
Date: Tue, 13 Jul 2021 02:32:47 +0700
On Tue, Jul 13, 2021 at 2:26 AM Pascal Quantin <pascal@xxxxxxxxxxxxx> wrote:
Hi Matthias,

Le lun. 12 juil. 2021 à 21:22, Dr. Matthias St. Pierre <Matthias.St.Pierre@xxxxxxxxx> a écrit :
Hi all,

in wsgcrypt.h the libgcrypt version is checked to ensure that it supports AEAD ciphers:

        #if GCRYPT_VERSION_NUMBER >= 0x010600 /* 1.6.0 */
        /* Whether to provide support for authentication in addition to decryption. */
        #define HAVE_LIBGCRYPT_AEAD
        #endif

        (see [1])

Given the fact that libgcrypt 1.6.0 was released in 2013-12-16 (see [2]), I was wondering whether after such a long time it would be acceptable to simplify
all the conditional code depending on HAVE_LIBGCRYPT_AEAD by making GCRYPT_VERSION_NUMBER >= 0x010600 a requirement and removing  the
#else code parts.

The reason why I am asking is because the packet-isakmp dissector has some conditional code to emulate AES-GCM using AES-CTR in the absence
of HAVE_LIBGCRYPT_AEAD which I'd like to remove. I did some git history research and noticed that there were some recent commits in 2020 related
to fixing compilation without HAVE_LIBGCRYPT_AEAD  (see [3]). However, I'm not sure whether this was done deliberately to support libgcrypt < 1.6.0
or just out of habit because nobody considered the option of removing the legacy check.

If some changes were done to fix the compilation, it means that some people still use a libgcrypt version older than 1.6.0. And as seen in our CMakeLists.txt file,
the minimum version required for now is 1.5.0.

The minimum version being stuck at 1.5.0 is, I believe, almost entirely due to RHEL/CentOS 7 being stuck at 1.5.3

It's a widely used enough distribution, still scheduled for 3 more years of support, that I think that for now the current approach of supporting it is reasonable. We do warn about it in strong terms.
(The RH package may have some backports of features from later versions, but I haven't looked into it.)

If at some point we want to drop RHEL 7 (and in a similar fashion, SUSE Enterprise Server 12), there's a number of packages whose version could be bumped, as seen on that page.

John Thacker