[noise] Stricter rules #2: PSKs fixed to 256 bits

[Alex]

On Thu, 21 Apr 2016 21:25:16 -0700
Trevor Perrin <trevp at trevp.net> wrote:

> A PSK that the server encrypts to itself, using some
> ticket-encryption key.  The server gives the ticket to the client,
> and when the client reconnects later, it presents the ticket, then
> uses the PSK.
> 
> This is an idea from TLS, to do resumption without server-side state
> (session caches).
> 
> To do session tickets or session cache resumption in Noise, the
> server would have to give the client a (PSK, session ticket) or (PSK,
> session ID) over an existing Noise protocol.
> 
> Then when the client reconnects later, the client would have to send
> a session ticket or session ID, followed by an initial NoisePSK_??
> protocol message.
> 
> The client could do something like NoisePSK_NN to add
> forward-secrecy, or even do a full handshake like NoisePSK_XX.  So
> this is another way to do zero-RTT encryption, instead of encrypting
> the first message to the server's static or semiephemeral key
> (though you could also combine all these things; there's a a lot of
> options here).
> 
> Anyways, relevance is that PSK is more suited to things like this,
> where you're storing and then reusing a strong key, then passwords
> that might be low-entropy.
> 

Thank you for that explanation. I realize that session tickets are
slightly tangential to your original email, but I'm interested in
higher-level use cases like this because I want to make sure that the
cacophony API provides the right primitives to allow them to happen.

I've modified the echo programs so that they use a base64 encoded PSK
file as opposed to having it specified on the command line as an ASCII
string.

Per Rhys's suggestion off-list, I also modified the echo protocol so
that the prologue is equal to the 5 header bytes (which negotiate
the handshake parameters) so as to prevent a MITM attack.

-- 
Alex