Re: [gentoo-dev] [RFC] Removing SHA512 hash from Manifests
On 2021-07-25 08:27, Michał Górny wrote: On Sun, 2021-07-25 at 01:12 +0200, Thomas Deutschmann wrote: I don't understand. Isn't it the same motion we put down just 2 months ago [1]? Or is this something new? If this isn't something new, what has changed since May [2]? Apparently it has not been 'put down' because it came back via open bugs. Open bugs? Could you please link them here? To remember: Currently we have two different hashes for every distfile. If we are going to throw this data away, we should really have good reasons to do that. Like said during that council meeting, BLAKE2B and SHA512 are competing hashes. What's wrong with having a backup plan even for a very unlikely scenario, that BLAKE2B will get broken? Define 'broken'. To quote from chapter 9 of the Handbook of Applied Cryptography, by Menezes, van Oorschot and Vanstone: If, for a given hash function, an attack is found, which, by exploiting special details of how the hash function operates, finds a preimage, a second preimage or a collision faster than the corresponding generic attack, then the hash function is said to be "broken". This happened publicly for SHA1 in 2017. Remember that verify-sig.eclass I criticized last year? Of course some scenarios I outlined were very unlikely and I never expected that I can run around in near future saying "I told you". But in January 2021, CVE-2021-3345 happened in libgcrypt... I don't see how this is relevant either. Are you admitting that you're criticizing all my ideas because I just happen to propose them? No, I am not criticizing ideas because *you* proposed them. I share my criticism when I have some concerns or believe the proposal has some flaws. You maybe have that impression because you are very active and most proposals are coming from you. In the end, we both are hopefully sharing the same goal to make Gentoo better... -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Removing SHA512 hash from Manifests
On Sun, Jul 25, 2021 at 11:23 AM Ulrich Mueller wrote: > > We can reiterate when there are indications that SHA512 would be broken. > (Then again, the same applies to BLAKE2B.) Unless both are broken at the same time you'd also have the advantage of not having to try to scramble to figure out whether anything was compromised. I get that typically hash functions are first broken in a way that makes them very difficult to exploit, but that isn't some sort of guarantee. In the very unlikely event that somebody comes up with a preimage attack against one of the functions, it would be even more unlikely that an attack would be devised against both. Sure, we're talking about low risks here, but we're also talking about low cost and security. When security is this cheap, why not have it? I mean, if people didn't care about this stuff they wouldn't bother migrating off of md5, and you'd have critical software like source code control using broken hashes like sha1. -- Rich
Re: [gentoo-dev] [RFC] Removing SHA512 hash from Manifests
> On Sun, 25 Jul 2021, Roy Bamford wrote: > I'm in the "if it's not broken don't fix it" school. +1 I don't see a strong argument to remove SHA512, so leave things as they are for now. We can reiterate when there are indications that SHA512 would be broken. (Then again, the same applies to BLAKE2B.) Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Removing SHA512 hash from Manifests
On 24/07/21 17:16, Michał Górny wrote: > Hi, everyone. > > I've been asked to repost the idea of removing SHA512 hash from > Manifests, effectively limiting them to BLAKE2B. > > The 'old' set of Gentoo hashes including SHA512 went live in July 2012. > In November 2017, we have decided to remove the two other hashes and add > BLAKE2B in their stead. Today, all Gentoo packages are using BLAKE2B > and SHA512 hashes. > > To all extent, this is purely a cosmetic change. The benefit from > removing the additional hash is negligible, both from space perspective > and hashing speed perspective. The benefit from keeping two hashes is > also negligible. > > Back during the 2017 discussion, Infra came to the conclusion that we're > going to keep SHA512 for a transition period, then remove it, and stay > with a single hash algorithm. In my opinion, we have kept it long > enough. > > WDYT? > I'd remove it once we have a second hash to add and/or BLAKE2B is widespread enough on upstream. lu
Re: [gentoo-dev] [RFC] Removing SHA512 hash from Manifests
Am Samstag, 24. Juli 2021, 17:16:23 CEST schrieb Michał Górny: > Hi, everyone. > > I've been asked to repost the idea of removing SHA512 hash from > Manifests, effectively limiting them to BLAKE2B. Just keep things as they are for now. Even reading this bike^H^H^H^Hthread is more effort than the potential gain. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice)
Re: [gentoo-dev] [RFC] Removing SHA512 hash from Manifests
On 2021.07.25 00:12, Thomas Deutschmann wrote: > Hi, > > I don't understand. Isn't it the same motion we put down just 2 months > > ago [1]? Or is this something new? > > If this isn't something new, what has changed since May [2]? > > To remember: Currently we have two different hashes for every > distfile. > If we are going to throw this data away, we should really have good > reasons to do that. Like said during that council meeting, BLAKE2B and > > SHA512 are competing hashes. What's wrong with having a backup plan > even > for a very unlikely scenario, that BLAKE2B will get broken? > > It's not like SHA512 is requiring any additional deps which are > unmaintained or something like that. SHA has even hardware > acceleration > support in modern systems. > > In addition it is even more likely that you will find SHA checksum > files > with upstream release tarballs than BLAKE2B files. > > Remember that verify-sig.eclass I criticized last year? Of course some > > scenarios I outlined were very unlikely and I never expected that I > can > run around in near future saying "I told you". But in January 2021, > CVE-2021-3345 happened in libgcrypt... > > So again: Why should we throw the data we currently have away and put > Gentoo unnecessarily at risk that we will end up without hashes > because > the only hash algorithm we used became broken and given that we will > be > unable to re-hash every file in a timely manner (remember how long it > took to get a BLAKE2B hash for every file)? > > > > See also: > = > [1] https://bugs.gentoo.org/784710 > > [2] https://projects.gentoo.org/council/meeting-logs/20210509.txt > > > -- > Regards, > Thomas Deutschmann / Gentoo Linux Developer > fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 > > I'm in the "if it's not broken don't fix it" school. The original proposal uses the word 'negligible' twice when describing the the benefits, which makes it sound like busywork. However, it's not me doing the work, so my opinion count for very little. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgp3G7Gf0Tace.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Removing SHA512 hash from Manifests
Hi, Back during the 2017 discussion, Infra came to the conclusion that we're going to keep SHA512 for a transition period, then remove it, and stay with a single hash algorithm. In my opinion, we have kept it long enough. WDYT? As far I remember we agreed to keep two different hashes. The idea is, that if one hash is no longer safe to use, we still have a short period for migration. If we use only one hash, gentoo is vulnarable to "sudden problems". The everyday news show us, that broken implementations are possible and that this scenario is likely to happen over the years. The benefit of removing the second hash is negligible. So we should keep two different hashes. -- Best, Jonas
Re: [gentoo-dev] [RFC] Removing SHA512 hash from Manifests
On 24/07/2021 16:16, Michał Górny wrote: Hi, everyone. I've been asked to repost the idea of removing SHA512 hash from Manifests, effectively limiting them to BLAKE2B. The 'old' set of Gentoo hashes including SHA512 went live in July 2012. In November 2017, we have decided to remove the two other hashes and add BLAKE2B in their stead. Today, all Gentoo packages are using BLAKE2B and SHA512 hashes. To all extent, this is purely a cosmetic change. The benefit from removing the additional hash is negligible, both from space perspective and hashing speed perspective. The benefit from keeping two hashes is also negligible. Back during the 2017 discussion, Infra came to the conclusion that we're going to keep SHA512 for a transition period, then remove it, and stay with a single hash algorithm. In my opinion, we have kept it long enough. WDYT? I use Gentoo heavily in my work but not a developer, so only offering a user perspective. I find SHA512 hashes in Manifests, of upstream provided tarballs (i.e. DIST entries) only, very useful when manually comparing with hashes provided by upstream sources. BLAKE2B may be better than SHA512 in certain respects but adoption elsewhere by comparison is extremely low. Granted SHA512 hashes of upstream files are certainly not plentiful (and it is shocking how many project still use MD5) but at least some projects provide them. I've personally never seen any project provide a BLAKE2B hash for a sources tarball. Additionally, as stated by someone else already, there is SHA512 hardware acceleration support on many systems. This can save precious time in certain scenarios when doing manual checks on large files. If there is little benefit to removing SHA512 it seems to me that there are significant benefits to keeping it. I for one would be quite disappointed to see it go.
Re: [gentoo-dev] [RFC] Removing SHA512 hash from Manifests
On 7/24/21 5:16 PM, Michał Górny wrote: Back during the 2017 discussion, Infra came to the conclusion that we're going to keep SHA512 for a transition period, then remove it, and stay with a single hash algorithm. I'm just curious if Infra in 2021 still wants only 1 hash algo? In my opinion, we have kept it long enough. Indeed, if nothing changed Infras opinion, then it is time to kick if off. -- Toralf PGP 23217DA7 9B888F45 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Removing SHA512 hash from Manifests
On Sun, 2021-07-25 at 01:12 +0200, Thomas Deutschmann wrote: > Hi, > > I don't understand. Isn't it the same motion we put down just 2 months > ago [1]? Or is this something new? > > If this isn't something new, what has changed since May [2]? Apparently it has not been 'put down' because it came back via open bugs. > To remember: Currently we have two different hashes for every distfile. > If we are going to throw this data away, we should really have good > reasons to do that. Like said during that council meeting, BLAKE2B and > SHA512 are competing hashes. What's wrong with having a backup plan even > for a very unlikely scenario, that BLAKE2B will get broken? Define 'broken'. > It's not like SHA512 is requiring any additional deps which are > unmaintained or something like that. SHA has even hardware acceleration > support in modern systems. ...which is entirely irrelevant given that both hashes need to be calculated. (SHA512 + BLAKE2B) can be as fast as the slower of two in the best scenario. > In addition it is even more likely that you will find SHA checksum files > with upstream release tarballs than BLAKE2B files. Again, I don't see how that's even remotely relevant. > Remember that verify-sig.eclass I criticized last year? Of course some > scenarios I outlined were very unlikely and I never expected that I can > run around in near future saying "I told you". But in January 2021, > CVE-2021-3345 happened in libgcrypt... I don't see how this is relevant either. Are you admitting that you're criticizing all my ideas because I just happen to propose them? -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Removing SHA512 hash from Manifests
On Sat, 2021-07-24 at 17:15 -0400, Joshua Kinard wrote: > On 7/24/2021 11:16, Michał Górny wrote: > > Hi, everyone. > > > > I've been asked to repost the idea of removing SHA512 hash from > > Manifests, effectively limiting them to BLAKE2B. > > > > The 'old' set of Gentoo hashes including SHA512 went live in July 2012. > > In November 2017, we have decided to remove the two other hashes and add > > BLAKE2B in their stead. Today, all Gentoo packages are using BLAKE2B > > and SHA512 hashes. > > > > To all extent, this is purely a cosmetic change. The benefit from > > removing the additional hash is negligible, both from space perspective > > and hashing speed perspective. The benefit from keeping two hashes is > > also negligible. > > > > Back during the 2017 discussion, Infra came to the conclusion that we're > > going to keep SHA512 for a transition period, then remove it, and stay > > with a single hash algorithm. In my opinion, we have kept it long > > enough. > > > > WDYT? > > Are there any security benefits/consequences of keeping two/one? If no to > consequences, then I don't see a problem dropping SHA512. To the best of my knowledge, the consequences are negligible. > And are we looking at BLAKE3 hash support at all for the future? I know > that algo is fairly new (Jan 2020). A quick read indicates it merges a > number of the BLAKE2 variants together and is faster in some areas of > execution. Not at the moment. I see they've eventually made a C implementation, so maybe it's worth looking into. OTOH we may want to wait till it's part of CPython, or at least has C-based Python bindings. -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Removing SHA512 hash from Manifests
Hi, I don't understand. Isn't it the same motion we put down just 2 months ago [1]? Or is this something new? If this isn't something new, what has changed since May [2]? To remember: Currently we have two different hashes for every distfile. If we are going to throw this data away, we should really have good reasons to do that. Like said during that council meeting, BLAKE2B and SHA512 are competing hashes. What's wrong with having a backup plan even for a very unlikely scenario, that BLAKE2B will get broken? It's not like SHA512 is requiring any additional deps which are unmaintained or something like that. SHA has even hardware acceleration support in modern systems. In addition it is even more likely that you will find SHA checksum files with upstream release tarballs than BLAKE2B files. Remember that verify-sig.eclass I criticized last year? Of course some scenarios I outlined were very unlikely and I never expected that I can run around in near future saying "I told you". But in January 2021, CVE-2021-3345 happened in libgcrypt... So again: Why should we throw the data we currently have away and put Gentoo unnecessarily at risk that we will end up without hashes because the only hash algorithm we used became broken and given that we will be unable to re-hash every file in a timely manner (remember how long it took to get a BLAKE2B hash for every file)? See also: = [1] https://bugs.gentoo.org/784710 [2] https://projects.gentoo.org/council/meeting-logs/20210509.txt -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Removing SHA512 hash from Manifests
On 7/24/2021 11:16, Michał Górny wrote: > Hi, everyone. > > I've been asked to repost the idea of removing SHA512 hash from > Manifests, effectively limiting them to BLAKE2B. > > The 'old' set of Gentoo hashes including SHA512 went live in July 2012. > In November 2017, we have decided to remove the two other hashes and add > BLAKE2B in their stead. Today, all Gentoo packages are using BLAKE2B > and SHA512 hashes. > > To all extent, this is purely a cosmetic change. The benefit from > removing the additional hash is negligible, both from space perspective > and hashing speed perspective. The benefit from keeping two hashes is > also negligible. > > Back during the 2017 discussion, Infra came to the conclusion that we're > going to keep SHA512 for a transition period, then remove it, and stay > with a single hash algorithm. In my opinion, we have kept it long > enough. > > WDYT? Are there any security benefits/consequences of keeping two/one? If no to consequences, then I don't see a problem dropping SHA512. And are we looking at BLAKE3 hash support at all for the future? I know that algo is fairly new (Jan 2020). A quick read indicates it merges a number of the BLAKE2 variants together and is faster in some areas of execution. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org rsa6144/5C63F4E3F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
[gentoo-dev] [RFC] Removing SHA512 hash from Manifests
Hi, everyone. I've been asked to repost the idea of removing SHA512 hash from Manifests, effectively limiting them to BLAKE2B. The 'old' set of Gentoo hashes including SHA512 went live in July 2012. In November 2017, we have decided to remove the two other hashes and add BLAKE2B in their stead. Today, all Gentoo packages are using BLAKE2B and SHA512 hashes. To all extent, this is purely a cosmetic change. The benefit from removing the additional hash is negligible, both from space perspective and hashing speed perspective. The benefit from keeping two hashes is also negligible. Back during the 2017 discussion, Infra came to the conclusion that we're going to keep SHA512 for a transition period, then remove it, and stay with a single hash algorithm. In my opinion, we have kept it long enough. WDYT? -- Best regards, Michał Górny
