On Fri, Jul 16, 2021 at 5:31 AM Ian Goldberg iang@uwaterloo.ca wrote:
On Tue, Jul 13, 2021 at 11:34:47AM -0700, Trevor Perrin wrote:
You also wanted to add an (optional) pre-shared key, which Noise supports:
NKpsk0: <- s ... -> psk, e, es <- e, ee
Out of curiosity, Trevor, what properties does this Noise protocol provide for low-entropy psk?
The Noise PSK is intended for 256-bit secrets, however:
* A low-entropy (even malicious) PSK can't reduce the security of the rest of the handshake. I.e. NKpsk0 with a bad PSK has all the security properties of NK.
* The handshake will only complete successfully if both parties use the same PSK.
This is *NOT* a PAKE: the legitimate recipient of the first NKpsk0 handshake message will be able to try offline guesses for the PSK.
Noise doesn't have a PAKE feature. You could generically combine a Noise handshake with an Oblivious PRF to produce a PAKE (like Hugo's OPAQUE). Integrating a "balanced" PAKE, like in OTR, would be more complicated.
If you want the protocol to work with Walking Onions, it needs to be *post-specified peer*. That is, contrary to:
The client knows:
- B: a public "onion key" for S
The client will in fact _not_ know B in advance in a Walking Onions setting, but rather will learn it at the end of the handshake.
I don't know the requirements here, but fwiw here's what pre-specified peer (NK or NK1) vs post-specified peer (NX) looks like for a Noise handshake:
NK: <- s ... -> e, es <- e, ee
NX: -> e <- e, ee, s, es
Trevor