Re: Ed25519 Signature 2018

> Vaneev, do you really want to use SHA-3 given the above? If so, you can
> still proceed, but given that Iroha also supports SHA-2, and that there
> are people that doubt SHA-3's advantages over SHA-2, why don't you just
> use the SHA-2 version and not create a split in the signature suite?

Yes, I will use ED25519+SHA3 anyway.

I am thinking about Ed25519SHA3Signature2018 name for the cipher suite.



> On May 7, 2018, at 20:53, Manu Sporny <msporny@digitalbazaar.com> wrote:
> 
> On 05/06/2018 02:10 PM, Vaneev Bogdan wrote:
>> I want to use Ed25519 implementation with SHA3-512, because it is
>> used in https://github.com/hyperledger/iroha and I don’t really know
>> how to modify Ed25519Signature2018
> 
> Hmm, so we dug a bit deeper and found that Iroha lets you choose between
> sha2 and sha3 (it says so at the very top of the implementation repo):
> 
> https://github.com/hyperledger/iroha-ed25519
> 
> On 05/07/2018 01:22 PM, Mike Lodder wrote:
>> I would update the name on the suite to be Ed25519Signature2018-2.
> 
> -1, there should be semantic meaning in anything added to the name...
> so, we've tried very hard to avoid things like "-2" suffixes, which may
> confuse developers regarding the differences between
> "Ed25519Signature2018" and "Ed25519Signature2018-2".
> 
> Looking at this:
> 
> https://tools.ietf.org/html/rfc8032
> 
> They use SHA-512 as defined in RFC6234:
> 
> https://tools.ietf.org/html/rfc6234
> 
> ... which references FIPS 180, which describes SHA2.
> 
> https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf
> 
> What is currently spec'd at IETF via RFC 8032 is SHA2. As far as we can
> tell, SHA3 is not spec'd. That's one of the reasons we use SHA2 for
> Ed25519Signature2018. Do you know of an IETF RFC that spec's Ed25519
> signatures using FIPS 202?
> 
>> Many would see the move to SHA3 as an improved version from a
>> security point of view.
> 
> That view is challenged by folks in the IETF CFRG:
> 
> https://www.imperialviolet.org/2017/05/31/skipsha3.html
> 
> Namely:
> 
> "there is a natural tendency to assume that SHA-3 must be better than
> SHA-2 because the number is bigger."
> 
> "SHA-3 is also slow, and is even slower than SHA-2 which is already a
> comparative laggard amongst crypto primitives."
> 
> "even the Keccak team appear to be pushing K12 rather than SHA-3 now."
> 
> "So there are some interesting prospects for a future, faster
> replacement for SHA-2. But SHA-3 itself isn't one of them."
> 
>> Daniel Bernstein’s original paper says the EdDSA uses SHA2-512 by
>> default but would move to SHA3 once standardized. The paper was
>> written over a decade ago.
> 
> Yes, and in that time, there have been concerns raised about SHA-3 being
> the replacement for SHA-2.
> 
>> I’m not sure how we denote version changes in the same year.
> 
> Versions typically shouldn't change in the same year. If they do, it's a
> sign that we've screwed up.
> 
> Vaneev, do you really want to use SHA-3 given the above? If so, you can
> still proceed, but given that Iroha also supports SHA-2, and that there
> are people that doubt SHA-3's advantages over SHA-2, why don't you just
> use the SHA-2 version and not create a split in the signature suite?
> 
> The signature suites are meant to capture best practices for that
> calendar year and it seems like SHA-2 is the best practice for 2018.
> 
> -- manu
> 
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Veres One Decentralized Identifier Blockchain Launches
> https://tinyurl.com/veres-one-launches