-
Notifications
You must be signed in to change notification settings - Fork 282
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
Handle invalid Addresses #8970
Comments
Some hopefully helpful theory: For grumpkin, Why don't square roots always exist in prime finite fields? They just don't. In a circuit, how can we efficiently demonstrate that an This code (from another project I was working on) should do it: global KNOWN_NON_RESIDUE = 5;
unconstrained fn __sqrt(x: Field) -> (bool, Field) {
let is_sq = std::ec::is_square(x);
let mut maybe_sqrt = 0;
if is_sq {
maybe_sqrt = std::ec::sqrt(x);
assert(maybe_sqrt * maybe_sqrt == x); // to catch bugs
} else {
// If x a non-residue, x * KNOWN_NON_RESIDUE will be a residue, since -1 * -1 = 1 when considering their legendre symbols.
let demo_not_square = x * KNOWN_NON_RESIDUE;
maybe_sqrt = std::ec::sqrt(demo_not_square);
assert(maybe_sqrt * maybe_sqrt == demo_not_square); // to catch bugs
}
(is_sq, maybe_sqrt)
}
fn sqrt(x: Field) -> (bool, Field) {
let (is_sq, maybe_sqrt) = __sqrt(x);
let mut out: (bool, Field) = (false, 0);
if is_sq {
let sqrt = maybe_sqrt;
assert(sqrt * sqrt == x);
out = (true, sqrt);
} else {
let not_sqrt = maybe_sqrt;
let demo_x_not_square = x * KNOWN_NON_RESIDUE;
// Given that this is square, it implies x is not square.
assert(not_sqrt * not_sqrt == demo_x_not_square);
}
out
} Saying a value If you take a known non-residue (5 is a non-residue in the Noir "Modulo a prime, the product of two nonresidues is a residue and the product of a nonresidue and a (nonzero) residue is a nonresidue." In other words: |
#8969 will require computing the
Point
that backs anAztecAddress
from its x coordinate, but the x coordinate might not be in the curve in the first place. If this happens, then we won't be able to do elliptic curve math on it, so we need an escape hatch.Since we define addresses as values that represent the x coordinate of a point in the curve, these address values are truly invalid, and cannot be used for anything. No decryption can be done with them, nor can they do things such as nullify notes since they won't be able to compute this invalid x coord. Therefore, it is fine to simply skip whatever action needed to be done to avoid King of the Hill attack vectors. For example, in the case of sending a note we should not send it at all.
This means that we should likely change
AztecAddress::to_point
so that it results something like anOption
, to handle the invalid derivation scenario.The text was updated successfully, but these errors were encountered: