Additionally, I would highlight the following side effects of using libgcrypt: 1. Side-channel vulnerability in libgcrypt - the Marvin Attack https://lists.gnupg.org/pipermail/gcrypt-devel/2024-March/005607.html (see the whole thread) Some might be worried about other side-channel vulnerabilities against it, like the Minerva Attack[1], and the Raccoon Attack[2], given the way they handled one of the oldest, well known, and most straightforward side-channel attacks. The worry isn't purely theoretical, other libraries turned out to be vulnerable already[3,4,5]. 2. They did downgrade their threat model as a result of Marvin too: https://gnupg.org/documentation/security.html compare it to the version from last year
https://web.archive.org/web/20230804061753/https://gnupg.org/documentation/security.html [1] https://minerva.crocs.fi.muni.cz/ [2] https://raccoon-attack.com/ [3] https://nvd.nist.gov/vuln/detail/CVE-2023-6135 [4] https://nvd.nist.gov/vuln/detail/CVE-2024-28834 [5] https://github.com/openssl/openssl/issues/23860 On Wed, Apr 17, 2024 at 8:40 AM Attila Lakatos <alaka...@redhat.com> wrote: > > On Tue, Apr 16, 2024 at 1:17 PM Derek Atkins via rsyslog < > rsyslog@lists.adiscon.com> wrote: > >> Hi David, >> >> On Tue, April 16, 2024 6:32 am, David Lang via rsyslog wrote: >> >> > Is there any way to duplicate the existing functionality with openssl or >> > gnutls >> > libraries? >> >> Without knowing what the current functionality actually is, I would answer >> "yes". At least with OpenSSL (but also with GnuTLS) you have access to >> all the low-level cryptographic methods, so you can go call AES and >> SHA2-256 directly as you wish. So yes, you can use them as generic >> cryptographic APIs. >> > > Even though I don't have a strong crypto background, I agree here. It > provides > ways to handle different algorithms and/or methods. The problematic part > is to make > this compatible with the current libgcrypt implementation. For instance, > the gcry > crypto provider supports various options for *cry.algo* and *cry.mode* > that you can or > can't combine, whilst for openssl this could be achieved by a single > parameter > DHE-RSA-AES256-GCM-SHA384 , etc. So the same functionality could be > achieved > but it needs to be handled differently. I think this is the same scenario > as setting > the *gnutlsPriorityString* option in rsyslog- openssl/gnutls. > > >> >> -derek >> >> -- >> Derek Atkins 617-623-3745 >> de...@ihtfp.com www.ihtfp.com >> Computer and Internet Security Consultant >> >> _______________________________________________ >> rsyslog mailing list >> https://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com/professional-services/ >> What's up with rsyslog? Follow https://twitter.com/rgerhards >> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad >> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you >> DON'T LIKE THAT. >> >> _______________________________________________ rsyslog mailing list https://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
