Re: [tor-dev] Proposal 332: Ntor protocol with extra data, version 3.

[Trevor Perrin]

On Fri, Jul 16, 2021 at 5:31 AM Ian Goldberg  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
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal 332: Ntor protocol with extra data, version 3.

[Ian Goldberg]

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?

Nick, what are the settings in Tor (if any) in which low-entropy psk
will come up?


But this post from Trevor also made me realize a bigger issue with the
protocol Nick proposed:

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.  The
protocol Nick specified does in fact use B in the first message, unlike
the current ntor handshake, which just sends KEYID(B) in the first flow,
but it's not part of the math, or indeed as far as I can see, used for
anything at all in Section 5.1.4 of tor-spec.txt, and so can be easily
removed (and replaced with B being sent by the server) for Walking
Onions.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev