Bump RustCrypto dependency crates to Release Candidate version

[nabetti1720]

This PR updates the crate to the Release Candidate version currently in development by the RustCrypto project.

• Since ed25519_dalek::SigningKey::from_sec1_der() no longer exists, We replaced it with my own implementation. It may be better to simply not support it. It now returns a message that it is not supported.
• rand_core::OsRng has been moved to the rand crate. We felt that there should be no new dependency on the rand crate, and instead have a small implementation with CryptoRng + RngCore trait functionality for compatibility.
• We have also fixed the incompatibilities that occurred in cargo fix/clippy/fmt.
• We have excluded Cargo.lock, which is included in assets other than those required for validation by core components and CI, as it increases maintenance burden.

If this has already been planned by an official expert, you may close this PR.
I hope this PR will be helpful to you. :)

[tarcieri]

@stevefan1999-personal can you take a look at this? I know it duplicates some of the work you were trying to do in #87, but I do like that this is just a self-contained dependency upgrade PR

[stevefan1999-personal]

@tarcieri I'm out on a trip rn and I will be back on 2nd Jan, but I will try to take a look

[stevefan1999-personal]

Okay I'm back from Japan now, seems like I can start working on it too

[nabetti1720]

@tarcieri @stevefan1999-personal gentle ping :)

Also check out this suggestion. #103 (comment)
If you need anything else regarding this PR, please let me know.

[tarcieri]

I will say as a general comment I prefer this PR over #103 simply by virtue of being smaller and more reviewable

[nabetti1720]

@tarcieri @stevefan1999-personal
Both of you seem to be sending positive signals, so if there are no problems, please merge.
I would like to work on the next improvements. :)

[tarcieri]

I can do a more detailed review soon

[nabetti1720]

I can do a more detailed review soon

Please do so when you have time. :)

There are some points that concern me about the content addressed in this PR.

When updating dependencies, I noticed that ed25519_dalek::SigningKey::from_sec1_der() is no longer supported. I'm sure there's a clear reason for this, such as security concerns.

However, the release currently includes code to simulate this.

I believe that cryptography implementation should be left to the RustCrypto crates, which are implemented by experts, and that rustls-rustcrypto should be a thin wrapper that makes the RustCrypto crates available to rustls.

If this proves to be the case, I'd be happy to remove the separate implementation for sec1 and change it to return an error indicating that it's unsupported.

[tarcieri]

Ed25519 defines its own point encoding which is not specified in SEC1 (it's a 255-bit compressed Edwards-y coordinate, along with 1-bit representing the sign/oddness, for a total of 256-bits/32-bytes).

The original Ed25519 paper wasn't even published until 2 years after the latest published revision to SEC1 (V2 in 2009, vs 2011 for the Ed25519 paper).

I'm not sure where you got ed25519_dalek::SigningKey::from_sec1_der from but it has never been supported specifically because there is no defined SEC1 encoding for Ed25519 curve points. SEC1 adds a needless tag byte, where all Ed25519 points are compressed by default so there's no need for a tag byte.

[nabetti1720]

I'm not sure where you got ed25519_dalek::SigningKey::from_sec1_der

This was certainly the case before this PR and this statement was valid.

rustls-rustcrypto/src/sign/eddsa.rs

Line 27 in 992778d

ed25519_dalek::SigningKey::from_sec1_der(sec1.secret_sec1_der())

This PR would be even simpler if no replacement implementation was needed.

[tarcieri]

That must've been going through the legacy blanket impl in the old version of the sec1 crate:

https://docs.rs/sec1/latest/sec1/trait.DecodeEcPrivateKey.html#implementors

It's completely wrong though and has been redesigned/removed in the latest prereleases.

Can you post an example of the ASN.1 DER you're trying to decode?

[nabetti1720]

It's completely wrong though and has been redesigned/removed in the latest prereleases.
Can you post an example of the ASN.1 DER you're trying to decode?

I don't have a specific use case. I added a compatibility implementation based on what was supported up until now, but it turned out to be wrong.

[tarcieri]

I'm guessing whatever it was, it likely doesn't work, but if you can somehow write a test case and print out the associated ASN.1 DER, I can help figure out how it should actually be implemented

[nabetti1720]

I'm guessing whatever it was, it likely doesn't work, but if you can somehow write a test case and print out the associated ASN.1 DER, I can help figure out how it should actually be implemented

Thank you. However, as I commented earlier, I don't have a specific use case at the moment, so I think it's something we can think about when we need it.

[nabetti1720]

@tarcieri Please let me know if there are any other areas that need to be reviewed.