Document that the default U for DuplexSponge is u8

[mmaker]

https://github.com/arkworks-rs/spongefish/blob/ccf88e9bdcb3ee3cc5833a2e9d979adf75e53a3c/spongefish/src/duplex_sponge/interface.rs#L4C47-L4C49

[z-tech]

Since DuplexSpongeInterface defaults U = u8, I thought both DuplexSpongeInterface and DuplexSpongeInterface<u8> would be valid type arguments as long I feed the sponge bytes. In other words, it sort of gave the impression that it abstracted over the CRH to handle field/byte conversion internally.

In practice, it seems U needs to match the CRHScheme input exactly. So for Poseidon, you have to override U = F here, and feed in &[F] here.

If it's correct that U always depends on the internal CRH input, maybe U doesn't need to be configurable?

[mmaker]

Hey @z-tech ! Thanks for reaching out.
I don't have access to compsec-epfl/warp, but let me summarize what I think I understood from your message.

DuplexSpongeInterface has a type parameter U that describes where the hash function operates on.
Reading the documentation, you found it misleading and are asking why is it there if it's part of the hash function definition.
A duplex interface can be implemented it in two ways:

1. The currrent way

trait DuplexSpongeInterface<U: Unit> {
}

2. A more implicit way

trait DuplexSpongeInterface { 
  type U: Unit;
}

Are you suggesting to go for 2 instead of 1?

[z-tech]

Oh right, my bad re: permissions 🙈. I added you in case helpful.

I don't have an opinion between 1 & 2 above, but what you summarized is correct:

1. Communicating that U must match CRHScheme::Input / Output for this to compile would be v helpful

2. Since U must match CRHScheme::Input anyway... idk is it more clear that DuplexSpongeInterface take an H: CRHScheme type parameter from which you can pluck H::Input / Output instead of U ?

^ 1 from above would be v helpful. Maybe 2 from above adds some complexity I don't see but just wanted to mention because it took some debugging.

[mmaker]

Option 1 is the one we currently implement.

I've been trying to do option 2 for many weeks, but without success.
When you start writing something like VerfierState<DuplexSponge> has trait bound DuplexSponge::U= u8, then the Rust type system starts falling apart and complaining. This is why I excluded it. I don't have unfortunately a minimal example to show right now, but if you were able to show a way to implement this it'd be great (I just don't think this was not possible in Rust 1 year ago).

[mmaker]

@z-tech any leads here?

[z-tech]

Still looking into it

[z-tech]

Did you consider this?

pub trait DuplexSpongeInterface<H>: Default + Clone + zeroize::Zeroize
where
    H: CRHScheme, // No need to specify CRHScheme<Input = [F], Output = F> etc here in the trait it can be done later in the impl
{

    /// Initializes a new sponge, setting up the state.
    fn new(iv: [u8; 32]) -> Self;

    /// Absorbs new elements in the sponge.
    fn absorb_unchecked(&mut self, input: &H::Input) -> &mut Self;

    /// Squeezes out new elements.
    fn squeeze_unchecked(&mut self, output: &mut H::Output) -> &mut Self;

    /// Ratcheting.
    ///
    /// This operations makes sure that different elements are processed in different blocks.
    /// Right now, this is done by:
    /// - permuting the state.
    /// - zero rate elements.
    /// This has the effect that state holds no information about the elements absorbed so far.
    /// The resulting state is compressed.
    fn ratchet_unchecked(&mut self) -> &mut Self;

    // /// Exports the hash state, allowing for preprocessing.
    // ///
    // /// This function can be used for duplicating the state of the sponge,
    // /// but is limited to exporting the state in a way that is compatible
    // /// with the `load` function.
    // fn tag(self) -> &'static [Self::U];
}

One question I have is if you will ever write an impl of DuplexSpongeInterface without a CRHScheme? If not, should be fine as a type parameter no? I imagine this could be worked through the layers okay.

My goal with this suggestion is that doing it this way the user need only define H::Input and H::Output one time. Then DuplexSpongeInterface takes that one definition from the CRHScheme and the user can't make a mistake about having mismatching definitions. This is more clear than before where the user needs to define both H::Input and H::Output and also define a matching U in DuplexSpongeInterface.

[mmaker]

Why would it be a type parameter and not implemented by the type itself? that seems a bit overkill. which struct would implement it? About input and output: do you know of any hash function that has inputs different from outputs?

[z-tech]

What you're calling "unit" may be the same but there are slight differences in the input/ output types yes.

• For Poseidon impl the default input is [F] and the default output is F (not slice).
• For sha256 impl the default input is [u8] and the default output is Vec<u8> (again not slice)

Those types are configurable, but the user will have to configure them rather than them just getting soaked up as defaults.

re: overkill
I guess it depends on what you're going for? If the direction is to decouple from arkworks conventions then the dependency on CRHScheme may be overkill. Another way to look at it though is that if we assume DuplexSpongeInterface is getting used with other arkworks stuff like CRHScheme then maybe it's this layer of abstraction with U: Unit that's overkill?