mimblewimble team mailing list archive

[Ignotus Peverell <igno.peverell@xxxxxxxxxxxxxx>]

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: oleganza@xxxxxxxxx
> To: Ignotus Peverell <igno.peverell@xxxxxxxxxxxxxx>
> mimblewimble@xxxxxxxxxxxxxxxxxxx <mimblewimble@xxxxxxxxxxxxxxxxxxx>
> 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.peverell@xxxxxxxxxxxxxx> 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: oleganza@xxxxxxxxx
>>> To: Ignotus Peverell <igno.peverell@xxxxxxxxxxxxxx>
>>> mimblewimble@xxxxxxxxxxxxxxxxxxx <mimblewimble@xxxxxxxxxxxxxxxxxxx>
>>> 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.peverell@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~mimblewimble
>>>> More help : https://help.launchpad.net/ListHelp