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
The solo machine has unnecessary layering when constructing the signature bytes the solo machine will sign over. The layers were added via a misunderstanding of the security implications. The current construction does not support the proposed changes in the spec repo to support Generic Verification functions. We should simplify the solo machine signature bytes to allow for the solo machine to verify signatures over new paths without modifying the existing code.
Problem Definition
The solo machine currently requires each path verified to have an associated DataType. Adding a type requires adding a new data type. This was added via a misunderstanding of the security implications. It was noted that the proto definitions do not provide uniqueness and we want to ensure that a signature corresponds to a specific path. What was missed is that the uniqueness is not provided by the proto definition, but by the usage of the proto definition. The path provided by core IBC will be unique and is already encoded into the signature data.
Doing these changes will change the verification of solo machine signatures. That is, solo machines would need to correctly construct their signature data based on the version of 06-solomachine the chain they are talking to is using.
I think the practical approach is to deprecate the existing functionality and support it as legacy handling for a certain amount of time (giving chains/solo machines time to update to the newest changes). We could either try to construct the new and old sign bytes and see if one of them verifies or create a temporary requirement that the diversifier append a -06-solomachine-version-1 to indicate it will use the new functionality.
For Admin Use
Not duplicate issue
Appropriate labels applied
Appropriate contributors tagged/assigned
The text was updated successfully, but these errors were encountered:
colin-axner
changed the title
Simplify solo machine
Simplify solo machine SignBytes construction
Mar 17, 2022
<!--
Please read and fill out this form before submitting your PR.
Please make sure you have reviewed our contributors guide before
submitting your
first PR.
-->
## Overview
Closes: cosmos#1107
<!--
Please provide an explanation of the PR, including the appropriate
context,
background, goal, and rationale. If there is an issue with this
information,
please provide a tl;dr and link the issue.
-->
## Checklist
<!--
Please complete the checklist to ensure that the PR is ready to be
reviewed.
IMPORTANT:
PRs should be left in Draft until the below checklist is completed.
-->
- [x] New and updated code has appropriate documentation
- [x] New and updated code has new and/or updated testing
- [ ] Required CI checks are passing
- [ ] Visual proof for any user facing features like CLI or
documentation updates
- [x] Linked issues closed with keywords
Summary
The solo machine has unnecessary layering when constructing the signature bytes the solo machine will sign over. The layers were added via a misunderstanding of the security implications. The current construction does not support the proposed changes in the spec repo to support Generic Verification functions. We should simplify the solo machine signature bytes to allow for the solo machine to verify signatures over new paths without modifying the existing code.
Problem Definition
The solo machine currently requires each path verified to have an associated DataType. Adding a type requires adding a new data type. This was added via a misunderstanding of the security implications. It was noted that the proto definitions do not provide uniqueness and we want to ensure that a signature corresponds to a specific path. What was missed is that the uniqueness is not provided by the proto definition, but by the usage of the proto definition. The path provided by core IBC will be unique and is already encoded into the signature data.
Proposal
DataType
DataType
toPath
inSignBytes
Backward compatibility considerations
Doing these changes will change the verification of solo machine signatures. That is, solo machines would need to correctly construct their signature data based on the version of 06-solomachine the chain they are talking to is using.
I think the practical approach is to deprecate the existing functionality and support it as legacy handling for a certain amount of time (giving chains/solo machines time to update to the newest changes). We could either try to construct the new and old sign bytes and see if one of them verifies or create a temporary requirement that the diversifier append a
-06-solomachine-version-1
to indicate it will use the new functionality.For Admin Use
The text was updated successfully, but these errors were encountered: