Add ed448

[mikelodder7]

This adds the Ed448-Goldilocks curve and signing implementation from the latest commit at Mikelodder7/Ed448-Goldilocks.

[dignifiedquire]

lets add a reference to the actual licnes file from curve25519-dalek

[dignifiedquire]

@tarcieri @mikelodder7 I am not seeing much in terms of test vectors or the likes, do you happen to know where to find some?

[dignifiedquire]

working on a pr to update to the current set of rustcrypto deps

[mikelodder7]

Co authors
@divergentdave
@conradoplg
@stackinspector
@anonion0
@kevaundray

[mikelodder7]

@tarcieri @mikelodder7 I am not seeing much in terms of test vectors or the likes, do you happen to know where to find some?

Here's the Ed448 test vectors

https://github.com/RustCrypto/elliptic-curves/pull/1121/files#diff-16bd59631ab39d33a42cd634a7603565919c4243d9d2b21b3d975d194457f22bR351

[dignifiedquire]

created mikelodder7#1

[mikelodder7]

created mikelodder7#1

👀

[dkg]

what's the status on this? It would be great to see ed448 under the RustCrypto umbrella.

[tarcieri]

@dkg waiting on @mikelodder7 to rebase and get the tests passing

[stackinspector]

There's a little stuff about my previous contribution that I feel the need to renegotiate before the code gets into a serious place like RustCrypto.
The hex_to_field (example) in test cases, which I originally implemented with macro_rules, passes string literial as a macro argument to hex-literial::hex!. But the maintainer of the original repository preferred hex_to_field as a function. But the problem is that hex-literial::hex! can only accept string literials, and the function hex-literial::decode, which can accept &'static str directly, is an internal API, even though we can do the checks that should be done, the API is theoretically unstable! Some of the other drawbacks I explained in the comment at the time. At final the function version was merged, but I still prefer to switch back to the macro_rules implementation and pass literals.

[tarcieri]

If we keep the name as ed448-goldilocks, it will allow the ed448 name to be used for the signature abstraction crate, which would be consistent with the ed25519 crate

(and that also ensures existing users get updates automatically without having to change to a new name)

[tarcieri]

Another option for a name is curve448. We could extract the EdDSA implementation/instantiation into ed448 at that point, which would follow how curve25519-dalek/ed25519-dalek are structured.