| 1 |
On Tue, Oct 24, 2017 at 4:21 AM, Paweł Hajdan, Jr. |
| 2 |
<phajdan.jr@g.o> wrote: |
| 3 |
> On 24/10/2017 06:11, Michał Górny wrote: |
| 4 |
>> W dniu wto, 24.10.2017 o godzinie 06∶04 +0200, użytkownik Michał Górny |
| 5 |
>> napisał: |
| 6 |
>>> Three hashes don't give any noticeable advantage. If we want a diverse |
| 7 |
>>> construct, we take SHA3. SHA3 is slower than SHA2 + BLAKE2 combined, so |
| 8 |
>>> even with 3 threaded computation it's going to be slower. |
| 9 |
>> |
| 10 |
>> Oh, and most notably, the speed loss will be mostly visible to users. |
| 11 |
>> An attacker would have to compute the additional hashes only |
| 12 |
>> if the fastest hash already matched, i.e. rarely. Users will have to |
| 13 |
>> compute them all the time. |
| 14 |
> |
| 15 |
> I'm surprised to see bikeshedding about this, where the performance |
| 16 |
> argument was shown to be speculative. |
| 17 |
> |
| 18 |
> Consider clarifying what's the goal of this thread. |
| 19 |
> |
| 20 |
> It seemed like a relatively obvious cleanup / modernizing the set of |
| 21 |
> hash functions, and I'd still be supportive of that. |
| 22 |
> |
| 23 |
|
| 24 |
++ |
| 25 |
|
| 26 |
IMO nothing really new has come up for the most part. People disagree |
| 27 |
on a few points, as is inevitable. The purpose of mailing lists isn't |
| 28 |
to keep reiterating the same points until there is unanimous |
| 29 |
agreement. Best to just move on. |
| 30 |
|
| 31 |
-- |
| 32 |
Rich |
Archives