[noise] non replayable XK/KK?

[Justin Cormack]

On 27 January 2018 at 19:26, Trevor Perrin <trevp at trevp.net> wrote:
> On Sat, Jan 27, 2018 at 3:32 PM, Justin Cormack
> 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?

Yes, I do think that psk, public key is better, even if just for the reason that
public keys are things that by the nature of their type you have mechanisms
to transfer (eg a handshake) and therefore it is high risk to have some keys
for which this is normal and others for which it would be disastrous.

> 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, 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

That does seem to be a nice way of doing constructions. It does start
to raise more questions around how many combinations there are
and how to help people make choices. I like your idea elsewhere of
proof and properties generation, so that a larger number of options
does not become unmanageable.

> 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...

Yes, it is not entirely clear as there are a lot of patterns. Maybe, like
psk, there are some versions that make most sense. Will think about it.

> 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?

It definitely seems promising to me.

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