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

Signed responses #621

Merged
merged 27 commits into from
May 31, 2024
Merged

Signed responses #621

merged 27 commits into from
May 31, 2024

Conversation

DavidM-D
Copy link
Contributor

@DavidM-D DavidM-D commented May 30, 2024

Make the smart contract verify that the responses we're getting back from the nodes are valid.

A large part of the change is move dependencies into crypto_shared so it can be used in the contract for verification.

This has a breaking change in that payloads are no longer little endian and are big endian (standard in our industry).

A subsequent PR will:

  • Get the native NEAR verification function working
  • Expose the well typed API
  • Unreverse the epsilon value
  • Force validation of scalars (not added in this PR)
  • Abstract the "Serializable" trait from its concrete types

@DavidM-D DavidM-D force-pushed the dmd/signed-response branch from 2c7b5a8 to 771c29d Compare May 30, 2024 13:56
@DavidM-D DavidM-D marked this pull request as ready for review May 30, 2024 15:46
CHANGELOG.md Outdated Show resolved Hide resolved
let derivation_path = format!("{EPSILON_DERIVATION_PREFIX}{},{}", predecessor_id, path);
let mut hasher = Sha256::new();
hasher.update(derivation_path);
let mut bytes = hasher.finalize();
Copy link
Member

Choose a reason for hiding this comment

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

consider native near_sdk::env::sha256 instead of wasm-side sha256 to be more efficient?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Will do

anyhow::bail!("cannot use either recovery id (0 or 1) to recover pubic key")
}

// #[cfg(not(target_arch = "wasm32"))]
Copy link
Member

Choose a reason for hiding this comment

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

This and // #[cfg(target_arch = "wasm32")] conditional compile seems unnecessary, as near-sdk handles mock of ecrecover etc. on non wasm case (by importing vmlogic from nearcore): https://github.com/near/near-sdk-rs/blob/master/near-sdk/src/environment/mock/mocked_blockchain.rs

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah excellent point

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Do you mind if I move this to the next PR? The merge conflicts are killing me

Copy link
Collaborator

@volovyks volovyks left a comment

Choose a reason for hiding this comment

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

Great work @DavidM-D !

contract/Cargo.toml Show resolved Hide resolved
contract/src/lib.rs Outdated Show resolved Hide resolved
let mut hasher = Sha256::new();
hasher.update(derivation_path);
let mut bytes = hasher.finalize();
// Due to a previous bug in our Scalar conversion code, this hash was reversed, we reverse it here to preserve compatibility, but will likely change this later.
Copy link
Collaborator

Choose a reason for hiding this comment

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

What is the reason for postponing this breaking change? Isn't now the best time to do it?

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 just trying to break up this PR a bit, I'll get it through before the 0.3.0 release

let payload_hash_scalar = k256::Scalar::from_bytes(&payload_hash); // TODO: why do we need both reversed and not reversed versions?
let mut payload_hash_reversed: [u8; 32] = payload_hash;
payload_hash_reversed.reverse();
payload_hash.reverse();
Copy link
Collaborator

Choose a reason for hiding this comment

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

We are still reversing the hash here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This code was and still is a bit of a mess.

Previously converting a Scalar to bytes reversed the bytes and converted to a Scalar.

The big_r and s values were generated using chain signatures from an older commit, therefore the signature is generated against a reversed hash.

You now have to reverse the bytes to generate the same Scalar and therefore Signature and this tests that. I'll write a comment to this effect, after this change has rolled out we should update this test using new values.

@DavidM-D DavidM-D force-pushed the dmd/signed-response branch from ad5976c to 942aca4 Compare May 31, 2024 13:06
match self {
Self::V0(mpc_contract) => mpc_contract.pending_requests.get(request),
}
}

Copy link
Collaborator

Choose a reason for hiding this comment

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

Do we need this?

@@ -70,36 +73,53 @@ impl Default for VersionedMpcContract {
}
}

#[derive(BorshDeserialize, BorshSerialize, Serialize, Deserialize, Debug, Clone)]
pub struct SignatureRequest {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why do we need SignatureRequest and SignRequest? Can we use 1 struct?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

SignatureRequest describes all the information about a request required by the signing protocol, SigRequest is the structure of the request sent to the contract, so they're different. That being said, we can probably come up with better names.

Copy link
Collaborator

@volovyks volovyks left a comment

Choose a reason for hiding this comment

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

We can merge this to avoid future conflicts and unblock yield/resume. Great contribution!

@DavidM-D DavidM-D merged commit 22c85cf into develop May 31, 2024
6 checks passed
@DavidM-D DavidM-D deleted the dmd/signed-response branch May 31, 2024 18:49
Copy link

Terraform Feature Environment Destroy (dev-621)

Terraform Initialization ⚙️success

Terraform Destroy success

Show Destroy Plan


No changes. No objects need to be destroyed.

Either you have not created any objects yet or the existing objects were
already deleted outside of Terraform.

Destroy complete! Resources: 0 destroyed.

Pusher: @DavidM-D, Action: pull_request, Working Directory: ``, Workflow: Terraform Feature Env (Destroy)

DavidM-D added a commit that referenced this pull request Jul 18, 2024
* Moved kdf out of the node

So the contract code can inherit it (also maybe include this in a client
library later?)

* Migrated contract over to using API with context

* Fix test imports

* Successfully merged into phuongs mega PR

* Builds with signature verification

* Working tests with a compatible API

* All tests pass (with spurious reversing)

* Test rogue responses fail

* Generate recovery ID on node

* Switched to use native near function to verify sig

* Cleanup

* Removed Multichain Signature type

* Add missing import in wasm builds

* Added a changelog explaining the API changes

* Cleanup comments

* Move into_eth_sig back up the dep tree

* Migrate recovery ID functions up the tree

* Clippy fix

* Do the native function in a seperate PR

It's not working with the CI

* Fix fmt

* Clippy fixes

* Compiling after rebase

* Update contract/src/lib.rs

Co-authored-by: Serhii Volovyk <[email protected]>

* Fixed types and removed unneeded type

* Simplify API

* Shrink diff

* Comment explaining the mad test

---------

Co-authored-by: Serhii Volovyk <[email protected]>
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.

3 participants