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

[spec] facilitate message authentication with candid serialization #124

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

chenyan-dfinity
Copy link
Contributor

@chenyan-dfinity chenyan-dfinity commented Oct 27, 2020

As discussed with @timohanke, we would like to explore using the value part (M) of Candid message for computing/verifying user-defined signature scheme.

This requires M to be a one-to-one mapping between value and bytes given a fixed type. Besides the non-determinism of leb128, this is already the case. We would like to add a statement in the spec to make sure it doesn't change in the future.

For the authentication to work, we assume the following:

  • Both sides agree on the method type (not sure how realistic this assumption is)
  • Both sides use the same/deterministic leb128 encoder
  • Canister code has access to the raw serialized bytes
  • Use domain separator to prevent replaying the message in other context

@rossberg
Copy link
Contributor

Note that we initially required a deterministic representation (and shortest LEB) but removed that requirement (can't find the PR right now). The reason we removed it is that it seemed impractical once you enrich the format. It already is the case that the type part of a serialised value can be represented and ordered arbitrarily, and there is no affordable way to avoid that.

I don't understand the use case well enough from the description, but it seems to require piercing the serialisation abstraction itself, by looking at the M-part in isolation. Tbh, that seems rather fishy and brittle, and I would not recommend it. Moreover, IIUC, it requires locking in a fixed method type and prevent any form of evolution on it, which is in conflict with our design goals.

@nomeata nomeata removed their request for review March 9, 2021 16:27
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