[noise] Stateful Hash Object Proposal

[Peter Schwabe]

Trevor Perrin <trevp at trevp.net> wrote:

Dear Trevor, dear all,

Sorry for my slow reply!

> > > OK, would you prefer Absorb(separator), then Ratchet()?
> >
> > I would prefer
> >
> >   PRF = SHO("P")
> >   PRF.Absorb(...)
> >   PRF.Sqeeze(...)
> >
> >   XOF = SHO("X")
> >   XOF.Absorb(...)
> >   XOF .Sqeeze(...)
> 
> OK, that's a nice API.  My concern was that there's two ways to do
> domain separation:
> 
>  (A) Prepend the separator *without* block padding (minimizes input size).
> 
>  (B) Prepend the separator *with* block padding (makes it easier to
> store the "IV" after processing the domain-separator).

But this is something that can be solved differently for different hash
functions inside the implementation of the hash object (where, in my
opinion, it should be solved). 

> I think we could support both:
> 
> Allow a SHO to be constructed with or without a "customization string"
> (which may be zero-length).
> 
> The SHO algorithm might have special support for a customization
> string (e.g. cSHAKE's customization string or maybe using the
> customization string as HKDF salt in an HKDF SHO).  If the SHO does
> *not* have special support for a customization string, then just call
> Absorb(customization) followed by Ratchet().

I think that for every implementation of the SHO you want to have
support for a domain-separation (or customization) string. If internally
this string is simply absorbed without padding, that's fine, but in the
calling code it's still clear that it's a domain-separation string and
whoever is using the SHO does not need to care about how exactly the
internals work for different hash functions.

> This design would NOT guarantee that a customized SHO will be
> domain-separated from a non-customized SHO, since the non-customized
> object might Absorb an initial input that collides with some
> customization string, but I tentatively think that's better than
> requiring an extra field be always present just to differentiate the
> customized / non-customized cases, since that complicates the simple
> use of a non-customized SHO.
> 
> This would support the API you prefer, but someone trying to squeeze
> things into the fewest hash blocks could also do:
> 
>   PRF = SHO()
>   PRF.Absorb("P" || ...)
>   PRF.Sqeeze(...)
> 
>   XOF = SHO()
>   XOF.Absorb("X" || ...)
>   XOF .Sqeeze(...)

Yes, with the API I suggested this would be possible, but then the
caller is responsible for making sure that this is actually secure,
whereas when passing the customization string as an argument to the
constructor it's the responsibility of the SHO object.
 
> > > For SHAKE, Ratchet() would run the permutation and then zeroize the
> > > sponge "rate".   So effectively, the sponge's "capacity" of 32 or 64
> > > bytes just becomes a different constant for Kyber's XOF, PRF, G, and
> > > H.
> >
> > > For SHA256, Ratchet() would just zero-pad to the next block boundary
> > > and run the compression function, which could also be treated as
> > > different IVs for Kyber's XOF, PRF, G, and H.
> >
> > I wouldn't expose Ratched() as a method on the SHO, but handle
> > ratcheting internally.
> 
> Ratchet() is useful in a protocol like Noise which is going to use a
> single SHO over some period of time, and wants to periodically ratchet
> it for forward-secrecy, and perhaps to reduce the amount of state
> stored between handling each message (since after Ratchet() the "rate"
> would be erased, so doesn't need to be stored).
> 
> But Noise also wants to efficiently/incrementally call Absorb(), so we
> don't want the cost of ratcheting for each Absorb().

I understand the first reason, but not so much the second one. The SHO
can easily keep track of how many more bytes can be absorbed before it
has to ratchet; that's quite standard in incremental hash APIs.

> So I think Ratchet() makes sense in the SHO API.  But for your case (a
> PQ algorithm at a single point in time), you wouldn't need it.

Cheers,

Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20181218/f0842d7e/attachment.sig>