[noise] [EXT] Re: [EXT] Re: Multi party psk

[Jonathan Moore]

I think something else that would make the spec easier to understand is to state explicitly the randomization of symmetric crypto depends on a using a random ephemeral asymmetric key for setup. This is implied in many places but the exact relationship between the symmetric encryption randomization and the ephemeral key is not explicitly called out early in the spec.


In my, probably naive, reading this concept and the state chaining are the two core ideas in the crypto for noise.


Jonathan Moore, CTO

SpiderOak

415.425.5495

>ENCRYPT EVERYTHING


________________________________
From: Trevor Perrin <trevp at trevp.net>
Sent: Wednesday, June 7, 2017 5:08:10 PM
To: Jonathan Moore
Cc: noise at moderncrypto.org
Subject: [EXT] Re: [EXT] Re: [noise] Multi party psk

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20170608/cab53eab/attachment.html>