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

Allow SharedSecret to be created from byte array #417

Merged
merged 2 commits into from Mar 11, 2022

Conversation

dspicher
Copy link
Contributor

This was accidentally removed in 8b2edad. See also the discussion
on #402

Closes #416.

apoelstra
apoelstra previously approved these changes Mar 10, 2022
Copy link
Member

@apoelstra apoelstra left a comment

Choose a reason for hiding this comment

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

ACK 16e37ec

Can you also add a commit which bumps the minor version number in Cargo.toml and adds an entry to CHANGELOG.md? This will let me quickly publish a new version.

@apoelstra
Copy link
Member

Also can you make sure this compiles with rustc 1.29? Sorry, we'll eliminate this requirement in the next major version I think.

elichai
elichai previously approved these changes Mar 10, 2022
Copy link
Member

@elichai elichai left a comment

Choose a reason for hiding this comment

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

tACK 78ed572

src/ecdh.rs Outdated
fn from(arr: [u8; SHARED_SECRET_SIZE]) -> Self {
SharedSecret(arr)
}
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm personally not keen on adding impl From<Inner> for Newtype in case there is struct Newtype(Inner); It encourages just calling into() which hides the newtype.

I suggest from_bytes(bytes: [u8; SHARED_SECRET_SIZE]) -> Self method instead.

Copy link
Member

Choose a reason for hiding this comment

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

I don't have a strong preference here. I'm not sure what you mean by "hiding" .. a call to .into is pretty explicit.

Copy link
Collaborator

Choose a reason for hiding this comment

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

It's not clear which type is converted into which until you review a bigger chunk of code.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done. I'm not very familiar with #[inline] usage, let me know if this is needed here as well.

Copy link
Member

@tcharding tcharding Mar 10, 2022

Choose a reason for hiding this comment

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

Another data point: we have secret_bytes() -> [u8; SHARED_SECRET_SIZE] already which is slightly strangely named, the reason is that its the same method name used for various keys, especially KeyPair (for which it makes most sense). In light of this I'd find from_bytes the least surprising name so as to kind of match with secret_bytes.

Copy link
Collaborator

Choose a reason for hiding this comment

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

#[inline] could be useful/nice but not super-important. Especially if one uses LTO.

Copy link

Choose a reason for hiding this comment

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

@Kixunil @apoelstra @dspicher

I think it is a poor decision to avoid implementing traits from the standard library which are even part of the standard prelude. The From trait defines a standard interface that allows for better composability, e.g. you can define functions like this

fn process<T: Into<Foo>>(t: T)

and it will compile for all types that can be converted into Foo. Also, you can always opt-in for doing the conversion explicitly:

let bar: Bar = foo.into()

I really don't understand why we need to segue here out of the standard rust interface for doing conversions.

apoelstra
apoelstra previously approved these changes Mar 10, 2022
Copy link
Member

@apoelstra apoelstra left a comment

Choose a reason for hiding this comment

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

ACK 78ed572

But will hold off merging until @Kixunil is satisified.

Copy link
Member

@apoelstra apoelstra left a comment

Choose a reason for hiding this comment

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

ACK 463148f

@apoelstra
Copy link
Member

Looks like the tests have actually passed -- not sure why CI reporting is being weird.

@apoelstra apoelstra merged commit 330c91b into rust-bitcoin:master Mar 11, 2022
@apoelstra
Copy link
Member

Holding off on publishing new version until #418.

Copy link
Collaborator

@Kixunil Kixunil left a comment

Choose a reason for hiding this comment

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

Post-merge ACK :)

apoelstra added a commit that referenced this pull request Mar 11, 2022
de65fb2 Implement de/serialization for SharedSecret (Tobin Harding)

Pull request description:

  As we do for other keys implement serde de/serialization for the `SharedSecret`.

  Please note, this adds `from_slice` and `from_bytes` (borrowed and owner respectively) because I needed to use them. Doing so treads on @dspicher's toes because he is in the process of implementing an owned conversion method for `SharedSecret`. The fair thing to do would be let #417 resolve and merge before merging this one (I can rebase).

  ~Side note, its kind of rubbish that `BytesVisitor` deserializes into a buffer (presumably) then we reallocate and copy the buffer to use the borrowed conversion method due to the serde function signature `fn visit_bytes<E: de::Error>(self, v: &[u8]) -> Result<Self::Value, E>`~ (I was bumbling nonsense.)

  Closes: #416

ACKs for top commit:
  apoelstra:
    ACK de65fb2

Tree-SHA512: 3d484f160d8a459a867f645736713984bad982429236ac5351c20b6c21b42cec86e68009fe7adf062912037cf7e747e5b15357a5fd7900e52169f208a4e56710
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.

SharedSecret should have a "deserialize from bytes" method and serde impls
6 participants