feat: multiple plaintext authentication #91
Conversation
lonerapier
changed the title
|
Can you make an updated diagram for this version? |
| signal part_ciphertext_digest <== DataHasher(DATA_BYTES)(bigEndianCiphertext); | ||
| signal plaintext_digest <== PolynomialDigestWithCounter(DATA_BYTES)(zeroed_plaintext, ciphertext_digest, plaintext_index_counter); | ||
|
|
||
| step_out[0] <== step_in[0] - part_ciphertext_digest + plaintext_digest; |
There was a problem hiding this comment.
Do we need to write out the counter so that we use the correct counter in the next iteration?
There was a problem hiding this comment.
Furthermore, we also need to assert the first time around the counter is 0
There was a problem hiding this comment.
Perhaps this is captured by the fact the whole PT digest needs to match? My only argument against this is without also verifying the counter, someone could be mischevious and clever with plaintext chunks
There was a problem hiding this comment.
yeah, you're right. should we add another public input?
also should i add it here in this PR, or create an issue and tackle with arbitrary data size proofs?
There was a problem hiding this comment.
Is this resolved now then? Seems like it.
There was a problem hiding this comment.
nope, it's not. have to add a counter hash.
| @@ -0,0 +1,13 @@ | |||
| pragma circom 2.1.9; | |||
|
|
|||
| function log2Ceil(a) { | |||
There was a problem hiding this comment.
I think this could be used in the JSON parser/machine. I have a comment about it in there actually.
lonerapier
force-pushed
the
feat/multiple-plaintext-authentication
branch
from
5b1ac19 to
53d33e1
Compare
| @@ -1,7 +1,7 @@ | |||
| { | |||
| "name": "web-prover-circuits", | |||
| "description": "ZK Circuits for WebProofs", | |||
| "version": "0.7.3", | |||
| "version": "0.7.4", | |||
There was a problem hiding this comment.
The API for these circuits is changing. I still think this should be 0.8.0
| signal part_ciphertext_digest <== DataHasher(DATA_BYTES)(bigEndianCiphertext); | ||
| signal plaintext_digest <== PolynomialDigestWithCounter(DATA_BYTES)(zeroed_plaintext, ciphertext_digest, plaintext_index_counter); | ||
|
|
||
| step_out[0] <== step_in[0] - part_ciphertext_digest + plaintext_digest; |
There was a problem hiding this comment.
Is this resolved now then? Seems like it.
| @@ -118,5 +117,5 @@ template HTTPVerification(DATA_BYTES, MAX_NUMBER_OF_HEADERS) { | |||
| accumulated_main_digests_hashed += main_digests_hashed[i]; | |||
| } | |||
|
|
|||
| step_out[0] <== step_in[0] + body_digest_hashed - accumulated_main_digests_hashed - data_digest_hashed; // TODO: data_digest is really plaintext_digest from before, consider changing names | |||
| step_out[0] <== step_in[0] + body_digest_hashed - accumulated_main_digests_hashed - pt_digest; | |||
There was a problem hiding this comment.
Need to hash pt_digest?
There was a problem hiding this comment.
yeah, i had thought about that, but then how do we calculate pt_digest_hash in authentication circuit?
my reasoning to just use digest and not hash was because all others were hashes, so you'd still have to find preimage of those to cancel these?
There was a problem hiding this comment.
ah, because of the different components...
Okay, I see.
Can you please make some issues on some of these potential security problems like this we're introducing? Then I'm good to sign off on this..
|
high level review lgtm, I'll defer to colin for deeper comments. |
closes #89
closes #80