[noise] [EXT] Re: Multi party psk

[Trevor Perrin]

On Wed, Jun 7, 2017 at 11:51 PM, Jonathan Moore
<jmoore at spideroak-inc.com> wrote:
> After thinking longer about it, and re-reading the psk section of the spec,
> I realized I don't understand the intended usage of psk(s). My thought was
> "It is a way to skip the key agreement and go right to the session" but
> given that it still uses an ephemeral key (instead of a nonce) to generate a
> unique ck, I don't know why I would use it over Noise_{K,X}.

Yeah, we should say more about PSK rationale.

PSKs are intended to provide "additive" security to a handshake, so
they get used in combination with DH.  WireGuard is using them mainly
for post-quantum properties:  A quantum computer might break your EC,
but if you have a PSK it probably can't break that.

Another use could be when resuming a session, where a PSK derived from
an earlier session protects the zero-RTT data which is exchanged
before the public-key handshake completes.  Or, the new handshake
might just do an unauthenticated Noise_NN to get forward-secrecy for
the new session, but rely on the PSK to extend the earlier session's
authentication.

But you're right that you don't need it in many / most cases.


> My use case is that I have a multi party chat, Semaphor, that uses a shared
> symmetric channel key. Right now we use a home grown protocol build on top
> of libsodium but I am hoping that we can switch to noise. I would actually
> like to switch to shared public channel key ( all parties know the private
> key ) but I am concerned with decryption time when back filling history.
> (Under the assumption that some phones can only handle ~1k DH operations/s)

Sounds like a lot going on here!  So I couldn't say from that
description whether Noise is a good fit.


Trevor