[noise] Reworking PSK usage
trevp at trevp.net
Tue May 2 14:17:07 PDT 2017
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.
More information about the Noise