[noise] Noise Explorer

[Trevor Perrin]

On Thu, May 24, 2018 at 9:23 AM, Katriel Cohn-Gordon <me at katriel.co.uk> wrote:
>
> If the static public keys are in the transcript hash then I agree that this is not a problem. Nadim and I were wondering off-list whether there could be a form of deferred protocol which causes the static key to be left out of the transcript hash, but I don't think there is.

There shouldn't be, static public keys are always bound into the
transcript hash before being used.


> It'd have to be some form of post-handshake auth...

Post-handshake auth should use a "channel binding" to the handshake
hash, so the binding to the static public keys will carry through.


> Is it worth *explicitly* adding the static public keys to the KDF inputs if they exist, instead of having them present implicitly as one of the messages? That would duplicate them in most cases but avoids doubt.

I don't think there's much doubt here, in terms of "binding".  (And
we're long past the point where we'd make small arbitrary changes
without a hugely compelling reason!).

Another argument you could make though:  Depending on how you hash
things and do proofs, you might be able to get a tighter Gap-DH proof
if public keys are hashed into session keys, but I would consider that
a proof artifact I don't care about.

OTOH, we've had some threads about new ideas for symmetric crypto (see
David Wong's work on Disco, and some of the "NXOF" discussions).  One
possibility to discuss more in future is developing options for a
single hash-chain that combines transcript-hashing and key-derivation,
rather than having separate two separate chains (for ck and h).

However, I'd be interested in that for implementation simplicity and
efficiency, rather than any security benefit.

Trevor