Skip to content
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

chore: remove derived Debug and Serialize from private key types #696

Merged
merged 7 commits into from
Oct 31, 2024

Conversation

mrain
Copy link
Contributor

@mrain mrain commented Oct 29, 2024

closes: #694

This PR:

In jf-signature crate

  • Manually implemented Debug for private signing keys to not print the actual value.
  • Remove derived (de)serialization. Implemented to/from_bytes() and the conversions to/from TaggedBase64.

This PR does not:

  • Private key type in elgamal crate still has derivations. Because of this ephemeral key in the ciphertext:

    pub(crate) ephemeral: EncKey<P>,

  • Private key type in aead crate still has derivations. Because of this ephemeral key in the ciphertext:

    ephemeral_pk: EncKey,

  • jf-vrf crate should be updated after to adopt these changes in jf-signature.

Key places to review:


Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

  • Targeted PR against correct branch (main)
  • Linked to GitHub issue with discussion and accepted design OR have an explanation in the PR that describes this work.
  • Wrote unit tests
  • Updated relevant documentation in the code
  • Added relevant changelog entries to the CHANGELOG.md of touched crates.
  • Re-reviewed Files changed in the GitHub PR explorer

@mrain mrain requested a review from alxiong as a code owner October 29, 2024 15:52
Copy link
Contributor

@alxiong alxiong left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

left comment on one file, but applicable to other similar places.

signature/src/schnorr.rs Outdated Show resolved Hide resolved
signature/src/schnorr.rs Show resolved Hide resolved
signature/src/bls_over_bls12381.rs Outdated Show resolved Hide resolved
Comment on lines +256 to +258
pub fn to_tagged_base64(&self) -> Result<TaggedBase64, Tb64Error> {
TaggedBase64::new(tag::BLS_SIGNING_KEY, &self.to_bytes())
}
Copy link
Contributor

@alxiong alxiong Oct 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. should we explicit about tag::BLS_OVER_BN254_SIGN_KEY?
  2. add code doc on SignKey that if one wants to implement serde on outer struct that contains this key (which should be rare), need to exercise self-caution about the implication of that, (since we removed it), and manually implement them by calling one of to_bytes or to_tagged_base64()

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm slightly hesitant on the first one. It's making a long tag.
Doc add in 5f85f10

fn serialized_size(&self, _compress: Compress) -> usize {
BLS_SIG_SK_SIZE
/// Deserialize `SignKey` from bytes.
pub fn from_bytes(bytes: &[u8]) -> Result<BLSSignKey, BLST_ERROR> {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it possible for these to have explicit lengths? e.g. can from_bytes take a &[u8; 32] here (since to_bytes() returns one)?

similar comment for the other to_bytes/from_bytes

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tried this: 8d25a8b

see if you like it or not

alxiong
alxiong previously approved these changes Oct 31, 2024
Copy link
Contributor

@alxiong alxiong left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

only left a nit comment on phrasing. otherwise LGTM.

@mrain mrain merged commit ca160ce into main Oct 31, 2024
5 checks passed
@mrain mrain deleted the cl/private_keys branch October 31, 2024 15:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Remove derived implementations for private key types
3 participants