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
