Check length when importing raw X25519 and Ed25519 keys

[hopafoot]

Closes #409

Section 5 of RFC7748 specifies that X25519 private and public keys are 32 bytes/256 bits. The spec, however, does not explicitly reject raw keys of different lengths.
This behaviour is already being tested for by WPT and common implementations already throw a DataError in such cases.

---

Preview | Diff

[panva]

Should ed25519 get the same treatment?

[hopafoot]

Should ed25519 get the same treatment?

@panva, According to RFC8032, I think so. WPT tests also currently expect them to be rejected and common implementations seem to pass these tests. Would you prefer I add these changes here, or keep them separate?

[panva]

might as well be done in this very PR

[hopafoot]

might as well be done in this very PR

done.

[davidben]

The "length in bits" thing threw me off at first, but I see it's just byte length * 8 and not something cursed like "check that the high bit is set". :-)

[w3cbot]

plehegar marked as non substantive for IPR from ash-nazg.

[twiss]

Thanks for the PR! Small nitpick below.

[hopafoot]

@twiss Thanks for the suggestion, committed! I did get a little too verbose.

[twiss]

👍 Thanks!

[Frosne]

Ok, I'm a bit lost now.
Some time ago I've implemented github.com/WICG/webcrypto-secure-curves/pull/35.

This patch does the same thing?

[twiss]

Yes; due to me being slow in merging WICG/webcrypto-secure-curves#35 (and updating this repo) we got an equivalent PR in both repos (apologies for the duplicate work!)

The root issue is that Curve25519 is still in both repos. Perhaps we can remove Curve25519 from WICG/webcrypto-secure-curves to prevent this from happening (or more ideally, also merge Curve448 into this repo, and just archive WICG/webcrypto-secure-curves..)