Add hazmat module with ExpandedSecretKey, raw_sign, raw_sign_prehashed

[rozbb]

This splits out the signing functionality we have into two new functions. Nothing changes underlyingly. The only difference is now users can use raw_sign() and raw_sign_prehashed() if you enable the raw_sign feature (and digest feature as well for the latter).

Also this renames ExpandedSecretKey::nonce to hash_prefix, because that's what it is, and it is absolutely used more than once.

Fixes #298.

Why expose these functions

Our removal of the public ExpandedSecretKey API in #205 made it impossible for users to sign using an ExpandedSecretKey. The only way to sign now is SigningKey::sign. The issue here is that some downstream users, as noted in #298, never actually saved their SigningKey, and only saved the ExpandedSecretKey. You cannot recover a SigningKey from an ExpandedSecretKey, since the former is the seed whose hash is expanded to the latter. Thus, it is necessary to expose some lower-level way of computing signatures. There were a few levels of abstraction we could have picked here, and I'm open to suggestions.

Separately, and I don't know how important this is, but these functions would allow someone to build BIP32-Ed25519 on top of this library, since scalar and hash_prefix are explicit inputs to the raw_sign() function.

[tarcieri]

My preference would be to stick the pub functions in a hazmat module with a big fat warning, similar to this:

https://docs.rs/ecdsa/latest/ecdsa/hazmat/index.html

[rozbb]

That looks good. Will do

[tarcieri]

@rozbb if you do extract a hazmat module it'd be good to link to https://github.com/MystenLabs/ed25519-unsafe-libs and document how things could go wrong if the public key isn't computed from the secret key

[benma]

but these functions would allow someone to build BIP32-Ed25519 on top of this library

Fyi, I made such a library (you can find it here), and I would appreciate if this PR made it into 2.0, as I previously relied on ExpandedSecretKey::from_bytes to use the BIP32 expanded private key to sign a message here.

[jplatte]

@rozbb gentle ping, are you expecting to finish this soon?

Alternatively, could we maybe get a patch release on x25519-dalek with the zeroize dependency unpinned? It seems like it causes a new problem once every week 😢

[rozbb]

@jplatte I apologize, I've been swamped at work lately. I will definitely get to this this week. The existing PR is pretty close to the finish line so it shouldn't take long.

[rozbb]

Ok, I think all concerns should be addressed, pending 1 unresolved conversation.

To address #298, I brought back ExpandedSecretKey. One notable change is that it uses Scalar::from_bytes_modulo_order() for deserialization rather than the Scalar::from_bits() function. Strictly speaking, this is a meaningful change. But the only way you'd notice the difference is if you were somehow serializing unreduced expanded secret key scalars. I really doubt that'll be an issue.

[poljar]

From my point of view this is all we need and looks great. Thanks a lot for bringing back ExpandedSecretKey as well.

[rozbb]

Alright, @tarcieri ready to review. Sorry for the huge edits. This weirdly affected a lot of things.

[tarcieri]

One nit on from_bytes accepting a slice but otherwise this looks good to me.

[tarcieri]

Looks good now, although for bonus points an ExpandedSecretKey::from_slice method and/or TryFrom<&[u8]> impl would be nice.

[rozbb]

Good idea, thanks!

[jplatte]

Any plans for the next (pre-)release? :)

[benma]

Any plans for the next (pre-)release? :)

Seconded :)

[tarcieri]

It's blocked on dalek-cryptography/curve25519-dalek#531

[tarcieri]

It's out