As detailed at http://www.cypherpunks.ru/gost/English.html and https://en.wikipedia.org/wiki/Streebog the streebog algorithm is a modern hashing algorithm from Russia with example implementations in python and go. It may be worth considering adding it to the range of hash functions in order to increase their diversity. Reproducible: Always Steps to Reproduce: 1. Download file for package build. Actual Results: Major western algorithms trusted (SHA256, SHA512, WHIRLPOOL). Expected Results: Broader range of algorithms utilized to establish trust in file identity. Apparently the SHA algorithms have FIPS (US) and NESSIE (EU) certification. Whirlpool has NESSIE (EU) certification. Streebog has GOST (Russian) certification. The addition of this algorithm would therefore appear to significantly increase the conceptual diversity of algorithm origin.
I don't think this makes any sense. "diversity of algorithm origin" isn't any technical goal we should pursue. (Actually, for simplicity I'd rather suggest considering doing the opposite and use just one secure hash function instead of three.) Other than that I don't think streebog support is part of any piece of software that's part of the Gentoo base system. So we'd have to either introduce a new dependency to the base system or ship an implementation with portage.
Given that admit that you weren't even aware three hash algorithms were running (https://news.ycombinator.com/item?id=12765206) and you're a Gentoo dev(!), I wonder why you feel qualified to suggest deprecating a multi-algorithm approach to file validation? Gentoo packages are used to build large numbers of systems, including other distributions and high security systems. I am sure that Gentoo's rigor of cryptographic validation is part of the attraction for these sorts of users, as the multiple algorithm approach is significantly more secure against cryptographic attacks (known or unknown), rare as these may be. Every package has to be validated against every algorithm by everyone who ever installs it, by design. Is adding another algorithm really going to improve matters measurably? I don't know, probably not much. However, it would seem that having at least one foot out of the EU/US algorithms wouldn't hurt, and if we have a free implementation that's fast and we can ship, why not consider it?
I agree with Hanno here. We're using frequently used = well supported (= supposedly well-tested) algorithms. In particular, Portage is preferably using implementations from built-in Python hashlib [1] module. This includes: In [2]: hashlib.algorithms_available Out[2]: {'DSA', 'DSA-SHA', 'MD4', 'MD5', 'MDC2', 'RIPEMD160', 'SHA', 'SHA1', 'SHA224', 'SHA256', 'SHA384', 'SHA512', 'dsaEncryption', 'dsaWithSHA', 'ecdsa-with-SHA1', 'md4', 'md5', 'mdc2', 'ripemd160', 'sha', 'sha1', 'sha224', 'sha256', 'sha384', 'sha512', 'whirlpool'} (also note:) In [3]: hashlib.algorithms_guaranteed Out[3]: {'md5', 'sha1', 'sha224', 'sha256', 'sha384', 'sha512'} So if you want to have Streebog there, first get it into some major cryptographic library. Portage is not a showcase for cryptographic functions, and Portage developers are certainly not people who feel confident adding cryptographic code that hasn't been verified by people that are really 'into crypto'. That said, please withdraw the Iron Curtain. It's not helping your case. Most of the OSS people judge things by their quality, not country of origin. [1]:https://docs.python.org/3/library/hashlib.html
I agree that the current algorithms are good choices. I note that the python hashlib library's function 'hashlib.algorithms_guaranteed' refers to guaranteed presence of implication, not a qualitative judgement of the algorithm. Thus it should be given no credence whatsoever (except 'ease of implementation'), since presence does not imply appropriateness of use. For example, it reports MD5 (which "suffers from extensive vulnerabilities") as 'guaranteed'. I agree that choice of individual algorithm is not a decision one should take without a strong background in cryptography. However, as we are selecting a range of algorithms, the failure of any individual algorithm is non-critical. I strongly disagree that adding an additional algorithm that may not have mass-market levels of penetration is an idea that should be casually dismissed. Why? 1. It is very cheap. 2. It is a well known truism in cryptography that halfway decent systems are usually worked around rather than broken. Single origin implies a single certification body of influence, a primary documented mode of attack against modern cryptographic standards. Thus, from an architectural perspective, right now we have 2 (two) origins or certification bodies of influence. Adding a third origin would appear to be an option worth discussing, since it is cheap insurance against a known attack vector. I am unsure how to interpret your 'iron curtain' comment, which comes across very questionable. For the record I have never been to Russia, speak Russian or any other Slavic language, or have any other connection with that period or part of the world. If I had, I might be offended. To be clear: I am laying out an architectural option, not an ideological affiliation. Please stay on topic.
s/implication/implementation/ # midnight
Good news, libgcrypt has Streebog, so we might actually use it. Bad news, it doesn't have any Python bindings in Gentoo, and I don't see immediately any project that is in state better than 'written, worked, abandoned'. However, I guess I could add pygost [1] since it seems to be maintained and is pure Python. But this would mean that people would have to explicitly install that package to have Streebog. But I guess it's a good step forward. [1]:http://www.cypherpunks.ru/pygost/
Now STREEBOG256 and STREEBOG512 hashes are supported by portage-9999. You'll need to have pygost or pygcrypt installed for that to work (neither is packaged at the moment but if you'd like to test early, you can use virtualenv + pip).
Fixed in portage-2.3.5.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=992cf6e5ecbc8de428792fe27bb821d04e03097c commit 992cf6e5ecbc8de428792fe27bb821d04e03097c Author: Sam James <sam@gentoo.org> AuthorDate: 2023-03-21 02:29:34 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-03-21 02:30:24 +0000 NEWS: update for checksum cleanups Bug: https://bugs.gentoo.org/597736 Bug: https://bugs.gentoo.org/615620 Bug: https://bugs.gentoo.org/885909 Bug: https://bugs.gentoo.org/888884 Signed-off-by: Sam James <sam@gentoo.org> NEWS | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) https://gitweb.gentoo.org/proj/portage.git/commit/?id=377a31434ae51b6e6465ba48b5132eb200a8cf40 commit 377a31434ae51b6e6465ba48b5132eb200a8cf40 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-03-20 03:16:37 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-03-21 02:30:23 +0000 checksum: drop STREEBOG{256,512} & pygost support For STREEBOG{256,512}, we had three options that we "supported": 1. using pygost; pygost is unpackaged in Gentoo and appears to, as of March 2023, been yanked from pypi too. Hence not only can we test it on the distribution where we do our development (Gentoo), but we also can't acquire it for CI easily either. 2. using pygcrypt; No longer in Gentoo and the codepath for this has been disabled since 2017(!) because of https://bugs.gentoo.org/615620. 3. a slow fallback implementation. This is not something we can rely on anyway, but this is especially wrong given the issues we've had recently with WHIRLPOOL. See https://bugs.gentoo.org/885909. As for whether we should support STREEBOG at all: - Per above, we don't have a decent implementation for it available. - We're not testing it very well. - Jugging obscure hash algorithms has become a pain because some of them have ended up being marked "legacy" or removed from OpenSSL by default. - I don't think we should have hash algorithms supported just for the sake of it. We're not in the business of supporting every single hash algorithm that a library with Python bindings out there provides. Bug: https://bugs.gentoo.org/597736 Bug: https://bugs.gentoo.org/615620 Bug: https://bugs.gentoo.org/885909 Bug: https://bugs.gentoo.org/888884 Signed-off-by: Sam James <sam@gentoo.org> lib/portage/checksum.py | 25 +------------------------ lib/portage/tests/util/test_checksum.py | 26 -------------------------- tox.ini | 1 - 3 files changed, 1 insertion(+), 51 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=25322edf49dada21af47356c7136e2d36e93c051 commit 25322edf49dada21af47356c7136e2d36e93c051 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-03-21 02:32:35 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-03-21 02:32:35 +0000 NEWS: add note re motivation for STREEBOG cleanup (pygost being yanked) Bug: https://bugs.gentoo.org/597736 Signed-off-by: Sam James <sam@gentoo.org> NEWS | 4 ++++ 1 file changed, 4 insertions(+)
Correction: there was no fallback impl, just pygost + pygcrypt.
