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