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

Secure commit-reveal and various contract, core library, and client upgrades for that #56

Merged
merged 35 commits into from
Jul 25, 2021

Conversation

polymorpher
Copy link
Owner

@polymorpher polymorpher commented Jul 25, 2021

Update 7/26/2021: This design has a mild DoS issue, identified by Andrianna Polydouri and her team. I will post another PR soon to fix it.


Fixes #47

Contract is upgraded to v6, which requires two arguments in commits: a commit hash, and a parameter hash. The commit hash is a hash of the credentials (neighbor, index, eotp). The parameter hash is a hash of the arguments for each specific operation type. For example, in a transfer operation, the parameter hash is a keccak256(destination . amount) where both arguments are casted to 32 bytes and . is concatenation.

All core library (/code/lib) functions are updated to work with the new commit-reveal structure.
The client and relayer are also upgraded. They are also made backward-compatible with wallets that are v5 or below.

All core library tests (/code/test) are also updated and made to work again. The tests are very primitive right now. They should be expanded soon in next versions.

Address issue #47 man-in-the-middle attack;
Added a map for constant time commit lookup;
Make some global variables immutable;
Added appropriate comments for complex functions;
Fixed a bug where token keys are computed using sha256 isntead of keccak256;
Unified all reveal functions into one
@polymorpher polymorpher merged commit ed16c0e into master Jul 25, 2021
Copy link
Collaborator

@ivan-homoliak-sutd ivan-homoliak-sutd left a comment

Choose a reason for hiding this comment

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

I was focusing on the smart contract part, but it is a bit hard to review/audit with the current code complexity.

// constants
uint32 constant REVEAL_MAX_DELAY = 60;
uint32 constant SECONDS_PER_DAY = 86400;
uint256 constant AUTO_RECOVERY_TRIGGER_AMOUNT = 1 ether;
Copy link
Collaborator

Choose a reason for hiding this comment

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

By doing so, the security of this wallet is 100% delegated to the security of the wallet that serves for last resort functionality. Therefore, I'd suggest to have at least some condition that would allow transfer to last resort only after some interval of inactivity, e.g., 1 month or something better.

Copy link
Owner Author

Choose a reason for hiding this comment

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

I agree. We should find a more flexible condition. One use case of recovery by auto trigger is loss-prevention upon theft. Requiring a long delay would render recovery in this use case ineffective. Ideally, the condition should also take this into consideration and balance on the trade-offs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants