Serde feature flag?
tmpfs opened this issue · 5 comments
Hi @fjarri ,
Whilst researching integrating with synedrion I notice the serde support is only activated during tests, would it be worth adding a serde feature flag to the library.
I activated serde support with this:
k256 = { version = "0.13.2", default-features = false, features = ["pem", "serde"] }
But it took my a while to figure out that I also needed to activate the pem feature in order for Serialize and Deserialize to be implemented for VerifyingKey.
Sorry it took me a while to get to this.
Could you explain a little more, what VerifyingKey are you referring to? If you mean the one from k256, it's not a part of the library, but an external type. synedrion just returns it and never needs to serialize it; if you want to do it, you have to enable these features yourself. It is documented (arguably not very clearly but still) in ecdsa docs.
That's cool @fjarri, yes I mean the VerifyingKey from k256. In the test specs you define VerifyingKey as part of the execution so I (probably wrongly) assumed they needed to be sent:
type MessageOut = (VerifyingKey, VerifyingKey, CombinedMessage<Signature>);
type MessageIn = (VerifyingKey, CombinedMessage<Signature>);And then I noticed we do actually need access to the from VerifyingKey to call preprocess_message:
println!("{key_str}: waiting for a message");
let (from, message) = rx.recv().await.unwrap();
// Perform quick checks before proceeding with the verification.
let preprocessed = session
.preprocess_message(&mut accum, &from, message)
.unwrap();Is there a better recommended way to access the from VerifyingKey without transferring it over the network?
Ah I see what you mean now. It is a bit confusing, because there are two types verifying keys involved. This one is the one that identifies the parties, and the corresponding signing key signs the messages between parties. It is external - the public types provided by the crate are generic over it. It can be, for example, the key of whatever blockchain network the crate is used in. It may be something other than secp256k1, or, in fact, it doesn't even have to be an ECC key, as long as it implements the required traits. So again, it is up to the user to ensure it is serializable. The lines you're quoting are from the test where I don't need serialization, so I can just supply k256::ecdsa::VerifyingKey.
As for the from, it is currently assumed that the verifying key of the sender will be somehow provided by whatever protocol is used to pass around messages. Maybe the user will bundle it, or encrypt-and-sign (in which case the key can be derived from the signature and the payload).
Perhaps it is a good idea to bundle the key into the message on synedrion level. I need to think about it. It seems kind of redundant because it is already implicitly encoded into the pair (payload, signature) - since you can derive it from that. I'll ask our resident cryptographer next week. Meanwhile, you will need to handle transferring it yourself.
Perhaps it is a good idea to bundle the key into the message on synedrion level. I need to think about it. It seems kind of redundant because it is already implicitly encoded into the pair (payload, signature) - since you can derive it from that. I'll ask our resident cryptographer next week. Meanwhile, you will need to handle transferring it yourself.
Thanks for the clarification @fjarri , please let me know when you decide if you want to defer to the library user to manage the from public key or whether you will fold it into the message structs. Personally, I think it would be better if synedrion managed this in the messages type, ie: we only ever need to transfer CombinedMessage and the from public key is an implementation detail.