[cryptography] Signature Scheme Validity Consistency

[technovision99]

Unlike the other signature variants, the ed25519-consensus crate, which is the library used to implement ed25519 signatures, only verifies the length of the byte array during deserialization time: https://github.com/penumbra-zone/ed25519-consensus/blob/78f83b21767077f602f30148e513a52e844abbb6/src/signature.rs#L22-L31
This is not an exploitable issue because the signature's validity will be checked during signature verification time: https://github.com/penumbra-zone/ed25519-consensus/blob/78f83b21767077f602f30148e513a52e844abbb6/src/verification_key.rs#L239-L244
However, checking the signature during deserialization may be more robust against invalid curve points if developers choose to perform any operations on signatures. In addition, it would be more consistent with the other signature implementations, as these all check validity during deserialization time.

[technovision99]

The private key should be a scalar chosen from the range [1,n-1] , however the library allows it to be in the range [1,2^256-1] as far as I can tell. This is likely not an issue but we wanted to call it to your attention: https://github.com/RustCrypto/traits/blob/81757de8a15d5ae628a15cbaad6e33b12cdb7893/elliptic-curve/src/secret_key.rs#L177-L197
In addition, there are no checks that the signature elements are in the range [1,n-1] as well. The s value is later rejected if it lies in the upper half of the curve but the r value is never checked (besides being nonzero): read_cfg will end up calling from_slice which calls from_scalars here. However from_scalars calls ScalarPrimitive::from_slice which does not check the curve order in the following function.