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

Adopt ZIP 216: Require Canonical Jubjub Point Encodings #82

Closed
str4d opened this issue Jun 2, 2021 · 1 comment · Fixed by #85
Closed

Adopt ZIP 216: Require Canonical Jubjub Point Encodings #82

str4d opened this issue Jun 2, 2021 · 1 comment · Fixed by #85
Assignees
Labels
fix:vulnerability Issues related to fix vulnerabilities of the architecture or software team:Core Low Level Core Development Team (Rust)

Comments

@str4d
Copy link

str4d commented Jun 2, 2021

Jubjub was specified such that all points are strongly-typed with canonical representations. However, there is a bug in the version of the jubjub crate that you forked from, which allows non-canonical encodings to be silently accepted for two points:

  • (0, 1), which is the identity;
  • (0, -1), which is a point of order two.

We are fixing this upstream in zkcrypto#46; I recommend that you similarly adopt ZIP 216 (or equivalent for your usages of Jubjub).

@autholykos autholykos added team:R&D Research & Development (Cryptographic Protocol) fix:vulnerability Issues related to fix vulnerabilities of the architecture or software labels Jul 1, 2021
@CPerezz
Copy link

CPerezz commented Jul 2, 2021

Hey @str4d I just noticed about this. I wasn't subscribed to the repo and did not see it. Thanks a lot for opening the issue and leave the explanation and the background. We will address it immediately.

Thanks so much!!!
CPerezz.

@autholykos autholykos added team:Core Low Level Core Development Team (Rust) and removed team:R&D Research & Development (Cryptographic Protocol) labels Jul 20, 2021
CPerezz added a commit that referenced this issue Sep 8, 2021
Since we're not in prod yet, we don't need to be backwards compatible
with the previous encoding and simply accept the next one.

The solution prevents a point of order 2 (0, -1) to be accepted as a
valid point.

For more details, see: https://zips.z.cash/zip-0216

Special thanks to Zcash and @str4d for pinging and filing an issue in
regards of that.

Resolves:  #82
@CPerezz CPerezz mentioned this issue Sep 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fix:vulnerability Issues related to fix vulnerabilities of the architecture or software team:Core Low Level Core Development Team (Rust)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants