-
Notifications
You must be signed in to change notification settings - Fork 198
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Some serializers fail to serialize/deserialize VerifyingKey
s & Signature
s correctly (k256)
#536
Comments
I'm guessing that the issue is JSON and TOML need toplevel objects/tables for a document to be valid. So you'll need to put the key/signature to be serialized in some kind of wrapper, e.g. let signature = ...;
json! { signature } |
Hmm yeah good thought, but adding the let val = serde_json::to_string(&SigningKey::random(&mut OsRng).verifying_key()).unwrap();
println!("No macro: {}", val);
println!("macro: {}", json! { val });
As a sanity check, all three serializers seem ok if I give them some arbitrary type: #[derive(Clone, Copy, Deserialize, Serialize)]
struct SomeStruct {
x: f32,
y: String
}
#[test]
fn general_ser_deser_test() {
let some_struct = SomeStruct {
x: 4.2,
y: "cool string",
};
ser_deser_test(
|val| serde_json::to_string(val).map_err(|err| err.to_string()),
|str| serde_json::from_str(str).map_err(|err| err.to_string()),
some_struct,
);
ser_deser_test(
|val| toml::to_string(val).map_err(|err| err.to_string()),
|str| toml::from_str(str).map_err(|err| err.to_string()),
some_struct,
);
ser_deser_test(
|val| bincode::serialize(val).map_err(|err| err.to_string()),
|bytes| bincode::deserialize(bytes).map_err(|err| err.to_string()),
some_struct,
);
} |
You'll need to construct the outer JSON/TOML object before serializing as a string. |
I think it's possible that I may be misunderstanding, but if the failure was caused by the outer JSON/TOML missing, then shouldn't the serialization tests of |
A struct maps directly to a JSON object or TOML table. So there isn't an issue there. Can you try adding a |
Yeah I'm still getting a failure on deserialization: #[test]
fn json_signing_key() {
let k = SigningKey::random(&mut OsRng).verifying_key();
let ser = &json!{ k }.to_string();
let deser = serde_json::from_str(ser).expect("Deserialization failure");
assert_eq!(k, deser);
}
|
Now you have the problem that you are trying to deserialize a Try defining a |
Thanks for the quick responses tarcieri. It's unfortunately still failing, however it's failing when it tries to parse the value for the field of the struct, so I don't think it's related to something missing at the top of the JSON payload: #[derive(Clone, Debug, Deserialize, PartialEq, Serialize)]
struct SomeStruct {
k: VerifyingKey,
}
#[test]
fn json_signing_key() {
let some_struct = SomeStruct {
k: SigningKey::random(&mut OsRng).verifying_key(),
};
let ser = serde_json::to_string(&some_struct).unwrap();
let deser = serde_json::from_str(&ser).expect("Deserialization failure");
assert_eq!(some_struct, deser);
}
With the actual serialized payload, column
|
Aah, that does appear to be a legitimate issue with the deserializer when used with a text-based format. It's currently decoding to a byte slice, which works with binary formats but not with text-based ones. That's easy enough to fix by changing it to a When encoding in JSON, there's also JWK as an interoperable format: https://docs.rs/elliptic-curve/latest/elliptic_curve/struct.JwkEcKey.html |
This commit changes the `Serializer` and `Deserializer` impls on the `PublicKey` type to work more like the ones on other types in this crate and its downstream dependencies: - Use binary DER serialization with binary formats (what it does today) - Use an upper-case hex serialization of the DER in conjunction with "human readable" formats Though richer formats exist for this use case (such as `JwkEcKey` which is an existing implementation of JWK), hex-serialized DER is relatively easy to work with, and can be decoded easily with online tools such as https://lapo.it/asn1js/ Note that the `Deserialize` impl for `PublicKey` never worked with human-readable formats as it was attempting to deserialize to `&[u8]`, which doesn't work with formats like JSON or TOML because they need an intermediate decoding step and therefore require deserialization to `Vec<u8>`. So this isn't a breaking change from the `Deserialize` side. Fixes RustCrypto/elliptic-curves#536
So I elected to do what most of the other types in Unfortunately in the current form it's a bit hard to test. I'd really like to extract this serialization logic into a separate crate which can have the sort of tests you're doing in this issue against a number of different encoding formats so we can solve these serialization problems once and for all in a single place. |
This commit changes the `Serializer` and `Deserializer` impls on the `PublicKey` type to work more like the ones on other types in this crate and its downstream dependencies: - Use binary DER serialization with binary formats (what it does today) - Use an upper-case hex serialization of the DER in conjunction with "human readable" formats Though richer formats exist for this use case (such as `JwkEcKey` which is an existing implementation of JWK), hex-serialized DER is relatively easy to work with, and can be decoded easily with online tools such as https://lapo.it/asn1js/ Note that the `Deserialize` impl for `PublicKey` never worked with human-readable formats as it was attempting to deserialize to `&[u8]`, which doesn't work with formats like JSON or TOML because they need an intermediate decoding step and therefore require deserialization to `Vec<u8>`. So this isn't a breaking change from the `Deserialize` side. Fixes RustCrypto/elliptic-curves#536
This CL replaces the default deserialization derivation with a custom one which uses FromStr (https://docs.rs/ecdsa/0.13.4/ecdsa/struct.VerifyingKey.html#impl-FromStr) to deserialize from a PEM string into a p256::ecdsa::VerifyingKey. The default deserialization derivation does not behave as expected: RustCrypto/elliptic-curves#536. This CL also adds a test case for deserializing that key from PEM, and deserializing a PublicKeyAndId struct from JSON. Change-Id: I2ea02fa56b70c430935e40c74f30d2a8e1173516 Bug: 95799 Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/667108 Reviewed-by: Sen Jiang <senj@google.com> Commit-Queue: James Buckland <jbuckland@google.com>
It seems that some Serde serializers have issues when serializing
VerifyingKey
s andSignature
s. They all serialize fine, but Serde returns an error for certain serializers when deserializing back to the original type.I've tested it with three serializers, and it seems to be a bit of a hit or miss if it works. It's a bit verbose, but I've included tests that reproduce the issue. I would normally just include a Rust Playground link, but they don't support
k256
.Dependencies:
With results:
I'm not very experienced with cryptography, so let me know if I'm doing something that I shouldn't be. 🙂
The text was updated successfully, but these errors were encountered: