Add TryFrom from &[u8] and Vec<u8> to PrivateKeyDer

[cpu]

This branch is an alternative to #39 that takes the base commit and reworks it slightly to:

• Introduce constants for the various bits of ASN.1 DER we're using, closely matching defines found in the webpki crate's DER module.
• Simplify some of the bounds checking and indexing.
• Correct the boundary for the short form length check. (I think we've reasoned out this was a no-op change)
• Document the heuristics in use, and why they work, citing RFCs for the ASN.1 structures we're matching.

Along the way I also:

• Used cargo fuzz to initialize a fuzzing crate, and a target for fuzzing this new API surface.
• Added a fuzzing smoke-test target to CI for the above
• Simplified the included unit test to use a table-driven design

I thought that it would be easier to open this PR rather than deliver a large volume of review feedback. Many thanks to @Alvenix for the original implementation.

[cpu]

cpu marked this pull request as draft now

I'm using something that requires std. Need to adjust 😮‍💨

[Alvenix]

Your pull request seems much better than mine, but I am not an expert on the subject. Why couldn't the tests be moved with the other tests if they need std?

[cpu]

Why couldn't the tests be moved with the other tests if they need std?

I think the issue isn't in the tests, it's the way I'm trying to build a pattern to match for the pkcs8_hint by combining two &[u8] at runtime with concat, creating a Vec.

There isn't a nice way to make a compile-time const that combines two const slice fragments without defining a macro (as far as I can tell). I'll have to rework the approach slightly.

[cpu]

There isn't a nice way to make a compile-time const that combines two const slice fragments without defining a macro (as far as I can tell). I'll have to rework the approach slightly.

I gave up on pulling out the VERSION_ONE and VERSION_TWO slices and inlined their values into the three hints. It's a little less nice but I think making a macro would be overkill.

[cpu]

Used cargo fuzz to initialize a fuzzing crate, and a target for fuzzing this new API surface.

FWIW I ran the fuzzer "a while" (~30m) on this branch, and the original commit from #39 without any findings.

[djc]

This looks great!

In terms of commit history, I would prefer not to keep @Alvenix' original commit separate from the other commits that change the code/tests, and instead squash them together (and use Co-authored-by or whatever the tag is to clarify origination) -- keeping the fuzzing commit separate is fine, of course.

[cpu]

In terms of commit history, I would prefer not to keep @Alvenix' original commit separate from the other commits that change the code/tests, and instead squash them together (and use Co-authored-by or whatever the tag is to clarify origination)

That sounds good to me. I've pushed an update that folds the revisions and the test updates into the original commit, maintaining the authorship from #39. I left the fuzzing commits separate.

[djc]

💯