[noise] rev32b (Release Candidate)

[Alex]

On Sun, 14 May 2017 01:40:08 +0200
"Jason A. Donenfeld" <Jason at zx2c4.com> wrote:

> On Sun, May 14, 2017 at 1:24 AM, Alex <alex at centromere.net> wrote:
> > The psk changes in rev32b alone require large breaking API changes
> > because my abstractions are based on the assumption that *all*
> > handshake parameters (such as the psk from previous revisions, as
> > well as the ephemeral key) are known to the library before the
> > handshake begins. As a result, the entire handshake can be thought
> > of as a "pure computation" whose output is solely dependent on its
> > input. But if the application can arbitrarily choose a psk half-way
> > through the computation, all purity is lost.  
> 
> These seems to be the crux of the problem you're facing. I think I
> understand the outcry now.
> 
> You can either continue to treat PSKs that way -- known ahead of time
> -- or you can work on making your library logic more flexible for more
> interesting uses. If you think your future users will want the latter,
> do that. If you think your future users will only ever need the
> former, stick with what you currently have.
> 

Right. Balancing flexibility with safety is my dilemma.

> Anyway, it sounds to me like you're feeling that there will be
> interesting programming challenges and design challenges associated
> with these recent changes. That's okay. I don't think these are
> unreasonable things to ask of an API, and there are a variety of ways
> to support it.
> 

To be clear, being able to choose a PSK based on a static identity
received during the handshake is useful, and I think Noise should
support it. My main concern with the implementation details.

-- 
Alex