[noise] [EXT] Re: Multi party psk

[Jonathan Moore]

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}.


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)


Jonathan Moore, CTO

SpiderOak

415.425.5495

>ENCRYPT EVERYTHING


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

On Wed, Jun 7, 2017 at 10:00 PM, Jonathan Moore
<jmoore at spideroak-inc.com> wrote:
>
> Would it be safe to take a shared s and do an HKDF( s, pubkey_n ) = s_n to
> create a unique s for each sender in a multi party channel?


Hi Jonathan,

Interesting question!

(Small note on terminology: "s" isn't the best name here, because
Noise uses that for a static key pair or static public key.)

If a server has a master symmetric key and wants to derive a shared
PSK with clients based on HKDF or just HMAC(master_key, client_ID)
that seems fine.  Client_ID could be anything, including the client's
public key.

I guess this could be a way to authenticate clients without the server
having to store a database of all Client IDs?  For example, a pattern
like NKpsk2 could allow the client send its ID in the first payload,
and then the server mixes the derived PSK in when responding.


Trevor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20170607/82008c28/attachment.html>