[noise] rev32b (Release Candidate)

[Alex]

On Sat, 13 May 2017 17:09:26 +0000
Trevor Perrin <trevp at trevp.net> wrote:

> On Sat, May 13, 2017 at 1:09 AM, Alex <alex at centromere.net> wrote:
> > On Thu, 11 May 2017 18:27:49 +0000
> > Trevor Perrin <trevp at trevp.net> wrote:
> >  
> >> The new design provides PSK flexibility with a "psk" token, and
> >> uses a naming scheme that fits with the "modifier" syntax we
> >> currently use for "fallback", and have discussed using for
> >> signatures ("sig"), post-quantum ("hfs"), and other pattern
> >> transformations ("noidh", others).
> >>  
> >
> > Does the following accurately describe your intention behind the
> > `psk` token?:
> >
> > Noise_IKpsk1(s, rs):
> >    <- s
> >    ...  
> >    -> e, es, s, ss, psk(lookup_psk_in_database(s.public_key))  
> >    <- e, ee, se  
> 
> 
> That's one way it could be used.
> 
> If you use psk2 instead of psk1 the responder can defer the lookup
> until after decrypting the first payload, which could help DoS
> resistance (e.g. allowing the responder to check a payload timestamp
> and discard old replays before looking up the PSK, which I think is
> the WireGuard rationale), or the responder could use something in the
> payload (e.g. a username) to lookup the PSK.
> 

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 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. It is not clear to me how to meet this
goal while also making the library flexible enough to support
parameterized tokens like `psk`.

-- 
Alex