-
Notifications
You must be signed in to change notification settings - Fork 60
relayer: support Google Cloud KMS signing #584
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
Open
zmanian
wants to merge
3
commits into
main
Choose a base branch
from
zaki/relayer-kms-signer
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🌐 Web query:
ethers-rs Signature recover RecoveryMessage From impl slice hash prefix💡 Result:
In ethers-rs, you can recover an Ethereum address from a signature using the Signature::recover method [1][2][3]. This method accepts any type that implements Into [2][4]. The RecoveryMessage enum is designed to handle two distinct scenarios [2][5]: 1. Data(Vec): If you provide raw message bytes, ethers-rs automatically handles the EIP-191 prefixing (i.e., hashing the message with the Ethereum Signed Message domain separator) before attempting recovery [2][4]. 2. Hash(H256): If you have already hashed your message (e.g., using Keccak256), you can pass the hash directly. In this case, the library treats it as a precomputed hash and skips the additional EIP-191 prefixing process [2][4]. To recover an address from a slice or hash, you can use the following patterns: // Recovering from raw message bytes (automatic EIP-191 hashing) let message = b"hello"; let recovered_address = signature.recover(&message[..])?; // Recovering from a precomputed hash (no extra prefixing) use ethers::core::types::H256; let hash = H256::from(keccak256("hello")); // Assuming custom hashing let recovered_address = signature.recover(hash)?; The Signature::recover implementation internally calls hash_message if you provide Data, or uses the raw hash if you provide Hash [2][4]. It then utilizes the VerifyingKey::recover_from_prehash method to derive the public key from the signature's recovery ID and the message hash [2][4]. Finally, it performs the standard Ethereum address derivation: taking the Keccak256 hash of the uncompressed public key (excluding the 0x04 prefix) and keeping the last 20 bytes [2][4].
Citations:
🏁 Script executed:
Repository: PeggyJV/gravity-bridge
Length of output: 9700
🏁 Script executed:
Repository: PeggyJV/gravity-bridge
Length of output: 280
🏁 Script executed:
Repository: PeggyJV/gravity-bridge
Length of output: 11039
🏁 Script executed:
Repository: PeggyJV/gravity-bridge
Length of output: 1326
🏁 Script executed:
Repository: PeggyJV/gravity-bridge
Length of output: 328
🌐 Web query:
crates.io ethers-core 2.0.14 source signature.rs ethers_core::types::signature💡 Result:
In the ethers-core crate version 2.0.14, the Signature struct is defined in the source file src/types/signature.rs [1][2]. This struct represents an ECDSA signature and contains the following fields: [3][4] pub struct Signature { pub r: U256, pub s: U256, pub v: u64, } The Signature implementation includes methods for verifying messages and recovering addresses, such as recover, recover_typed_data, and verify [3][4]. These methods typically use Electrum notation for the v value (expected to be 27 or 28) [4]. The source code for this specific version can be accessed directly through the Docs.rs platform [1][2]. Note that the ethers-rs library is in the process of being deprecated, and users are encouraged to look toward newer alternatives [5][6].
Citations:
🌐 Web query:
docs.rs 2.0.14 ethers_core::types::signature Signature recover RecoveryMessage impl From<[u8; 32]>💡 Result:
In ethers-core 2.0.14, the RecoveryMessage enum is used to represent the message data that can be signed or verified [1][2]. It provides an implementation of the From trait for [u8; 32], which allows a 32-byte array (typically a message hash) to be converted directly into a RecoveryMessage variant [2][3]. Specifically, the implementation is defined as follows: impl From<[u8; 32]> for RecoveryMessage { fn from(hash: [u8; 32]) -> Self { RecoveryMessage::Hash(hash.into) } } When used with the Signature::recover method, which accepts any type M that implements Into, passing a [u8; 32] will treat the data as a precomputed message hash [1][2]. If the input is instead RecoveryMessage::Data(Vec), the library will automatically hash the message using EIP-191 before performing the recovery [1][2].
Citations:
🌐 Web query:
docs.rs ethers-core 2.0.14 source impl From<&[u8]> RecoveryMessage Data prefix💡 Result:
In ethers-core version 2.0.14, the RecoveryMessage enum is defined in src/types/signature.rs [1][2]. The implementation of From<&[u8]> for RecoveryMessage converts a slice of bytes into a RecoveryMessage::Data variant by converting the slice into a Vec and then into the enum [1][2]. Regarding the specific mention of a data prefix, the RecoveryMessage enum itself does not contain a prefixing implementation within its From conversion [1][2]. Instead, the prefixing logic for Ethereum signed messages is handled by the hash_message function, located in src/utils/hash.rs [3]. This function implements EIP-191 by prepending the prefix "\x19Ethereum Signed Message:\n" and the decimal length of the message to the input bytes before hashing them with Keccak-256 [3]. The source code for the relevant implementation is as follows: // From src/types/signature.rs in ethers-core 2.0.14 [2] impl From<&[u8]> for RecoveryMessage { fn from(s: &[u8]) -> Self { s.to_owned.into } } // From src/utils/hash.rs in ethers-core 2.0.14 [3] pub fn hash_message<T: AsRef<[u8]>>(message: T) -> H256 { const PREFIX: &str = "\x19Ethereum Signed Message:\n"; let message = message.as_ref; let len = message.len; let len_string = len.to_string; let mut eth_message = Vec::with_capacity(PREFIX.len + len_string.len + len); eth_message.extend_from_slice(PREFIX.as_bytes); eth_message.extend_from_slice(len_string.as_bytes); eth_message.extend_from_slice(message); H256(keccak256(ð_message)) }
Citations:
🌐 Web query:
docs.rs ethers-core 2.0.14 source Signature recover MessageSignature signature.rs line💡 Result:
In version 2.0.14 of the ethers-core crate, the recover method for the Signature struct is defined within the src/types/signature.rs file [1][2]. The implementation of the recover method, which recovers the Ethereum address used to sign a given message, typically begins around line 91 of the source file [2]. The method accepts a message that implements the Into trait and returns a Result containing an Address or a SignatureError [1][2]. Within this method, the signature is converted into a recoverable signature and a recovery ID using the internal as_signature method [2]. It then utilizes the VerifyingKey::recover_from_prehash function from the underlying elliptic curve library to recover the public key, which is subsequently hashed to derive the Ethereum address [2]. Note that ethers-core is part of a library that is in the process of being deprecated, and it is recommended to use the re-exports directly from the ethers crate instead [3][4].
Citations:
🏁 Script executed:
Repository: PeggyJV/gravity-bridge
Length of output: 2559
Pass an owned hash into the GCP KMS recovery path.
normalize(&hash, &sig)passes a&[u8]intosig.recover(...), andetherstreats&[u8]as raw data that receives the Ethereum signed-message prefix. KMS signs the raw EIP-712 hash, so recovery for typed-data and transaction signatures can return “Invalid signature while normalizing”. Copy the[u8; 32]/H256value before callingnormalizeso it is treated as a raw hash.🤖 Prompt for AI Agents