feat(identity): implement protobuf encoding for all key types#3681
feat(identity): implement protobuf encoding for all key types#3681drHuangMHT wants to merge 100 commits intolibp2p:masterfrom
Conversation
Unreleased patch version 0.43.1 bumped. Added entry for PR 3606: Deriving 'Clone' for 'mdns::Event'
New unreleased minor version 0.44.0.
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Unsynced co-authered change.
…s to disabled feature
drHuangMHT
changed the title
libp2p-identity keypairs
|
Now I don't expect the branch to be merged with such aggressive changes...... |
thomaseizinger
left a comment
thomaseizinger
left a comment
There was a problem hiding this comment.
Thank you for the tidy-up!
There are some good ideas in here. I've made some comments throughout. Most importantly, I think we can easily do this in a non-breaking way by just adding new functions and deprecating old ones.
|
I merged latest master because there was some diff of other PRs. |
|
I've resolved the merge conflicts on this one for you. Are you still planning on splitting multiple PRs out of this one? Probably the easiest is to:
That way, we can slowly chip away at the changes in this PR and land them in master piece-wise! |
…-libp2p into identity-keypair
|
This pull request has merge conflicts. Could you please resolve them @drHuangMHT? 🙏 |
|
Now I guess this commit is mostly about renaming. |
|
This pull request has merge conflicts. Could you please resolve them @drHuangMHT? 🙏 |
| /// Encode a private key as protobuf structure. | ||
| /// | ||
| /// See <https://github.com/libp2p/specs/blob/master/peer-ids/peer-ids.md#key-types> for details on the encoding. | ||
| pub fn encode_protobuf(&self) -> Result<Vec<u8>, DecodingError> { |
There was a problem hiding this comment.
It is a shame that we rename the function here and cannot do the signature change to infalliblity at the same time. For that we need to also implement RSA encoding but I think for that we need to switch to the rsa crate which I want to debate first.
I wonder:
- should we delay the rename of this function until then so we can land the rest now
- should we rename it with the others and send users through another rename (+ signature change) once we support RSA
There was a problem hiding this comment.
Delay the rename then.
|
Should we remove this from |
Thanks, I removed the milestone. |
|
Are we |
Has anything changed around the situation of the |
Well the crate has been audited RustCrypto/RSA#60, but the non constant-time issue RustCrypto/RSA#19 is still not solved yet. |
In that case, I'd say we keep things as is for now. I have very limited capacity this month and will step down from active maintenance after that so I'd like to focus the remaining time on other issues. |
|
Not planned in the foreseeable future, closing this to clean up work tree on my fork. |
2 participants
Description
Previously, we only supported encoding the ed25519 private key. To be fully compliant with the spec, we also need to support encoding the other 3 key types ECDSA, RSA and secp256k1.
Resolves #3630.
Related #3623.
Related #3350.
Related #3649.
Notes & open questions
Breaking change.
Should we make the code panic when encountering missing feature?Blocked by #540.
Change checklist