[noise] Reworking PSK usage

[Trevor Perrin]

On Tue, May 2, 2017 at 8:53 PM, Alex <alex at centromere.net> wrote:
>
> (A) Does the addition of this token allow the user to construct invalid
> handshakes? For example, what if the psk token is specified twice in a
> row? Is that valid?

That shouldn't harm anything.  I don't have a use for that but one
might come up later, so I don't see a reason to disallow that.


> (B) If multiple psk tokens are technically valid, how would you fit
> that in to the proposed naming scheme?

I would just accept that the naming scheme doesn't cover everything
possible, it just hits the most likely placements, and if someone
discovers a need for something different it can be named then.

(There's ways you could rearrange the current tokens we don't have
names for, either).


> (C) Where does the "psk" designation belong? For example, which one of
> these is correct?:
>
> * Noise_NNhfs+psk0
> * Noise_NNpsk0+hfs

Hm, I guess this becomes immediately relevant with "fallback" and
"psk?".  Maybe if the order of application doesn't matter, make it
alphabetical?  So, XXfallback+psk0?


> (D) I feel that the pattern naming is getting a tad clunky when you
> factor in transformations, the newly proposed psk token, etc. What do
> think of a naming scheme in which you serialize the entire handshake,
> hash it, and use that as the naming scheme? For example,

I see how that would eliminate ambiguity and eliminate the need for
naming discussions, because we'd be directly mapping a handshake
pattern to a name.

But that would also reduce legibility of the names, and make them
larger.  And thinking about patterns in terms of a base plus
modifiers/transformations seems helpful even apart from naming, so
it's not costing much to have a naming scheme.  So I guess I think the
current path of just stacking a few modifiers onto the base pattern
name should work pretty well.

Trevor