[noise] Reworking PSK usage

[Trevor Perrin]

On Wed, May 3, 2017 at 4:45 PM, Alex <alex at centromere.net> wrote:
> On Tue, 2 May 2017 21:17:07 +0000
> Trevor Perrin <trevp at trevp.net> wrote:
>
>> On Tue, May 2, 2017 at 8:53 PM, Alex <alex at centromere.net> wrote:
>> > (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?
>>
>
> The order of application does matter, at least when it comes to
> transformations.

In some cases yes, in some cases no.

You're right that it would matter in the XXfallback+psk0 case.  Using
the rev32 notation, and the proposal of psk0 inserting "psk" after
"e":

XX:
-> e
<- e, ee, s, es
-> s, se

XXfallback:
-> e
...
<- e, ee, s, es
-> s, se

XXfallback+psk0:
-> e
...
<- e, psk, ee, s, es
-> s, se

XXpsk0+fallback: (???)
-> e, psk
...
<- e, ee, s, es
-> s, se

It would also matter in the hfs and psk0 case, since both put the new
token ("f" or "psk") after "e":

XXhfs_psk0(s, rs):
  -> e, psk, f
  <- e, f, ee, ff, s, es
  -> s, se

XXpsk0_hfs(s, rs):
  -> e, f, psk
  <- e, f, ee, ff, s, es
  -> s, se

This all seems complicated, because the psk0 location is interacting
with fallback and hfs.

Maybe there's a better way to handle "psk0"?  One option is that psk0
would NOT insert a token, and just would process the PSK before the
patterns, similar to current behavior.  That means it's a special
case, but also means there's less interactions like above to worry
about.

Thoughts?

Trevor