Repository navigation
Conversation
The EdDSA branch inferred the curve from the DER length, which only matches PKCS#8 v1 keys (48 bytes). PKCS#8 v2 (RFC 5958) keys also carry the public key and were rejected with InvalidEddsaKey. Ed25519 is the only supported Edwards curve, so let the crypto provider parse the key and reject invalid ones instead. Fixes Keats#544
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Jwk::from_encoding_keyworked out the EdDSA curve from the length of the PKCS#8 DER document, and only accepted 48 bytes. That is the size of a PKCS#8 v1 Ed25519 key. A PKCS#8 v2 (RFC 5958) key also carries the public key, so it is 83 bytes and was rejected withInvalidEddsaKey. For example, keys fromaws_lc_rs::signature::Ed25519KeyPair::generate_pkcs8are v2.Ed25519 is the only supported Edwards curve, so this drops the length check. The provider's
ed_pub_components_from_private_keyalready parses the key withEd25519KeyPair::from_pkcs8orSigningKey::from_pkcs8_der, both of which accept v1 and v2 and validate the key. Anything that isn't a valid Ed25519 PKCS#8 key still returnsInvalidEddsaKey.This is the minimal fix. It doesn't conflict with the broader idea in the #506 discussion of normalizing keys in
EncodingKey/DecodingKey.Tests:
tests/eddsa/private_ed25519_v2_key.{pem,pk8}: the existing test key re-encoded as PKCS#8 v2, checked withopenssl asn1parse/openssl pkey.ed_jwk_from_ed25519_pkcs8_v2_key(PEM) anded_jwk_from_ed25519_pkcs8_v2_der_key(DER) check that both produce the samexas the v1 key. They fail onmasterand pass with this change.ed_jwk_from_invalid_der_keychecks that invalid input still returnsInvalidEddsaKey.cargo fmt --checkpasses.cargo clippy --all-targets --features {rust_crypto,aws_lc_rs} -- -D warningsis clean.cargo testpasses with and without default features, for both backends (stable toolchain). I didn't run the wasm tests.Also added a CHANGELOG entry under Unreleased.
Fixes #544