Add ability to calculate filedigests using Streebog-256 and Streebog-… #1082

StZhukov · 2020-02-20T20:33:45Z

…512 RFC 6986.

This patch adds ability to calculate filedigests (hashsums of files inside rpm package) using Streebog-256 and Streebog-512 - hashsum calculating algorithms standartized by GOST R 34.10-2012, Russian national standard.

Streebog (another name is Stribog) has existed for quite long time in libgcrypt, and now, after RPM switched to libgcrypt as the default crypto backend, this patch adds ability to use Streebog-256 and Streebog-512 to calculate file digest.

Our plan is to use these digests to sign them using rpmsign --signfile. First, I would like to receive feedback and get this initial implemetation merged. After that I am planning to extend usage of GOST.

I previously implemented the same in rpm5 (https://abf.io/soft/rpm5/commits/master), and it works. As ROSA is switching from rpm5 to rpm4, we would like to contribute our work to upstream. It may be useful for other people who have to follow some special information security requirements or those who do not trust other algorithms for some reasons.

…512 RFC 6986. This patch adds ability to calculate filedigests (hashsums of files inside rpm package) using Streebog-256 and Streebog-512 - hashsum calculating algorithms standartized by GOST R 34.10-2012, Russian national standard. Streebog (another name is Stribog) has existed for quite long time in libgcrypt, and now, after RPM switched to libgcrypt as the default crypto backend, this patch adds ability to use Streebog-256 and Streebog-512 to calculate file digest. Our plan is to use these digests to sign them using rpmsign --signfile. First, I would like to receive feedback and get this initial implemetation merged. After that I am planning to extend usage of GOST. I previously implemented the same in rpm5 (https://abf.io/soft/rpm5/commits/master), and it works. As ROSA is switching from rpm5 to rpm4, we would like to contribute our work to upstream. It may be useful for other people who have to follow some special information security requirements or those who do not trust other algorithms for some reasons.

Conan-Kudo

It's a good first start, just some initial nits...

Conan-Kudo · 2020-02-21T01:51:29Z

configure.ac

@@ -395,6 +395,7 @@ AC_SUBST(WITH_OPENSSL_LIB)
 WITH_LIBGCRYPT_INCLUDE=
 WITH_LIBGCRYPT_LIB=
 if test "$with_crypto" = libgcrypt ; then
+  AC_DEFINE(WITH_LIBGCRYPT, 1, [Build with libgcrypt instead of nss3 support?])


Why the instead of nss3 support?? This could just be Build with libgcrypt as the crypto backend.

Thanks, I will change.

Conan-Kudo · 2020-02-21T01:52:29Z

lib/rpmds.c

+     */
+    { "rpmlib(FileDigestsGOST12)", 		"4.16.0-1",
+	(		 RPMSENSE_RPMLIB|RPMSENSE_EQUAL),
+    N_("file digest can be GOST R 34.11 2012 (STREEBOG256, STREEBOG512)") },


I'm not sure how to word this yet, but I don't like this wording much...

Sorry, I did not understand, what do you mean?

We don't track individual file digest algorithms for anything else either, lets keep it that way.
Rpm needs to better deal with unknown algorithms but rpmlib() dependencies are such a clumsy and ugly way...

Conan-Kudo · 2020-02-21T01:53:16Z

rpmio/rpmpgp.h

@@ -266,6 +266,8 @@ typedef enum pgpHashAlgo_e {
    PGPHASHALGO_SHA384		=  9,	/*!< SHA384 */
    PGPHASHALGO_SHA512		= 10,	/*!< SHA512 */
    PGPHASHALGO_SHA224		= 11,	/*!< SHA224 */
+    PGPHASHALGO_GOST12_256	= 100,	/*!< GOST R 34.11-2012 256 */
+    PGPHASHALGO_GOST12_512	= 101,	/*!< GOST R 34.11-2012 512 */


Is there a reason we jump so many values?

It should match the hash algorithm id used in pgp.

12 is SHA3-256, 14 is SHA3-512. 100-110 is reserved for Private/Experimental algorithms.

See https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-05

(I'd actually prefer to use official values. Is the GOST project in contact with the pgp folks?)

@mlschroe What is "the GOST project"? I am not aware of any attempts to include GOST to OpenPGP RFC, but maybe someone tried, I do not know. We in ROSA with @StZhukov first wanted to implement signing RPM payload with GOST as it is signed with gpg, but then we found out that OpenPGP RFC does not support GOST, so implementing it does not make much sense. I would not expect GOST algos to appear in the RFC in the nearest future. Because of all this I would suggest to use values >110 here, which are not specified in the RFC and so will never become used by other algorithms.

Dunno, I thought something like http://gostcrypt.github.io/

pmatilai

Please ask for at least a reservation for the GOST algorithms in OpenPGP RFC, I don't see this being acceptable otherwise.

The other option would be detaching the digest algorithm enumeration used by rpm for non-PGP purposes from the OpenPGP values. This would probably be the most "correct" thing to do anyway, but also the one that requires most work and churn.

mikhailnov · 2020-02-24T10:18:59Z

The other option would be detaching the digest algorithm enumeration used by rpm for non-PGP purposes from the OpenPGP values

If to make values out of the range specified by the OpenPGP RFC (e.g. 250 and 251 or whatever else), they will still be called PGPHASHALGO_*, but may it break anything elsewhere in RPM?

mikhailnov · 2020-02-24T10:26:32Z

RPM 5 did it: https://abf.io/soft/rpm5/blob/master/rpmio/rpmiotypes.h#lc-204
Will the same approach be acceptable in rpm4?

Conan-Kudo · 2020-02-24T10:34:55Z

RPM 5 did it: https://abf.io/soft/rpm5/blob/master/rpmio/rpmiotypes.h#lc-204
Will the same approach be acceptable in rpm4?

Well, rpm5 compatibility is an explicit non-goal, so it's not likely to sway anyone on this...

pmatilai · 2020-02-24T10:52:44Z

What I meant by detaching is declare a separate RPMHASHALGO_FOO enumeration that is free of OpenPGP constraints and then adjust the entire codebase to use that as appropriate, but that seems like quite a bit of busywork and churn.

Please try to get GOST included in OpenPGP officially, that's what you really wanted to begin with as per above comments. That'd be the win-win situation here. As per https://tools.ietf.org/html/rfc4880#section-10.3.3:

The initial values for this registry can be found in
Section 9 for the algorithm identifiers and text names, and Section
5.2.2 for the OIDs and expanded signature prefixes. Adding a new
hash algorithm MUST be done through the IETF CONSENSUS method, as
described in https://tools.ietf.org/html/rfc2434

pmatilai · 2020-02-24T11:25:44Z

Oh and to clarify, what I mean by "getting into OpenPGP" is at least try to get a reservation for the algorithm(s). There are any number of such reservations in the RFC and one would think that it wouldn't require jumping through too many hoops.

Temporarily use the same OIDs for GOST as we used in RPM 5 to ensure RPM 5 is able to install those packages from rpm5 to boostrap rosa2019.05 based on packages from rosa2019.0. This needs to be reworked before upstream inclusion. Cf. rpm-software-management#1082

pmatilai · 2022-01-25T13:06:44Z

Coming back to this after much too long a while:

Private/experimental values are best left alone in what is a very public project with long-lived artifacts (aka rpms). Rpm is wrong to use the PGP hash algorithm values for entirely different purposes, that's where the problem starts and to fix it, we just need to untangle that connection. Otherwise this will keep coming up again and again.

Closing this but opened #1899 to track the underlying issue.

Conan-Kudo suggested changes Feb 21, 2020

View reviewed changes

pmatilai requested changes Feb 24, 2020

View reviewed changes

pmatilai mentioned this pull request Jan 25, 2022

Decouple rpm's hash algorithm values from OpenPGP standard #1899

Closed

pmatilai closed this Jan 25, 2022

pmatilai mentioned this pull request Feb 24, 2022

Begin decoupling rpm's crypto API's from PGP #1937

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add ability to calculate filedigests using Streebog-256 and Streebog-… #1082

Add ability to calculate filedigests using Streebog-256 and Streebog-… #1082

StZhukov commented Feb 20, 2020

Conan-Kudo left a comment

Conan-Kudo Feb 21, 2020

StZhukov Feb 21, 2020

Conan-Kudo Feb 21, 2020

StZhukov Feb 21, 2020

pmatilai Feb 24, 2020

Conan-Kudo Feb 21, 2020

mlschroe Feb 21, 2020

mlschroe Feb 21, 2020

mikhailnov Feb 21, 2020

mlschroe Feb 21, 2020

pmatilai left a comment

mikhailnov commented Feb 24, 2020

mikhailnov commented Feb 24, 2020

Conan-Kudo commented Feb 24, 2020

pmatilai commented Feb 24, 2020 •

edited

pmatilai commented Feb 24, 2020

pmatilai commented Jan 25, 2022

Add ability to calculate filedigests using Streebog-256 and Streebog-… #1082

Add ability to calculate filedigests using Streebog-256 and Streebog-… #1082

Conversation

StZhukov commented Feb 20, 2020

Conan-Kudo left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pmatilai left a comment

Choose a reason for hiding this comment

mikhailnov commented Feb 24, 2020

mikhailnov commented Feb 24, 2020

Conan-Kudo commented Feb 24, 2020

pmatilai commented Feb 24, 2020 • edited

pmatilai commented Feb 24, 2020

pmatilai commented Jan 25, 2022

pmatilai commented Feb 24, 2020 •

edited