Comments (4)
Indeed, making it parametric is an option, but I think it would still be a bit confusing. We have actually stumbled a few times when hashing from bytes to fr.Element
inside MiMC, for example in cases when input byte slice overflows fr.Element
.
My proposal has been to instead implement a new hash interface which takes as an input fr.Element
(see #448), but the problem with the approach is that we would have to have separate interfaces for every supported field or use type parameters (which has been shown to be slow and may not be most intuitive). Then, it would be up to the user to perform the hashing from bytes to fr.Element
(for example by using hash-to-field) in a most convenient way.
But until that as a workaround having either optional endianness or different MiMC constructor seems reasonable. cc @ThomasPiellard and @gbotrel, what do you think?
from gnark-crypto.
Indeed, making it parametric is an option, but I think it would still be a bit confusing. We have actually stumbled a few times when hashing from bytes to
fr.Element
inside MiMC, for example in cases when input byte slice overflowsfr.Element
.My proposal has been to instead implement a new hash interface which takes as an input
fr.Element
(see #448), but the problem with the approach is that we would have to have separate interfaces for every supported field or use type parameters (which has been shown to be slow and may not be most intuitive). Then, it would be up to the user to perform the hashing from bytes tofr.Element
(for example by using hash-to-field) in a most convenient way.But until that as a workaround having either optional endianness or different MiMC constructor seems reasonable. cc @ThomasPiellard and @gbotrel, what do you think?
Also random question regarding this: would it be cryptographically insecure to consider MiMC as a 253bit (avoid the modulus) block-cipher hash function? If not we could have a sha2-like interface ingesting arbitrary bytes?
from gnark-crypto.
Technically we can do both -- for the "hash interface that takes bytes", add in the constructor an option (retro compatible change) with an enum big / little endian.
And if one days it comes to it that doesn't prevent us from doing #448 .
from gnark-crypto.
Also random question regarding this: would it be cryptographically insecure to consider MiMC as a 253bit (avoid the modulus) block-cipher hash function? If not we could have a sha2-like interface ingesting arbitrary bytes?
It should indeed be a secure cryptographic hash function. The issue it is not usually used outside of circuits is that it is quite slow. But in circuit due to the algebraic nature it is better than SHA2.
The problem with current interface (that MiMC implements hash.Hash
i.e. ingests bytes) is that we have to split the input into log(q) bit partitions, construct individual fr.Element from the partitions and then run MiMC. But the individual partitions could overflows the field. So, we would rather have to represent the input byte slice as base q big integer, but this is very memory-expensive when the inputs are a few MBs.
from gnark-crypto.
Related Issues (20)
- How to call mimc to input a string and output the mimc hashed result? HOT 1
- feat: define and implement field hasher implement for snark-friendly hash functions HOT 1
- Optimize BW6 final exponentiation
- What's the rationale for methods returning pointers in the ecc packages? HOT 3
- bug: invalid marshalling found by fuzzer HOT 2
- iop.Polynomial.Evaluate should work in Lagrange/Lagrange shifted form
- refactor: make applying domain separation optional in Fiat-Shamir Transcript HOT 1
- bug: When dynamic linking, R15 may be clobbered by a global variable access HOT 7
- bug: possibly incorrect `DST_prime` in `ExpandMsgXmd` HOT 6
- Docu: Merkle tree documentation outdated or hashing of nodes in is incorrect
- Add SetElement to fptower.E2 HOT 2
- BLS12-381 G1 Subgroup checks are slow HOT 7
- feat: MIMC security considerations HOT 2
- Optimize Legendre symbol
- Generator of Fr*
- feat: Implement Poseidon hash
- 📦 `github.com/consensys/gnark-crypto/ecc` HOT 1
- bug: MiMC Write() violates hash.Hash expectations. HOT 5
- feat: add MustSetRandom methods
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gnark-crypto.