Mailing List Archive: Possibility to introduce a new log crypto provider

Possibility to introduce a new log crypto provider

Apr 15, 2024, 2:54 AM

Post #1 of 8 (73 views)

Hello,

Currently, log messages written to files can undergo encryption using the
libgcrypt cryptographic library [1]. This works fine, logs can be encoded
and successfully decoded but I think the library has some drawbacks:

- algorithms are hardcoded, if someone would want to use something else,
then they would need to request it first
- the same applies to the algorithm mode
- If I am not mistaken, the libgcrypt library is part of rsyslog only
for this purpose -> adds extra dependency that maintainers need to cover

I would like to ask if there is any chance that a new crypto provider will
be part of the project in the future? For example openssl (or gnutls) could
provide the same functionality and it could reduce the amount of
dependencies the project currently has. I would gladly craft a patch or two.
What do you think?

[1] https://www.rsyslog.com/doc/configuration/cryprov_gcry.html

Attila
_______________________________________________
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.

Re: Possibility to introduce a new log crypto provider [ In reply to ]

rsyslog at lists

Apr 15, 2024, 3:08 AM

Post #2 of 8 (73 views)

Permalink

Sound good to me, as long as everything is backwards-compatible ;-)

Else we need to discuss pro and con (I guess there a lot of pro!)

Rainer

El lun, 15 abr 2024 a las 11:55, Attila Lakatos via rsyslog
(<rsyslog@lists.adiscon.com>) escribió:

>
> Hello,
>
> Currently, log messages written to files can undergo encryption using the
> libgcrypt cryptographic library [1]. This works fine, logs can be encoded
> and successfully decoded but I think the library has some drawbacks:
>
> - algorithms are hardcoded, if someone would want to use something else,
> then they would need to request it first
> - the same applies to the algorithm mode
> - If I am not mistaken, the libgcrypt library is part of rsyslog only
> for this purpose -> adds extra dependency that maintainers need to cover
>
> I would like to ask if there is any chance that a new crypto provider will
> be part of the project in the future? For example openssl (or gnutls) could
> provide the same functionality and it could reduce the amount of
> dependencies the project currently has. I would gladly craft a patch or two.
> What do you think?
>
> [1] https://www.rsyslog.com/doc/configuration/cryprov_gcry.html
>
> Attila
> _______________________________________________
> 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.

Re: Possibility to introduce a new log crypto provider [ In reply to ]

rsyslog at lists

Apr 16, 2024, 3:17 AM

Post #3 of 8 (69 views)

Permalink

One approach that comes to my mind is to create a brand new provider using
e.g. openssl. Provide
a new configure option to build that. If the new crypto provider is turned
on, then it will be used. Otherwise,
if --enable-libgcrypt was passed to configure, then libgcrypt will be used.
For logs decryption, the rscryutils binary will be compiled based on what
configure option was passed to it.
This ensures that the default behavior is not changed and also we can
add/remove/change CLI options
for the rscryutils prog.
I am open to any suggestions :)

On Mon, Apr 15, 2024 at 12:09?PM Rainer Gerhards <rgerhards@hq.adiscon.com>
wrote:

> Sound good to me, as long as everything is backwards-compatible ;-)
>
> Else we need to discuss pro and con (I guess there a lot of pro!)
>
> Rainer
>
> El lun, 15 abr 2024 a las 11:55, Attila Lakatos via rsyslog
> (<rsyslog@lists.adiscon.com>) escribió:
>
> >
> > Hello,
> >
> > Currently, log messages written to files can undergo encryption using the
> > libgcrypt cryptographic library [1]. This works fine, logs can be encoded
> > and successfully decoded but I think the library has some drawbacks:
> >
> > - algorithms are hardcoded, if someone would want to use something
> else,
> > then they would need to request it first
> > - the same applies to the algorithm mode
> > - If I am not mistaken, the libgcrypt library is part of rsyslog only
> > for this purpose -> adds extra dependency that maintainers need to
> cover
> >
> > I would like to ask if there is any chance that a new crypto provider
> will
> > be part of the project in the future? For example openssl (or gnutls)
> could
> > provide the same functionality and it could reduce the amount of
> > dependencies the project currently has. I would gladly craft a patch or
> two.
> > What do you think?
> >
> > [1] https://www.rsyslog.com/doc/configuration/cryprov_gcry.html
> >
> > Attila
> > _______________________________________________
> > 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.

Re: Possibility to introduce a new log crypto provider [ In reply to ]

rsyslog at lists

Apr 16, 2024, 3:32 AM

Post #4 of 8 (69 views)

Permalink

While this approach makes it easier to add new algorithms, it isn't going to do
anything to reduce the load on the maintainers.

Is there any way to duplicate the existing functionality with openssl or gnutls
libraries?

given that some people prefer openssl and some prefer gnutls, I think that we
will need to make the new option work with both.

David Lang

On Tue, 16 Apr 2024, Attila Lakatos via rsyslog wrote:

> One approach that comes to my mind is to create a brand new provider using
> e.g. openssl. Provide
> a new configure option to build that. If the new crypto provider is turned
> on, then it will be used. Otherwise,
> if --enable-libgcrypt was passed to configure, then libgcrypt will be used.
> For logs decryption, the rscryutils binary will be compiled based on what
> configure option was passed to it.
> This ensures that the default behavior is not changed and also we can
> add/remove/change CLI options
> for the rscryutils prog.
> I am open to any suggestions :)
>
> On Mon, Apr 15, 2024 at 12:09?PM Rainer Gerhards <rgerhards@hq.adiscon.com>
> wrote:
>
>> Sound good to me, as long as everything is backwards-compatible ;-)
>>
>> Else we need to discuss pro and con (I guess there a lot of pro!)
>>
>> Rainer
>>
>> El lun, 15 abr 2024 a las 11:55, Attila Lakatos via rsyslog
>> (<rsyslog@lists.adiscon.com>) escribió:
>>
>> >
>> > Hello,
>> >
>> > Currently, log messages written to files can undergo encryption using the
>> > libgcrypt cryptographic library [1]. This works fine, logs can be encoded
>> > and successfully decoded but I think the library has some drawbacks:
>> >
>> > - algorithms are hardcoded, if someone would want to use something
>> else,
>> > then they would need to request it first
>> > - the same applies to the algorithm mode
>> > - If I am not mistaken, the libgcrypt library is part of rsyslog only
>> > for this purpose -> adds extra dependency that maintainers need to
>> cover
>> >
>> > I would like to ask if there is any chance that a new crypto provider
>> will
>> > be part of the project in the future? For example openssl (or gnutls)
>> could
>> > provide the same functionality and it could reduce the amount of
>> > dependencies the project currently has. I would gladly craft a patch or
>> two.
>> > What do you think?
>> >
>> > [1] https://www.rsyslog.com/doc/configuration/cryprov_gcry.html
>> >
>> > Attila
>> > _______________________________________________
>> > 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.
_______________________________________________
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.

Re: Possibility to introduce a new log crypto provider [ In reply to ]

rsyslog at lists

Apr 16, 2024, 4:17 AM

Post #5 of 8 (69 views)

Permalink

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.

-derek

--
Derek Atkins 617-623-3745
derek@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.

Re: Possibility to introduce a new log crypto provider [ In reply to ]

rsyslog at lists

Apr 16, 2024, 11:40 PM

Post #6 of 8 (64 views)

Permalink

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
> derek@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.

Re: Possibility to introduce a new log crypto provider [ In reply to ]

rsyslog at lists

Apr 16, 2024, 11:50 PM

Post #7 of 8 (64 views)

Permalink

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 <alakatos@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
>> derek@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.

Re: Possibility to introduce a new log crypto provider [ In reply to ]

rsyslog at lists

Apr 17, 2024, 1:01 AM

Post #8 of 8 (64 views)

Permalink

On Wed, 17 Apr 2024, Attila Lakatos via rsyslog 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.

to be backwards compatible, the existing configs would need to keep working,
even if they are implemented differently under the covers.

So while you may be able to do it with a single parameter with a different
library, you still need to have a shim module that accepts the old parameters
and does the conversion to new parameters under the covers.

If it would break the existing configs, it means we can't remove the old
functionality, so instead of reducing maintainer effort, it would just add to
it.

David Lang

>
>>
>> -derek
>>
>> --
>> Derek Atkins 617-623-3745
>> derek@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.
_______________________________________________
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.