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

[Trevor Perrin]

On Thu, Apr 21, 2016 at 9:11 PM, Alex <alex at centromere.net> wrote:
> On Thu, 21 Apr 2016 14:56:08 -0700
> Trevor Perrin <trevp at trevp.net> wrote:
>
>> The payload is encrypted/authenticated by a PSK.  That's good, because
>> the PSK can be used to accomplish 0-RTT encryption with session
>> tickets or caches, but it means a low-entropy PSK is exposed to
>> offline guessing attacks.
>>
>
> Could you expand on how that would be accomplished? What exactly is a
> session ticket and how would it be used?


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.

Trevor