[noise] non replayable XK/KK?

[Trevor Perrin]

On Sat, Jan 27, 2018 at 3:32 PM, Justin Cormack
<justin at specialbusservice.com> wrote:
> Been thinking about using noise for distributed capabilities, wrote
> some notes at https://www.cloudatomiclab.com/noise-capabilities/
[...]
> I wondered if Noise could be extended to support a non replayable
> version of KK and XK?

Hi Justin,

That's a very interesting direction, and it poses great questions
regarding patterns.

Before I get to your main point, let me be a stickler for one crypto
detail, since it affects the patterns we consider:

You cite [1] which discusses an "important conceptual link between
capabilities and public key cryptography", and says that "knowing the
public key of a key pair is like holding a capability to an object and
thereby being able to send messages to the object".

I think standard security models for public-key encryption assume that
"public keys" are known to the adversary, so I don't think we can
assume that public-key encryption is "unforgeable" if the public key
is secret (correct me if I'm wrong, someone).

Noise in particular assumes that public keys are public, so you'd have
to use them as PSKs if you wanted a property like that.  But I think
treating public-keys as secrets is confusing, thus dangerous, so it
would be better to use explicit PSKs.

So maybe a "capability" here would be more analogous to
 (1) a pair of (PSK, public key), or
 (2) a pair of (certificate chain, public key)

Where the first element is used for authentication of the possessing
party, and the second is used for encrypting to / authenticating the
resource?

To keep this simple, maybe we can focus on (1) and consider NKpsk0 as
a representative handshake that could be used with capabilities?

NKpsk0(rs):
  <- s
  ...
  -> psk, e, es
  <- e, ee


Anyways, your important observation (from the Dominic Tarr paper) is
that an attacker replaying an initial message in NKpsk0 (for example)
could confirm the server still has the same static key and PSK, if it
responds.

That's a good observation!  It's not in the Noise spec section on
identity hiding.  It probably should be.

Anyways, I think you and Dominic are right that we can improve NKpsk0
here by deferring the authentication:

  -> e
  <- e, ee, es, psk

We have a (still-evolving) concept of modifiers (psk?, fallback), and
this seems like another job for them.

For example, we could consider a "defer" modifier that moves the
authentication "es" later; then apply a psk modifier after that:

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

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

NKdefer+psk2(rs):
  <- s
  ...
  -> e
  <- e, ee, es, psk

This is also interesting because NKdefer is essentially Tor's "Ntor"
[2].  I don't know if there's a particular reason Tor prefers NKdefer
over NK (maybe it's just easier to hash the DH secrets in one go?
maybe it helps with DoS-resistance?), but it would be nice to be able
to express this.

We've lightly discussed this before but never bit into it, because it
would take real work to figure out the range of potential use cases /
requirements for a "defer" modifier (or multiple modifiers?) and then
specify how it actually works with all possible patterns...

But it's possible we should tackle this now.  Does this seem like the
right direction to people?  Anyone want to flesh out what "defer"
really means?

[1] http://www.cap-lore.com/CapTheory/Dist/PubKey.html
[2] http://www.cypherpunks.ca/~iang/pubs/ntor.pdf

Trevor