[noise] non replayable XK/KK?

[Trevor Perrin]

On Sun, Jan 28, 2018 at 10:11 AM, Justin Cormack
<justin at specialbusservice.com> wrote:
>
> Intuitively this may be most useful for where there is
> a pre-message, so there are parts of the handshake that can be done
> in effect by either party. So one choice is initiator vs responder using
> that shared key, so the NKdefer is switching from initiator to responder
> using it. For the KK case this would potentially allow two deferals.
> But maybe there are other useful deferral cases too.

It's hard to say where the line is between useful and
not-useful-but-valid patterns.  But the general case of deferral gets
complicated.  We could potentially "defer" any part of a handshake,
including any of the DH calculations, or transmitting any of the
public keys.

Just starting with XK, below's a non-exhaustive list of 7 "deferred" variants.

Hard to know what to do!  Do we work out a framework of modifiers that
can describe all of these?  Or just start with a simple modifier that
covers some immediate use cases (with the risk it doesn't generalize
well)?

XK(s, rs):
  <- s
  ...
  -> e, es
  <- e, ee
  -> s, se

XKdefer1(s, rs):
  <- s
  ...
  -> e
  <- e, ee, es
  -> s, se

XKdefer2(s, rs):
  <- s
  ...
  -> e
  <- e, ee
  -> es, s, se

XKdefer3(s, rs):
  <- s
  ...
  -> e
  <- e
  -> ee, es, s, se

XKdefer4(s, rs):
  <- s
  ...
  -> e
  <- e
  -> ee, es, s
  <- se

XKdefer5(s, rs):
  <- s
  ...
  -> e
  <- e
  -> ee, es
  <- s, se

XKdefer6(s, rs):
  <- s
  ...
  -> e
  <- e
  -> ee
  <- es
  -> s, se

XKdefer7(s, rs):
  <- s
  ...
  -> e
  <- e
  -> ee
  <- es
  -> s
  <- se

Trevor