-
Notifications
You must be signed in to change notification settings - Fork 162
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
Field-agnostic Fiat-Shamir Challenge Names #304
Comments
@gbotrel @ThomasPiellard |
So, to sum up state of things after your PR, we would have an arithmetic hash like MiMC that is supposed to take as input field elements, that would implement the following 2 interfaces; type ArithmeticHash interface {
WriteString(rawBytes []byte) error
} and from go std: type Hash interface {
// Write (via the embedded io.Writer interface) adds more data to the running hash.
// It never returns an error.
[io](https://pkg.go.dev/io).[Writer](https://pkg.go.dev/io#Writer)
// ...
} I think #265 introduced a bad decision; make Since it's cumbersome to add The piece we need to document well is; as a user, if I do: h.Write(0xAA)
h.Write(0xBB)
h.Write(0xCC) Caveat then, with what I proposed this is interpreted as 3 field elements (assuming q > CC). So if the user wanted to hash a single 0XAABBCC value, it's his responsability to bufferize on the calling side... |
another option is, for packages like |
I still think having two different Write functions, one for field elements and one for general strings is the way to go. So There are two difficulties with this:
Sorry if I'm repeating things @gbotrel or myself have already said. This is an attempt to sum (no pun intended) things up. |
Currently, in order to align hash inputs correctly, the user of a Fiat-Shamir transcript has to pad the challenge names so that they are as long as a hashing block. It is desirable for that to be done automatically,
It is better to pre-pad rather than post-pad with zeros to avoid the resulting block being "larger" than the field modulus. This will make
gnark/std/fiat-shamir.TestFiatShamir
pass (it currently fails.)304 addresses these issues, but introduces another:
gnark/std/commitments/fri.TestFriVerification
fails because a challenge name is too large. To solve this we must somehow pass a decompose function to the transcript object, such that for arithmetic hashes it operates as introduced in #265 and for traditional hashes it simply breaks them up into blocks. How to do this cleanly such thatTranscript
remains hash-agnostic andNewTranscript
doesn't get more complicated? I suggest instead of using the standard goHash
interface we use a wrapper that also has aDecompose
function.There are other failing
gnark
tests (withgnark-crypto@develop
) that this issue doesn't address:gnark/std/accumulator/merkle.TestVerify
gnark/std/commitments/fri.TestFriVerification
gnark/std/signature/eddsa.TestEddsa
The text was updated successfully, but these errors were encountered: