feat: adaptable foldable AES circuit #47
Conversation
| ciphertext_input_was_zero_chunk[i] <== IsZero()(packedCiphertext[i]); | ||
| both_input_chunks_were_zero[i] <== plaintext_input_was_zero_chunk[i] * ciphertext_input_was_zero_chunk[i]; | ||
| ciphertext_option[i] <== (1 - both_input_chunks_were_zero[i]) * packedComputedCiphertext[i]; | ||
| ciphertext_equal_check[i] <== IsEqual()([packedCiphertext[i], ciphertext_option[i]]); |
There was a problem hiding this comment.
nice okay i see whats going on here. This is clever. Do we know how much perf it gives us? How many changes will this require downstream in the web-prover? Is it worth spending time on performance for aes when we know chacha20 is more performant over all?
There was a problem hiding this comment.
This is about allowing for doing less folds with AES which should boost performance especially in WASM. Every fold adds time, every fold adds memory pressure, and every fold makes compression slower.
Yes, we will likely move to chacha20, but it is never a bad idea to have a backup!
I don't believe it is sunk cost -- the PR is mostly done. It just needs a bit more review. Spending <1h or so of total review isn't asking much to get something that gives us flexibility. Likely won't be as high impact as ChaCha20, but it is not clear if we will have the TLS changes made in |
Idea
Basically, we want to be able to provide a padded plaintext input to our NIVC chain. There may be 242 bytes of plaintext, but we will pad to 512.
With previous work (a-la #45), we were able to run the AES circuit 16 times and not actually the full 32 needed to consume the padded ciphertext because when we hash plaintext data, we are doing so by ignoring full 16 byte chunks that are zero (as these indicate padding). Real plaintext won't have that (unless I'm mistaken -- in which case we should pad with -1 or 256 since real plaintext absolutely, certainly, cannot have that).
Now, what we also want to be able to do is potentially do 2 or more AES encryption chunks per fold. However, there is potentially some oddity that would happen in a case where the plaintext was, say 239 bytes and we were folding 2 AES encryption chunks at a time. Namely, it would encrypt the bytes 240-256 as a chunk, even those these are actually all zeros and only appear due to padding and trying to encrypt more than we need.
This PR
This PR solves this problem. We will default to checking that the encryption of plaintext in circuit matches the ciphertext private input chunk by chunk UNLESS both the plaintext and ciphertext chunks input at that point were zero. In that case, it bypasses this check and continues forward.
Furthermore, we selectively only hash the nonzero chunks just like the new DataHasher circuit from #45.
Reviewing
PLEASE BE CAREFUL REVIEWING THIS! This is a potential optimization we can use, but this does need some time to be carefully reviewed before I feel comfortable shipping it.
Closes #46