[noise] rev32b (Release Candidate)

[Jason A. Donenfeld]

On Sat, May 13, 2017 at 7:21 PM, Alex <alex at centromere.net> wrote:
> Noise_IKpsk1(s, rs):
>    <- s
>    ...
>    -> e, es, s, ss, psk(lookup_psk_in_database(s.public_key))
>    <- e, ee, se

I guess you could do this? But you don't have to. Like all other
tokens, the source of its required data could come from any number of
sources. Different libraries will be useful in different ways, so
whatever floats your boat seems fine in this regard.

> 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.

That's really not true. It's the same type semantically as any other
token. A particular static key, for example, could be dependent on
something like the source IP address, or other framing. However, in
most circumstances, you simply tell the particular "instance" of Noise
what keys will be used for different points of a handshake.

> 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?

A library should probably provide pre-packaged off-the-shelf handshake
patterns, which is why Trevor has taken the pains to document and name
several useful ones.

> My goal is to have cacophony be "idiot proof" -- it should be difficult
> to shoot yourself in the foot. It is not clear to me how to meet this
> goal while also making the library flexible enough to support
> parameterized tokens like `psk`.

`psk` is not a necessarily parameterized token. You could choose to
implement it this way, just like all the other tokens -- which could
be parameterized on _something_ -- but you could also choose to
implement it a simpler way.

>From my own personal experience working on three different Noise
libraries, this is _not_ a hard thing to implement. But if you'd like
to complicate it with various complicated lookup semantics, then I
guess you can do that if you want?

> What if the user wants to add their own Noise extension that introduces
> a new token? Will they be required to fork your library, or would there
> be an interface for adding new tokens? How would the code that applies
> user-specified modifications take in to account user-specified
> extensions?

I think what you should do is take things incrementally. If an actual
use arises where something odd and complicated is needed, then you'll
look into it at that time. There is _always_ some direction you could
go in that requires an additional abstraction. I think there are even
theorems from programming language theory that demonstrate this sort
of thing. The goal in writing a library is to provide APIs that are
simple and sane, while enabling future growth as needed. As a decent
example of this, the Qt library is commonly cited as a good example of
rigorous library API design. Not too abstracted, not too constrained.
But in any case, these decisions are up to you. And again, from my own
experience working on this, there are some really straight forward
ways of implementing this.

> For instance, how do you communicate to a library your intention to add
> a `foo` token right before the `bar` token in the second message
> pattern of some arbitrary handshake? That sounds like a very complex
> API.

I'd encourage you to use Trevor's set of predefined and named handshakes.

> I think I may have no choice but to have the user to write their own
> handshake patterns. Ideally a Noise library would perform static
> analysis on the handshake pattern before even starting, as opposed to
> waiting until some assertion is violated half way through a handshake.

I think you certainly have many choices that aren't that. It's fairly
clear that you've _wanted_ to go in this direction for a while though,
based on some other very interesting suggestions here about making
handshake patterns a hash of some descriptive string, and so forth.
But I believe Trevor made the call early on to stick with predefined
named handshakes. Those certainly make the security analysis more
straightforward. So, erm, you definitely do have plenty of different
sane ways of writing your library. I guess that's what makes
programming fun?