[noise] SAS (was: Explicit nonces (for lossy transports)
rhys.weatherley at gmail.com
Wed Jul 12 15:20:07 PDT 2017
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Noise