You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hey folks, while reviewing the Oracles contract I started digging into the data signed by oracles and how it's being verified.
Overall, my main concern was to understand the extent to which these signatures might be reused.
From my understanding, the main ways in which the contract intends to prevent reuse are (i) only allowing a trusted entity to submit signatures and (ii) using nonces tracked in state. As far as I can see, these do the job well.
Having said that, I think there may be room to make those signatures more robust. Just to prevent any unexpected misuse in the future.
If you want to do it the "standard" way, perhaps might be worth taking a look at EIP 712. But it might be like an overkill for your specific use case.
So if you decide to stay in the custom way, at least you might want to consider including things like: the chain id (to definitely rule out any reuse across chains) and the address of the contract where they're intended to be validated (to definitely rule out reuse on the same chain but different contracts). You could go on, for instance including an expiration timestamp. I'd say that more specific the data signed, the less chances of running into reuse issues. As an interesting side-effect, making the signed data more specific would also reduce the amount of trust delegated to the entity ultimately in charge of submitting the signatures.
Given the current state of nonces in the contracts on Etherem/Goerli/Gnosis Chain, the different set of addresses used for oracles across these chains, the fact that the three signature-handling functions in the Oracles contract take different data types, and that only a trusted entity can submit signatures to the contracts, I don't think there's any risk today.
Still I wanted to raise the topic for you to be aware.
The text was updated successfully, but these errors were encountered:
Hey folks, while reviewing the
Oracles
contract I started digging into the data signed by oracles and how it's being verified.Overall, my main concern was to understand the extent to which these signatures might be reused.
From my understanding, the main ways in which the contract intends to prevent reuse are (i) only allowing a trusted entity to submit signatures and (ii) using nonces tracked in state. As far as I can see, these do the job well.
Having said that, I think there may be room to make those signatures more robust. Just to prevent any unexpected misuse in the future.
If you want to do it the "standard" way, perhaps might be worth taking a look at EIP 712. But it might be like an overkill for your specific use case.
So if you decide to stay in the custom way, at least you might want to consider including things like: the chain id (to definitely rule out any reuse across chains) and the address of the contract where they're intended to be validated (to definitely rule out reuse on the same chain but different contracts). You could go on, for instance including an expiration timestamp. I'd say that more specific the data signed, the less chances of running into reuse issues. As an interesting side-effect, making the signed data more specific would also reduce the amount of trust delegated to the entity ultimately in charge of submitting the signatures.
Given the current state of nonces in the contracts on Etherem/Goerli/Gnosis Chain, the different set of addresses used for oracles across these chains, the fact that the three signature-handling functions in the
Oracles
contract take different data types, and that only a trusted entity can submit signatures to the contracts, I don't think there's any risk today.Still I wanted to raise the topic for you to be aware.
The text was updated successfully, but these errors were encountered: