[noise] Spec revision 32

[Trevor Perrin]

On Fri, May 19, 2017 at 12:14 PM, Alex <alex at centromere.net> wrote:
> On Wed, 17 May 2017 18:22:56 +0000
> Trevor Perrin <trevp at trevp.net> wrote:
>
>>  * PSK support was changed to allow PSKs to be added at different
>> points in the handshake.  This is incompatible with all previous PSK
>> handshakes, which are replaced with new ones, using a new naming
>> scheme.
>>
>
> In section 9.2:
>
> "In non-PSK handshakes, the "e" token in a pre-message pattern or
> message pattern always results in a call to MixHash(e.public_key). In a
> PSK handshake, all of these calls are followed by MixKey(e.public_key).
> In conjunction with the validity rule in the next section, this ensures
> that PSK-based encryption uses encryption keys that are randomized
> using ephemeral public keys as nonces."
>
> What this implies is that a general purpose Noise library simply can't
> execute the instructions sequentially. You have to scan the entire
> pattern, determine if there are any `psk` tokens, and then change the
> *meaning* of the `e` token if you find any. Is this correct?


The library has to know in advance whether PSKs are being used, that's true.

Whether this knowledge comes from the pattern name, or is explicitly
specified by the caller (e.g. a psk=True argument), or is based on
scanning the pattern, I guess is a question of API design.

As you've mentioned, if you're accepting arbitrary patterns from the
user, it's probably a good idea to scan them for validity, so the
library would notice the PSK token at that point.

So I'm not seeing a practical problem, or a much better alternative.
We could discuss adding a "mixkeye" token after each "e" to be more
explicit about this, but to me that looks messier and not really worth
the effort.


Trevor