Re: Ed25519 Signature 2018

So let me state that I'm still in favor of using SHA2. Keccak is an awesome
algorithm for SHA3 but NIST hardened it too much that it is slower than
SHA2. The reasons many are staying away from SHA3 are speed and security.
SHA2 is still considered secure so there hasn't been a need for a
replacement yet. Many crypto people like BLAKE2b because it has similar
characteristics to SHA2 but has been shown to be faster without sacrificing
security. The same could be done with Keccak given the right settings. So
for now I would vote to just use the Ed25519Signature2018 with SHA2. If
SHA2 is broken in the future, a newer version could be made. I don't agree
that we've done something wrong if the version changes in the same year.
You could everything correctly but a security issue arrises that makes the
current spec weak or broken in the same year you write it. Hopefully that
doesn't happen but could.

For future reference what versioning should be used then if such a change
is needed.

Do you know of an IETF RFC that spec's Ed25519
signatures using FIPS 202?
Not right now.

On Mon, May 7, 2018 at 11:57 AM, Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On 05/07/2018 01:53 PM, Vaneev Bogdan wrote:
> > Where can I find a sources for this spec? It seems this repo
> > contains rendered page.
>
> Every spec should have a Github link at the top under "Source control".
> Here's the one for the spec you were looking at:
>
> https://github.com/w3c-dvcg/lds-ed25519-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
>



-- 
Mike Lodder
Senior Crypto Engineer