[noise] rev32b (Release Candidate)

[Trevor Perrin]

On Sat, May 13, 2017 at 5:21 PM, Alex <alex at centromere.net> wrote:
>
> The `psk` token unlike all other tokens: It is parameterized. There is
> no way for a Noise library to know ahead of time what the value will
> be.

In a general-purpose library I think "psk" tokens should probably be
handled by a callback (psk0 is perhaps an exception to this, if the
library wants to provide a different/simpler API for just setting the
psk0 explicitly).

That's different from existing tokens, but seems OK to me - callbacks
are not uncommon if you look at, say, TLS APIs.


> In an ideal general purpose Noise library, would you expect the end-user
> to write the handshake pattern themselves, with their
> application-specific logic (e.g. lookup_psk_in_database) woven in? Or,
> would you want to have the library provide a set of pre-packaged
> off-the-shelf handshake patterns, and users will only very rarely
> define their own?
>
> My goal is to have cacophony be "idiot proof" -- it should be difficult
> to shoot yourself in the foot.

I wouldn't expect "application-specific logic" to be considered part
of the pattern.

It's a good question how general-purpose libraries should handle the
combinatorics of pattern modifiers.  For example, should a library
hardcode all the patterns listed in this (and future) specs, or should
it only hardcode the base patterns (XX, IK, etc), and then apply
user-specified modifiers?

Assuming we continue down the road towards more modifiers ("noidh",
"hfs", "sig", "fallback" used more generically, etc), then the latter
approach might be more scalable.  However, it raises the issue of
detecting invalid patterns, so that users don't shoot themselves in
the foot with bad combinations of modifiers.

At the moment, applying the pskN modifier to any base pattern produces
a valid pattern, and so it's reasonable for libraries to just
calculate this modification.

We can hope simple statements like that continue to be true, as we add
more modifiers, but I don't think we really know.


Trevor