Add the basic interface and documentation for the sponge trait #2
Conversation
Will-Lin4
force-pushed
the
dev
branch
2 times, most recently
from
73d464c
to
52aae86
Compare
Absorbable is now sponge implementation independent and only requires conversion to a byte vector and a field element. The CryptographicSponge trait now supports outputting both bytes and field elements.
| /// The output depends on previous `absorb` and `squeeze` calls. | ||
| pub trait CryptographicSponge<F: Field> { | ||
| /// Initialize a new instance of the sponge. | ||
| fn new() -> Self; |
There was a problem hiding this comment.
Is the zexe ecosystem built with security parameter as a variable everywhere? I feel like it should be an input to new. (Or alternatively change new to something like clone or reset)
There was a problem hiding this comment.
My understanding is that one would write a PoseidonSponge that implements CryptographicSponge, and then have a
PoseidonSponge<F>::new() that generates the parameters for it, and gives you an instance of the object.
But you don't want to write a different PoseidonSponge for each security level. Or is the idea instead that you would make a parameter class, and then it'd be PoseidonSponge<F, params>::new()?
There was a problem hiding this comment.
I guess my question is, when would you not want 128-bit security?
There was a problem hiding this comment.
I feel like one may want to be shaving off the last few bits (or adding more in) depending on various circumstances.
Some cases that come to mind:
- You only need pre-image resistance, not collision resistance for certain things (e.g. blockchain addresses)
- You don't trust the papers analyses, so you use a higher security param
- You're already not at 128 bits of soundness due to other things. (Pretty common, ZCash Sapling was designed for 125 bits, later reduced to 122 due to Cheon's)
Also there are a lot of questions around what does 128 bit security mean for the sponge vs standard hashes / other parts of your system.
E.g. these arithmetic hash papers don't consider bit complexity per field op, so you feel safer lowering the last few bits of soundness, or you weight time/memory trade-offs differently, leading to different parameterizations.
There was a problem hiding this comment.
is the idea instead that you would make a parameter class, and then it'd be PoseidonSponge<F, params>::new()?
I think this approach makes sense, no?
There was a problem hiding this comment.
On further thought, I completely agree.
There was a problem hiding this comment.
This looks good to me. I filed #3 to deal with the question brought up by @ValarDragon. Let's get this initial design merged, and then we can use it in our crates to see any issues that arise.
Sounds good. I will merge it in. |
No description provided.