[noise] Stateful Hash Object Proposal

[Trevor Perrin]

On Sun, Nov 25, 2018 at 9:06 AM Nadim Kobeissi <nadim at symbolic.software> wrote:
>
> I think that it would be better to make SHOs the only way in which hashing works in Noise. This is because:
>     1. SHOs are not much more complex than the original hashing API.
>     2. Most modern programming languages already offer a stateful hashing API (Node.js, Golang, C, you name it.)
>     3. The added complexity to the Noise language will be much greater if both SHO and regular hashing were to be supported, for no real benefit.

I consider the core spec stable (won't break or remove things) apart
from the recent deferred patterns.

So we definitely wouldn't remove the existing KDF/hashing, that's been
unchanged since 2015 I think, widely implemented, uses conservative
and familiar constructs, etc.


> But in general, I have a bad gut feeling not just about SHOs but about the push for extensions and complications generally.

I think we have a great set of extension ideas, myself.  We've also
spent a lot of effort on a clean framework that lends itself to
extensibility, so it would be a shame not to put it to use, IMO.

Implementers will use specific Noise protocols, so enlarging the
universe of possible Noise protocols just makes it more useful, it
doesn't bloat the actual code or on-the-wire protocol people end up
using.

And it's not like Noise has taken over the world yet, there's still
lots of things people want for protocols like this which we don't do
(PQ, sigs, PAKE, simpler hashing, PSK resumption, negotiation, and so
on).

Trevor