impl multiplication for polyval #55
Conversation
There was a problem hiding this comment.
Damn!! This is good work! It's a tricky algorithm. One thought is that his algo appears to be optimized for CPU execution, but I wonder if that maps over to snark efficiency.
Regardless, starting with a working algorithm seems like the right idea.
Added only one comment, I'll wait until the PR is out of draft for further review.
| // | ||
| // ref: https://github.com/RustCrypto/universal-hashes/blob/master/polyval/src/backend/soft64.rs#L151 | ||
| template MUL() { | ||
| signal input a[2][64]; |
There was a problem hiding this comment.
What's the intuition behind doing [2][64] vs [128]? Given each is represented as a field element internally, my hunch is we don't gain efficiency out of this (tho not certain) while having worse readability.
There was a problem hiding this comment.
maybe to use REV64()?
circuits/aes-gcm/component
Outdated
KaiGeffen
force-pushed
the
impl-polymul
branch
from
587ccd5 to
ec817c8
Compare
|
All gfmul tests should be logically passing, but I'm having issues getting circomkit to correctly recognize the out[2][64] outputs, seems to only be capturing 64 of the 128 bits, causing these tests to fail. Only thing left blocking this PR is figuring out that circomkit quirk and we're flying. @Autoparallel @0xJepsen @KaiGeffen would you take a look? Run I used https://github.com/thor314/universal-hashes to generate test vectors (see |
…ng 64 of 128 bits in out
thor314
force-pushed
the
impl-polymul
branch
from
60655d7 to
b11e9be
Compare
Closes #25.
Basing multiplication of the RustCrytpo software implementation. This PR is about halfway finished, implements
bmul64, and most of the main galoismulsubroutine.Still need to:
multhere's a broken test I wrote that isn't actually supposed to pass (and i have no test vectors for it yet; I might generate some from rust-crypto), but triggers circom's compiler errors, which has been useful (if painful).