[crypto] Ed25519 security

[huitseeker]

Feedback from writing MystenLabs/narwhal#32 on our ed25519 implementation:

• the "master" record of our keys is now a ed25519_dalek type, which is zeroized properly on drop => can we ensure this sort of thing is kept as a convention for future impls? perhaps with a unit test?
• we do not perform any verifications on deserialization of a key, including:
  • canonical scalar representation for PrivKey,
  • small order element for Public keys and keypairs.
• we should probably add warnings about small order components in keys, as they will disagree with single-signature verification.

Inspirations for accomplishing the above:

• https://github.com/diem/diem/blob/main/crates/diem-crypto/src/ed25519.rs
• https://eprint.iacr.org/2020/1244.pdf
• https://github.com/novifinancial/ed25519-speccheck (contains test vectors!)

[kchalkias]

@huitseeker as we're now with zip215, do you think we could close this issue?

[huitseeker]

I think the best approach is for us to encode our expectations against the vectors included in : https://github.com/novifinancial/ed25519-speccheck And I would convert this issue into running asserts against each of those vectors.