Good question. It's hard to know without a complete implementation :-) So I may
very well be micro-optimizing.
That being said, hashing is pervasive and used over a wide variety of data
types and structures and so we might as well anticipate. This surfaced first as
I was profiling our sum-tree implementation and SHA3 is completely dominating
performance, in a bad way. I'd rather not being already limited by SHA3 in how
fast we can add outputs to the sum tree.
- Igno
> -------- Original Message --------
> Subject: Re: [Mimblewimble] Switch to Blake2
> Local Time: July 21, 2017 6:47 PM
> UTC Time: July 21, 2017 6:47 PM
> From: olega...@gmail.com
> To: Ignotus Peverell <igno.pever...@protonmail.com>
> mimblewimble@lists.launchpad.net <mimblewimble@lists.launchpad.net>
> I'm curious what % of the validation time is spent on hashing vs scalar
> multiplication (you probably have a hundred of those in rangeproofs per
> output)?
>
> On 21 Jul 2017, at 21:40, Ignotus Peverell <igno.pever...@protonmail.com>
> wrote:
>
>> I have considered SHAKE128/256 and been hesitating with Blake2 for a bit. My
>> preference is going for Blake2 mostly for the following reasons:
>>
>> - If we're going to switch to a faster hash function, we might as well go
>> all the way. Blake2 is still over twice as fast as SHAKE128.
>> - In Rust libraries, SHAKE doesn't seem as well supported as Blake2. Our
>> current SHA3 lib, tiny-keccak, doesn't even tests SHAKE and only supports
>> SHAKE128 with 128 bits outputs. We could improve that, but can't really
>> justify the extra effort.
>> - I can email Zooko if I have questions :-)
>>
>> - Igno
>>
>>> -------- Original Message --------
>>> Subject: Re: [Mimblewimble] Switch to Blake2
>>> Local Time: July 21, 2017 6:27 PM
>>> UTC Time: July 21, 2017 6:27 PM
>>> From: olega...@gmail.com
>>> To: Ignotus Peverell <igno.pever...@protonmail.com>
>>> mimblewimble@lists.launchpad.net <mimblewimble@lists.launchpad.net>
>>> My apologies for bike shedding, but have you considered SHAKE128? It uses
>>> the same Keccak function but with saner (faster) parameters and you use the
>>> extensible output for simpler generation of several blinding factors,
>>> forged elements etc.
>>>
>>> On 21 Jul 2017, at 21:12, Ignotus Peverell <igno.pever...@protonmail.com>
>>> wrote:
>>>
>>>> Hi all,
>>>> I originally picked SHA3 (Keccak) for all hashing in grin [1]. The
>>>> advantages of SHA3 over SHA256 are numerous (more modern design, less
>>>> known weaknesses, designed independently from NSA, well studied and long
>>>> review process, etc.) which motivated my original decision. However it
>>>> turns out that in practice, SHA3 is on the slower side [2] due to last
>>>> minute decisions from NIST to increase the security parameters.
>>>> We will need a fair amount of hashing operations in grin, as our
>>>> "transactions" are broken down into inputs, outputs (in which range proofs
>>>> can be considered separately) and kernels which may all be hashed
>>>> independently. We also maintain at least one sum tree of the UTXO set.
>>>> Hashing performance is important to our normal operation.
>>>> So I'm considering a switch to the Blake2 [3] hash function. It's
>>>> extremely fast in software (faster than SHA256 and even MD5), has been
>>>> shown to be as secure as SHA3, was designed independently and has been
>>>> widely reviewed.
>>>> Any strong opposition or concerns?
>>>> - Igno
>>>> [1]
>>>> https://github.com/ignopeverell/grin/blob/master/core/src/core/hash.rs#L153
>>>> [2] https://www.imperialviolet.org/2017/05/31/skipsha3.html
>>>> [3] https://blake2.net
>>>
>>>> --
>>>> Mailing list: https://launchpad.net/~mimblewimble
>>>> Post to : mimblewimble@lists.launchpad.net
>>>> Unsubscribe : https://launchpad.net/~mimblewimble
>>>> More help : https://help.launchpad.net/ListHelp
--
Mailing list: https://launchpad.net/~mimblewimble
Post to : mimblewimble@lists.launchpad.net
Unsubscribe : https://launchpad.net/~mimblewimble
More help : https://help.launchpad.net/ListHelp
