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

feat: signatures #96

Open
wants to merge 6 commits into
base: master
Choose a base branch
from
Open

feat: signatures #96

wants to merge 6 commits into from

Conversation

nugaon
Copy link
Collaborator

@nugaon nugaon commented Jan 16, 2023

Added smart contract library Signature.sol that contains all helper function to signature handling and added PostageStampSig and SocSig that shows how to utilize that with the functionality to recover Ethereum address from postage stamp and Single Owner Chunk signatures, respectively.

Copy link

@tfius tfius left a comment

Choose a reason for hiding this comment

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

Did you check eip-712 https://github.com/Mrtenz/eip-712 ?

) public pure returns (bytes32 r_, bytes32 s_, uint8 v_) {
require(sig.length == 65, "invalid signature length");

assembly {
Copy link

Choose a reason for hiding this comment

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

if you can avoid assembly and send r,s,v directly into recoverSigner, you would simplyfy contract

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

but the assemly part sets values for r_, s_ and v_, those are output parameters.

*/
return
keccak256(
abi.encodePacked("\x19Ethereum Signed Message:\n32", _messageHash)
Copy link

Choose a reason for hiding this comment

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

the added prefix string would make it an invalid as transaction

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

this is the way how Bee client signs all message
https://github.com/ethersphere/bee/blob/master/pkg/crypto/signer.go#L82-L83
we do not check signed blockchain transactions with this function.

@tfius
Copy link

tfius commented Jan 16, 2023

I am kinda missing context where is this going to be used ? Will this be used to verify postageStamp signer and only for it ?
Or why ?

If you plan to do any multisig kind verification then I have a huntch the replay attack could happen since there is no nonce.
Is timestamp from when batchId is created? If it is then message hash for (chunk, batchId, index and timestamp) is constant and you can have man in the middle attack. If timestamp is changing per request then its ok.

Copy link

@tfius tfius left a comment

Choose a reason for hiding this comment

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

if r,s,v can be supplied from outside, i would remove assembly part

@nugaon
Copy link
Collaborator Author

nugaon commented Jan 16, 2023

the postage stamp sig check will be used in the storage incentives. though, it can be a utility function for something else as well in the future.
the single owner chunk sig check is needed in the fdp sw3 contracts later.

Is timestamp from when batchId is created?

exactly.
https://github.com/ethersphere/bee/blob/master/pkg/postage/stamper.go#L45

how can you have man in the middle attack here? you need the private key from of postage stamp owner to sign the message.

@tfius
Copy link

tfius commented Jan 16, 2023

if timestamp would not change, one could cache signature. But since timestampe is changing it acts as a nounce, is always higher then before, then it can not occour.

@tfius
Copy link

tfius commented Jan 16, 2023

yes, this is then ok.

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.

2 participants