-
Notifications
You must be signed in to change notification settings - Fork 17
DO NOT MERGE - zkpassport circuit audit comments #96
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -48,5 +48,6 @@ | |
"ts-jest": "^29.1.2", | ||
"tsx": "^4.19.3", | ||
"typescript": "^5.0.0" | ||
} | ||
}, | ||
"packageManager": "[email protected]+sha512.8cd0e31bd60779ef4ca92b855fb3462c7ec35ce8b345752b7349a68239776417f46d41d79c8047242d9c93b48a1516f64c7444ebe747d9a02bf26868e6fa1f2b" | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,13 +1,27 @@ | ||
use commitment::nullify; | ||
use compare_citizenship::compare_citizenship; | ||
|
||
// Q: Is this superfluous, given that this can be achieved with `disclose`? | ||
fn main( | ||
comm_in: pub Field, | ||
salt: Field, | ||
private_nullifier: Field, | ||
dg1: [u8; 95], | ||
// The country is public so verifiers can check | ||
// the country provided to the proof is correct | ||
// Danger: these public inputs are inconsistent with those of other disclosure circuits that I've looked at so far. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This circuit is no longer used since it can be done with the disclose circuit. So we'll discard it for clarity as part of a larger PR to clean unused code. |
||
// In particular, I suspect this is breaking the rigid ordering that is expected by the Outer circuit. | ||
// The outer circuit expects public inputs of disclosure proofs to be in the order: | ||
// - comm_in | ||
// - service_scope | ||
// - service_subscope | ||
// - param_commitment | ||
// - scoped_nullifier | ||
// | ||
// But this circuit has no `param_commitment`, and although the `country` could feasibly replace | ||
// that `param_commitment` field, it is in the wrong position, and it is a str<3> type, which I | ||
// presume is naively serialized into 3 distinct fields. | ||
// So how is this circuit's public inputs "shape" compatible with the Outer circuit? | ||
country: pub str<3>, | ||
service_scope: pub Field, | ||
service_subscope: pub Field, | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,5 +1,7 @@ | ||
use data_check_expiry::check_expiry; | ||
|
||
// Suggestion: Use DG1Data type | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This circuit is actually not used on its own. The expiry date is checked directly within the data integrity check circuit. So, this is a circuit that should be discarded as well |
||
// Question: How is this circuit used, and how does it fit in with all the other circuits? | ||
fn main(dg1: [u8; 95], current_date_timestamp: pub u64) { | ||
// Check the ID is not expired first | ||
check_expiry(dg1, current_date_timestamp); | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -5,6 +5,7 @@ use exclusion_check_sanctions::{ | |
}; | ||
use utils::PROOF_TYPE_SANCTIONS_EXCLUSION; | ||
|
||
|
||
fn main( | ||
comm_in: pub Field, | ||
salt: Field, | ||
|
@@ -15,6 +16,15 @@ fn main( | |
service_scope: pub Field, | ||
service_subscope: pub Field, | ||
) -> pub (Field, Field) { | ||
// So is the plan to always hard-code the root in the circuit, or to instead | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The plan is to have a non-hard-coded root that can be passed as inputs, as there will be multiple sanction lists, and they should be updated regularly. They will be managed similarly to other registries (i.e., certificates and circuits registries). For now, it was hard-coded to have a first working version before we can deploy the rest of the logic to make it dynamic |
||
// have the root be a public input (or committed into param_commitment) so that | ||
// the list can be more-easily updated onchain? | ||
// Iiuc, it might make more sense to not have a hard-coded root, and instead | ||
// instantiate this as: | ||
// `trees = SanctionsSparseMerkleTrees { root };` using the circuit private input `root`, | ||
// then checking that root within the Verifier. | ||
// Also "trees" (plural) is confusing, because it appears to be just one big tree, | ||
// which contains leaves that might represent one of three different concepts. | ||
let trees = SanctionsSparseMerkleTrees::default(); | ||
assert(trees.root() == root); | ||
// Check that nationality of the passport holder is not in the list of countries | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was a rather arbitrary choice. It can be changed to 512, which should be enough for most use cases