[noise] SAS (was: Explicit nonces (for lossy transports)

[Rhys Weatherley]

On Wed, Jul 12, 2017 at 6:44 PM, Trevor Perrin <trevp at trevp.net> wrote:

>  (B) One party can just transmit a PSK to the other.  There's some
> subtlety in that you might want to "channel-bind" the PSK by hashing
> it with the handshake-hash, or using the handshake-hash as prologue
> when such a PSK is used for resumption, to prevent PSKs being relayed
> between sessions.  But I'm thinking that might be OK, and transmitting
> the PSK gives flexibility to send multiple PSKs, and works well with
> rekey (since PSKs sent before a rekey will be protected by the rekey).
>

My concern with transmitting the PSK's is that they are no longer "mutual"
- the sending party solely determines the value.  And if that party's
random number generator has become borked (e.g. accidentally or
deliberately outputting all-zeroes), then the PSK value is essentially in
the clear as the transmitted ciphertext.

What about this: modify Rekey() to return 64 bytes instead of 32.  The
first 32 are used as the new transport key, and the second 32 can be
exported from the protocol as a PSK if the protocol needs a PSK at that
point.  If the protocol requires multiple PSK's, it can Rekey() multiple
times before continuing with data transport.  Because the transport keys
are already determined using a mutual process, the PSK will be mutual also.

Cheers,

Rhys.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20170713/c4d10ff8/attachment.html>