Hi Ulrich, On 4/6/22, Ulrich Mueller <u...@gentoo.org> wrote: >>>>>> On Wed, 06 Apr 2022, Jason A Donenfeld wrote: > >> I think actually the argument I'm making this time might be subtly >> different from the motions that folks went through last year. >> Specifically, the idea last year was to switch to using BLAKE2b only. >> I think what the arguments I'm making now point to is switching to >> SHA2-512 only. > > Still, I think that if we drop one of the hashes then we should proceed > with the original plan. That is, keep the more modern BLAKE2B (which was > a participant of the SHA-3 competition [1]) and drop the older SHA512.
Why? Then we're dependent on two things, either of which could break, rather than one. To be clear, I'm a big fan of BLAKE2 myself and have used it in a number of projects. And either one breaking would be a big deal. So maybe it doesn't really matter that much. But strictly formally, it seems like SHA512 is the most sound decision? I spelled out two reasons for that to Sam; if you still disagree, maybe you can address why you think my two reasons aren't very meaningful? > I also think that the argument about the OpenPGP signature isn't very > strong, because replacing that signature by another one using a > different hash is trivial. As I said before, replacing all Manifest > files in the tree isn't. I looked into changing gnupg to use BLAKE2b for signatures, but it doesn't appear to be supported. It's in gcrypt but not gpg. From --version: `Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224`. Since my argument rests on minimizing probability of a break, changing the signature hash algo after it's broken doesn't help with much, so I think this is something we'd want to happen now, rather than later, if we're to use BLAKE2b exclusively. I could potentially send a patch to gnupg for this if you want to take the long path. But also: don't forget there's also the interoperability argument that favors SHA512 too. Jason
