Re: Ed25519 Signature 2018

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

Received on Monday, 7 May 2018 17:54:25 UTC