| 1 |
On Thu, Oct 19, 2017 at 6:49 PM, Gordon Pettey <petteyg359@×××××.com> wrote: |
| 2 |
|
| 3 |
> On Thu, Oct 19, 2017 at 5:32 PM, Hanno Böck <hanno@g.o> wrote: |
| 4 |
> |
| 5 |
>> On Thu, 19 Oct 2017 21:08:40 +0200 |
| 6 |
>> Michał Górny <mgorny@g.o> wrote: |
| 7 |
>> |
| 8 |
>> > manifest-hashes = SHA512 SHA3_512 |
| 9 |
>> |
| 10 |
>> Counterproposal: Just use SHA512. |
| 11 |
>> |
| 12 |
>> There isn't any evidence that any SHA2-based hash algorithm is going to |
| 13 |
>> be broken any time soon. If that changes there will very likely be |
| 14 |
>> decades of warning before a break becomes practical. |
| 15 |
>> |
| 16 |
>> Having just one hash is simpler and using a well supported one like |
| 17 |
>> SHA512 may make things easier than using something that's still not |
| 18 |
>> very widely supported. |
| 19 |
> |
| 20 |
> |
| 21 |
> Yet having more than one lets you match make sure nobody hijacked your |
| 22 |
> manifest file when an attack vector is inevitably discovered for the old |
| 23 |
> new algorithm (whether SHA2, SHA3, or BLAKE2), because you'll be able to |
| 24 |
> confirm the file is the same one that matched the old checksum in addition |
| 25 |
> to the new one. |
| 26 |
> |
| 27 |
|
| 28 |
Would it make sense then to support several hashes but let the user |
| 29 |
optionally turn off the verification of some of them, depending on the |
| 30 |
user's security vs performance requirements? |
| 31 |
|
| 32 |
-- |
| 33 |
Anton |
Archives