Split permutation from sponge construction

[hdevalence]

Summary

I think it would be useful to split the current API into two parts, a lower-level part with access to the "raw" permutation, and a higher-level part with a sponge or other duplex construction.

Problem Definition

Currently, it's not possible for API clients to use the permutation directly, only via the provided sponge construction. This presents some difficulties:

• For fixed-size hashing, users have to figure out how to specify the hashing behavior they want in terms of the duplex operations, instead of being able to write it directly. This makes it more likely that the code will include some behavior accidentally derived from the initial implementation choice.

• It's not possible for users to implement any other duplex modes than what's already provided, or to implement duplex behavior that's differently specified than the provided one. For instance, the current implementation puts the capacity at the end of the state, but other instantiations of Poseidon hashing, like the C2SP proposal Poseidon sponge construction C2SP/C2SP#3 , put it at the beginning.

Proposal

Rework the current structures as follows:

PoseidonParameters: remains unchanged.¹

PoseidonSpongeState: renamed to PoseidonState, and redefined as

pub struct PoseidonState<F: PrimeField> {
    pub state: Vec<F>,
    pub params: PoseidonParameters<F>,
}

In other words, the state structure includes the field elements in the state, as well as the parameters needed to run the permutation. The permute function is moved to a pub fn permute(&mut self) on PoseidonState.

PoseidonSponge: redefined as

pub struct PoseidonSponge<F: PrimeField> {
    pub state: PoseidonState<F> ,
    pub mode: DuplexSpongeMode,
}

In other words, the sponge structure consists of a state, together with the extra data tracking how that state is being used to implement a higher-level duplex construction.

This allows providing two levels of API: a lower-level API that provides precise control over the permutation, and a higher-level API that provides a duplex or other construction. Users who want to have more "batteries included" functionality can use the higher-level construction, but it's possible to implement other constructions using the lower-level API.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

Footnotes

1. the doc comment about "and RNG used" should be eliminated, correct? I don't see any use of an RNG in the public API. ↩